This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]