RE: GC_DEBUG patch, again

["Boehm, Hans" <hans dot boehm at hp dot com>]

> From: Bryce McKinlay [mailto:mckinlay@redhat.com]
> 
> OK. The clean-ups look good, thanks.
Thanks.  I'll check it in once some tests finish.

> 
> I'd like to get an idea of what would be required to enable the debug 
> routines to be selected at runtime, though. Is there code in 
> the GC that 
> assumes that only one version of the functions will be compiled in?
> 
The GC actually somewhat supports simultaneous use of both debug
and non-debug versions of the functions, though you may get
occasional false error reports.  And if you register an object
for finalization, you have to use the same flavor of the routine
as was used for allocation.  (One could fix that at modest cost.)

The real problem is that in order to get full functionality, you really
need to

a) Allocate at least most objects with extra space in the header.  This space
is currently used for
	- file name and line number at allocation. (Useless for Java)
	- partial stack trace at allocation.  (Less interesting, but
	  not useless. with vtable pointers in objects.)
	- space for GC installed back pointer.  This should really go
	  in a separate data structure I think.  The current solution
	  is more efficient for heap profiling.  But I think we can live
	  with the extra cost.  (There are currently two distinct back
	  pointer data structures: one for heap profiling, and one for
	  GC_PRINT_BACK_HEIGHT.  The latter keeps all back pointers,
	  and is constructed after the fact.  The GC_PRINT_BACK_HEIGHT
	  is partially separate.
	- The true allocation size.  (Not crucial?)
	- Space for magic numbers so we can check for overwrite errors.
	  (Should be impossible in pure Java code, but certainly possible
	  in native code.)

b) Use a version of the mark routine that keeps track of pointer sources,
and installs the back pointers.  It may make sense to do this in a second
pass as in backgraph.c.

Unless I'm overlooking something (not unlikely) I think that to really do
this at run-time, the collector should

- Keep all back pointers in a separate data structure, built in a separate
pass.  (Or possibly we could substitute a different version of the marker code,
as I suggested earlier.)  Use this for both heap profiling and
GC_PRINT_BACK_HEIGHT (backgraph.c).  This should make heap profiling
functional without debug headers, though the quality of the output might
suffer a bit, though we might be able to move some of the header
info to this structure as well.  Another downside is substantial
extra space use for heap profiling, though I have some ideas to minimize that.

- Make the object headers orthogonal, and have the debug_ routines
continue to add those.  Gcj would presumably call debug_ routines at most
in a debug build, or if we decide to use indirection for allocation anyway,
and debugging is requested.

- Probably get rid of the extra arguments to the debug allocation routines,
on the assumption that we know how to do stack unwinding, and we can
map addresses to line numbers later.

I will try to do something along these lines for 7.0, but I certainly
don't want to promise a completion date.  Some of this is real work.
I agree it's important, though.

Hans