Projects

[Jonathan P. Olson]

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.

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.

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.

-- 
Jon Olson, Modular Mining Systems
	   3289 E. Hemisphere Loop
	   Tucson, AZ 85706
olson@mmsi.com
Phone:	(520)746-9127
Fax:	(520)889-5790