GC statistics (was Re: big project ported)

[Boehm, Hans]

I believe the statement in the 1996 PLDI paper is still fairly accurate,
though it's getting slightly more questionable over time.

Recent versions of the collector do recognize pointers to anywhere inside an
object as a precaution.  But that's not necessarily sufficient, and I have
since seen one real instance in which the compiler successfully hid a
pointer from the collector, and thus introduced a bug.  (This occurred with
Visual C++, which seems to have grown a fairly aggressive optimizer over the
years.)  I would expect that without interior pointer recognition there
would have been a few more instances of this due to compiler optimizations,
and many more due to client code that doesn't keep base pointers.

Does gcj use the normally default of defining ALL_INTERIOR_POINTERS?  Even
if it doesn't, all interior pointers originating on the stack or in
registers are recognized.  The collector does use the techniques of the 1996
paper to minimize the chance that this will cause spurious retention.  This
tends to make it hard to allocate very large objects.

I would like to eventually see the gcc back-end ensure some form GC-safety,
at least for potentially large arrays.  That would allow such arrays to be
allocated such that interior pointers are only recognized close to the
beginning of the array, which avoids these issues.

Hans

-----Original Message-----
From: Godmar Back [ mailto:gback@cs.utah.edu ]
Sent: Wednesday, October 27, 1999 1:54 PM
To: hboehm@exch.hpl.hp.com
Cc: tromey@cygnus.com; java-discuss@sourceware.cygnus.com
Subject: Re: GC statistics (was Re: big project ported)


> 
> I would expect there to be an issue with the allocation of very large
> (multi-MB) Java arrays.  By default, and I believe the way they are
> allocated now, a misidentified pointer to anywhere in the array retains
the
> array.  The allocator will try to place such arrays between known bogus
> references to minimize the problem.  But this tends to be hard for
> sufficiently big arrays.  I know of no way to avoid this issue without
> teaching the code generator to keep a reference to the beginning of the
> array around as long as the array is needed.  Once you do that, it becomes
> trivial.
> 

Hans,

in your 1996 PLDI paper [1], you discuss the problems with GC safety
that can occur if the code generator does not keep a reference to the
beginning of the array around and suggest an alternative to make
code GC-safe.

However, you said that "Such problems are in fact extremely rare with
existing compilers, ... and the above problems have only been observed
in examples contrived for the purpose"

Have things changed since or is this a different issue?

	- Godmar

[1] Boehm, H., ``Simple Garbage-Collector-Safety'', Proceedings 
of the ACM SIGPLAN '96 Conference on Programming Language Design 
and Implementation.