Projects

[Corey Minyard]

"Jonathan P. Olson" <olson@mmsi.com> writes:

> On Sun, 07 May 2000, Corey Minyard wrote:
> >
> >I think it is significant.  You are making some big assumptions in
> >your statement that don't match my runtime environment.  I'm running
> >GC in 1GB of RAM on a 32-bit processor.  In that case, 1/16th of all
> >"random" data looks like a valid pointer.  Encryption data is
> >especially bad about having random looking data.  I implemented
> >something to scan the root set before the GC started and eliminate
> >these from the scan (maybe dangerous, but not too bad, really, since
> >uninitialized data is set to zero by Unix).  I was loosing many
> >megabytes of data before, now I loose nothing.
> >
> >I will also point out that Java requires this type of runtime type
> >information, anyway, so no additional memory is required for this.
> >
> >Corey
> 
> Actually, you can get alot better than 1/16 if you assume that
> a reference to an object must be to the starting address, not just
> anywhere inside the object.  In this case, your 1 GB, if you have
> an average of 32 bytes per allocation would have only 1/128
> lossage.  With larger allocations the lossage would be proportionately
> much less.

You are, of course, correct.  The problem with lossage, especially in
larger more connected sets, is that losing one can mean losing a lot
of data.  I'm trying to train our designers to null pointers when
done, but there are lots of cases to think of.  But if we could null
everything when done, then manual memory management would be easy :-).

> 
> Considering the 50% overhead I get with Java metadata, lossage
> from GC seems miniscule.  Besides, gcj's metadata isn't terribly
> useful as-is for a garbage collector.  To be actually useful for precise
> collection, you really need a separate data structure containing a bit
> for each pointer in an allocation.  Merrily marching through the Java
> field metadata looking for pointers would really kill GC performance.

Ok, you are right.  Although GCJ currently uses the metadata for this,
the performance does stink.  I've worked on a different method than
the bit array; I implemented something that scanned the metadata for a
class the first time it was collected and created a table of ranges to
scan and stuck that in the vtable for the class.  It uses the table
after that.  I'm not sure if the bit array is better performance-wise,
but it wasn't ready when I was doing this and it is limited to 128
byte objects (unless something has changed recently).

> However, I believe that collecting a 1 GB heap is an entirely
> different problem than collecting a 1 MB heap.  I hate to see the
> application that actually has an entire 1GB of heap space active at
> once.

It's pretty scary.  It makes the class overhead pretty trivial, I'd
gladly trade memory for performance.

Corey