[PING] Re: [RFC 0/9] Attempt to unify Python object's lifecycle

["Jan Vraný" <Jan.Vrany@labware.com>]

Polite ping. 

Thanks,
Jan

On Mon, 2025-01-27 at 10:44 +0000, Jan Vrany wrote:
> Hi,
> 
> this RFC is an attempt to systematically address Andrew's
> comment on a patch I submitted earlier [1]. In particular,
> this part:
> 
> > I don't really like the approach taken by this function.  Each time
> > the
> > function is called we get a new gdb.Compunit object created and
> > chained
> > onto the objfile.
> 
> This is in fact true for other objects - gdb.Symtab, gdb.Symbol,
> gdb.Type. Moreover each of these objects have their own copy
> of (largely same) housekeeping code. The gdb.Block used to be
> the same but not long ago it was changed so gdb.Blocks are now
> interned (memoized). From the user point of view, I found it bit
> counter-intuitive.
> 
> My idea was to refactor this housekeeping code into a common class.
> This RFC is result of several iterations. Tested on x86_64-linux.
> 
> First four commits expand existing code to intern (memoize)
> gdb.Symtab, gdb.Symbol and gdb.Type. The rest then introduces
> template classes that implement necessary housekeeping and
> converts gdb.Symtab, gdb.Symbol and gdb.Type to use it.
> It could go further (one can convert gdb.Block too and
> gdb.Value and gdb.Value.type and dynamic_type could be
> further simplified too) but I decided to stop here.
> 
> The main reason is that it turned not to be as simple as
> I thought - there seem to be few differences here and there
> (see [2]). This complicated the housekeeping classes
> (gdbpy_registry and associated "storage"). My C++ is
> is pretty basic so perhaps there's better and simpler way
> of doing it. Another reason is that I was hoping for some code
> reduction in terms of size but looking at the result,
> there's hardly any. On the other hand, the lifecycle management
> is more unified across different Python objects.
> 
> All in all, I'm not sure this is the best approach and worth
> it. By this RFC, I'd like to solicit feedback from experienced
> GDB developers on how to move on.
> 
> Basically I see following options:
> 
> 1) Do not change anything in this area (I'm perfectly
>    happy with that).
> 2) Intern (memoize) Python objects (where it makes sense)
>    but keep the current approach. Basically first four
>    commits of this RFC.
> 3) Continue working on this.
> 
> Thanks,
> 
> Jan
> 
> [1]:
> https://inbox.sourceware.org/gdb-patches/87o70ar34z.fsf@redhat.com/
> [2]:
> https://inbox.sourceware.org/gdb/6c73f834d3f7b545188e1999125e7ae63ae83eab.camel@vrany.io/T/#u
> 
> ---
> 
> Jan Vrany (9):
>   gdb/python: preserve identity for gdb.Symtab objects
>   gdb/python: preserve identity for gdb.Symbol objects
>   gdb/python: do not hold on gdb.Symtab object from
> gdb.Symtab_and_line
>   gdb/python: preserve identity for gdb.Type objects
>   gdb/python: introduce gdbpy_registry
>   gdb/python: convert gdb.Symbol to use gdbpy_registry
>   gdb/python: convert gdb.Type to use gdbpy_registry
>   gdb/python: convert gdb.Symtab to use gdbpy_registry
>   gdb/python: convert gdb.Symtab_and_line to use gdbpy_registry
> 
>  gdb/python/py-symbol.c                 |  75 +++-------
>  gdb/python/py-symtab.c                 | 182 ++++++----------------
>  gdb/python/py-type.c                   |  95 +++++-------
>  gdb/python/python-internal.h           | 200
> +++++++++++++++++++++++++
>  gdb/testsuite/gdb.python/py-arch.exp   |   5 +
>  gdb/testsuite/gdb.python/py-symtab.exp |  28 ++++
>  gdb/testsuite/gdb.python/py-type.exp   |  15 ++
>  7 files changed, 347 insertions(+), 253 deletions(-)
>