Re: [patch 0/8] Types Garbage Collector (for VLA+Python)

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Sat, 06 Jun 2009 00:50:03 +0200, Tom Tromey wrote:
> >>>>> "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 am aware you did approve the reference counting implementation before.
There is place for sorry, thanks more for pointing out this full
mark-and-sweep GC implementation possibility.


> 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)?


(the new) mark-and-sweep GC implementation
	http://sourceware.org/ml/gdb-patches/2009-05/msg00543.html

pros
	* No additional glues in code dealing with types - no need to
	  reference count them [the type_incref() and type_decref() calls in
	  the reference-counting patch].

cons
	* Possibly lower runtime performance.  But it also depends how often
	  the mark-and-sweep GC is being run.  Heard mark-and-sweep GC can
	  be faster than type-referencing GC as it has zero overhead during
	  runtime contrary to the reference-counting GC needing to expensively
	  maintain the counters valid across all the runtime operations.

	  As a major successful platform (Java) relies on mark-and-sweep GC
	  such choice cannot be considered as a problem on current hardware.
	  And GDB currently has more severe performance problem than this one.


(the old) reference-counting GC implementation
	http://sourceware.org/ml/gdb-patches/2009-04/msg00199.html

cons
	* In addition to the type-referencing code it still needs the same
	  crawler implementation to ensure proper types grouping for
	  interconnected types (such as one being TYPE_CODE_PTR to the other
	  type it points to).

note (not a pro but an equality with mark-and-sweep GC):
	* It is immune against cyclic references as the types themselves never
	  make references.  Only values or other global variables referencing
	  types increase their references.  Type referencing an other type
	  only enforces both share the same type group.


hypothetical fully explicit reference-counting implementation

pros
	* No crawler needed.
	* Nothing like type_group is needed, as is currently in:
	    [patch 5/8] Types GC [type_group framework]
	    http://sourceware.org/ml/gdb-patches/2009-05/msg00548.html
	* It can discard no longer used types which are still just inter-type
	  connected with other types still in use.

cons
	* In addition to type_incref/type_decref calls for global objects
	  referencing types it also needs to call explicitly type_incref (or
	  type_decref) anytime GDB code connects (or disconnects) one type to
	  the other by TYPE_POINTER_TYPE, TYPE_REFERENCE_TYPE,
	  TYPE_FIELD_TYPE, TYPE_TARGET_TYPE or TYPE_VPTR_BASETYPE.
	* It would have to deal with inter-type cycles (by a crawler? :-) ).


I prefer this new mark-and-sweep GC primarily for no additional glues in the
regular GDB code which brings the best simplicity for people unrelated to this
framework.  Plus IMO nonexistent (or fixable) performance disadvantages.

Still I made no performance measurements - as currently I can only imagine
VALUE_HISTORY_CHAIN hit may be measurable which is fixable as discussed in:
	[patch 0/8] Types Garbage Collector (for VLA+Python)
	http://sourceware.org/ml/gdb-patches/2009-05/msg00543.html


> 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.

There must be no reference to any value which still did not have called
release_value on it.

As any value being linked into a global structures is always release_value-d
(otherwise it would be already a crashing bug in existing code) it means just
there must be no value referenced from autovariables.

Therefore it can be safely called from some top-level function (with no
unexpected callers and no its own autovariables rerefencing values).

free_all_types has the same rules.


Thanks,
Jan