Projects

Mon May 8 07:48:00 GMT 2000

On 2000年5月07日, 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