Re: [patch] [0/5] Types reference counting (for VLA+Python)

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> currently GDB knows only permanent types and objfile-associated
Jan> types.  GDB currently does not need more.  The only special kind
Jan> are types copied from closed objfiles for value history.  As the
Jan> value history is always kept in full length such types are in
Jan> fact also permanent.

FWIW, you can get a memory leak here with CVS gdb by setting a
convenience variable to a value whose type comes from an objfile,
closing all the objfiles ("file"), and then assigning a new value to
the convenience variable.  In this case nothing frees the type.

Jan> To be true there exist some artificial temporary types such as in
Jan> value_cast
[...]
Jan> , these can be freed by this implemented garbage collecting
Jan> infrastructure.  These are already leaking in current FSF GDB;
Jan> fix based on this framework is currently not a part of this
Jan> patchset.

Why is that?  (It doesn't matter in terms of acceptance, I'm just
curious.)

Jan> This is a work based on Tom Tromey's original one but it got
Jan> changed a lot so blames to me first.

:-)

Jan> The basic decisions of this patchset are about the differences
Jan> between permant types (currently having TYPE_OBJFILE == NULL) and
Jan> garbage collectable (=reclaimable) types:

Jan> * Should the default allocation of types (alloc_type (NULL))
Jan> provide permanent type or a garbage collectable type?
Jan>   = Currently it creates a permanent type.

Too bad the other approach didn't work out.  Where do all these
permanent types come from?  Not just init_type, I gather.

It seems strange to have a type-crawling garbage collector *and*
reference counting.  But I suppose this is because enumerating the
root set is tricky.

Jan>   Not tested with the Python branch (which will need to
Jan> explicitely define the allocated types as reclaimable).

I'll handle this, assuming the timing is right.  We're accumulating
quite a backlog of patches to be applied after the pretty-printing
series :-(

I think your approach seems sane in general.  I will comment on the
individual patches soon.

Tom