This is the mail archive of the
mailing list for the Java project.
RE: Garbage collector problem ???
- To: "'apbianco at cygnus dot com'" <apbianco at cygnus dot com>, "Boehm, Hans" <hans_boehm at hp dot com>
- Subject: RE: Garbage collector problem ???
- From: "Boehm, Hans" <hans_boehm at hp dot com>
- Date: Fri, 19 Jan 2001 11:09:47 -0800
- Cc: "'balrog at amena dot com'" <balrog at amena dot com>, java-discuss at sources dot redhat dot com
> (2) always keep a
> pointer to the array object around, while addressing one of its
This should theoretically be very cheap, since the array pointer is almost
always around anyway (otherwise the current gcj would break more often), and
it's OK to spill the array pointer to a stack location, e.g. inside a loop.
It seems to be cheap, but not completely free, in the presence of imperfect
Many years ago, we looked at preserving this property in the gcc back-end,
and a summer student at Xerox PARC (Rhonda Reese) even generated some code
to do so. At the time, it looked like it was feasible to express the right
property at the RTL level, and thus have it preserved. This work was in the
context of C, not Java. And I'm sure many other things changed since then.
> -----Original Message-----
> From: Alexandre Petit-Bianco [mailto:email@example.com]
> Sent: Friday, January 19, 2001 10:34 AM
> To: Boehm, Hans
> Cc: 'firstname.lastname@example.org'; email@example.com
> Subject: RE: Garbage collector problem ???
> 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
> The current front-end does (1), though this can be optimized in weird
> ways. I'm not sure (2) is guaranteed, because of optimizations.
> > 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.