Garbage collector problem ???

[Boehm, Hans]

> From: Corey Minyard [ mailto:minyard@acm.org ]
> Alexandre Petit-Bianco <apbianco@cygnus.com> writes:
> 
> > Boehm, Hans writes:
> > 
> > > That would be safe for Java arrays if we knew that the compiler
> > > always kept a pointer to the array itself while the array could
> > > still be dereferenced.
> > 
> > You mean (1) always address an array element with an arithmetic that
> > starts from the pointer to the array object? Or (2) always keep a
> > pointer to the array object around, while addressing on of its
> > element?
> > 
> > The current front-end does (1), though this can be 
> optimized in weird
> > ways. I'm not sure (2) is guaranteed, because of optimizations.
> 
> Because Java arrays are objects and hold things besides just the
> array, I'd actually be suprised if (2) wasn't maintained for Java
> arrays.  If it wasn't, I doubt it would be maintained for normal
> objects, either.
Just to clarify:

I) I'd be very surprised if (2) were guaranteed, for either plain objects or
arrays.

II) I'd be mildly surprised if someone could send me a non-contrived piece
of Java code for which (2) is violated by gcc.  Given a day or so, I suspect
I could contrive one.  A requirement for such an example is that the
remaining information in the array object is clearly dead, so that the
compiler doesn't need to keep a pointer to it.  You also want lots of
register pressure, to motivate the compiler to reuse the register that used
to point to the array.

(III) Plain objects are usually much less of an issue than arrays for two
reasons:
(a) Java objects can't really be very large.  Thus there is virtually
guaranteed to be room for them between known false pointer targets.
Recognizing interior pointers from the stack to plain objects is almost
always fine.
(b) There is rarely any motivation for the compiler to produce a derived
pointer outside the object.  Thus recognizing interior pointers from the
stack is generally sufficient to handle the problem.  (The counterexamples I
know about involve accessing fields with a displacement of more than 32K on
something like PowerPC.  I suspect that's extremely unlikely for Java
objects.)
> 
> > 
> > > I believe currently the front end ensures that, but not in a way
> > > that ensures the back end will preserve the property.
> > 
> > I'll see if some hints can be passed to the middle and back-end.
> 
> Getting hints from the Java portion of the compiler is probably not
> good enough.  I'd actually be more concerned about the C and C++
> portions of the compiler.  The C libraries might also be a problem.
> The strhash stuff (for String.intern()) would be once case where this
> might happen, and anything that deals directly with arrays from C++
> would be suspect.

Agreed.  The back end eventually needs to support a GC-safety option across
all languages.  I'm personally less worried about the standard libraries
than user CNI or Objective C code, since there is a finite amount of code in
the standard libraries, and in the unlikely case that the problem occurs
there, we can work around it.  But it clearly is an issue for both.

Hans