This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[patch 0/8] Types Garbage Collector (for VLA+Python)
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: gdb-patches at sourceware dot org
- Date: Mon, 25 May 2009 10:00:18 +0200
- Subject: [patch 0/8] Types Garbage Collector (for VLA+Python)
Hi,
this is a re-post of:
[patch] [0/5] Types reference counting (for VLA+Python)
http://sourceware.org/ml/gdb-patches/2009-04/msg00199.html
[patch] [1/5] Types reference counting [base]
http://sourceware.org/ml/gdb-patches/2009-04/msg00200.html
[patch] [2/5] Types reference counting [garbage-collector]
http://sourceware.org/ml/gdb-patches/2009-04/msg00201.html
[patch] [4/5] Types reference counting [varobj-validation]
http://sourceware.org/ml/gdb-patches/2009-04/msg00203.html
implementing now a mark-and-sweep garbage collector instead of the original
reference counting memory management; to address:
On Thu, 16 Apr 2009 21:32:11 +0200, Tom Tromey wrote:
> 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.
It may introduce now a quadratic complexity due to VALUE_HISTORY_CHAIN for
long-term running/repeating print commands. It may get fixed later:
* It is already a memory leak as value_history_chain never forgets.
* free_all_types (the GC) can be called only rarely. GDB can count the
reclaimable objects if they got allocated at all, currently it does not
happen too often.
* There may be a special exception for marking by value_history_chain.
Regression tested on x86_64-unknown-linux-gnu.
Thanks,
Jan