This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch 0/8] Types Garbage Collector (for VLA+Python)
- From: Tom Tromey <tromey at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 05 Jun 2009 16:50:03 -0600
- Subject: Re: [patch 0/8] Types Garbage Collector (for VLA+Python)
- References: <20090525080017.GA10886@host0.dyn.jankratochvil.net>
- Reply-to: tromey at redhat dot com
>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
Jan> implementing now a mark-and-sweep garbage collector instead of the original
Jan> reference counting memory management; to address:
Tom> It seems strange to have a type-crawling garbage collector *and*
Tom> reference counting. But I suppose this is because enumerating
Tom> the root set is tricky.
I was making an assertion to try to make sure I understood the
situation... but I see now I did that somewhat clumsily. I'm sorry
about that.
I think the real question is what approach we want. I'm happy with
either approach provided it achieves our goals. Could you briefly
address the pros and cons of this series as compared to the other one?
Is there one you prefer (and why)?
Jan> * free_all_types (the GC) can be called only rarely. GDB can count the
Jan> reclaimable objects if they got allocated at all, currently it does not
Jan> happen too often.
I occasionally wonder whether we can call free_all_values in a
long-running Python script.
Tom