Projects

Sun May 7 20:48:00 GMT 2000

"Jonathan P. Olson" <olson@mmsi.com> writes:
>> Precise collection implies that there is enough information at run-time
> for GC to know exactly what memory locations contain pointers.
> This is really not a write-barrier issue but rather having the compiler
> generate alot of run-time type information about objects and what
> locations within objects contain pointers. Precise collectors have the
> following advantages.
>> 1) They avoid memory lossage from floating point numbers and
> integers which `look' like pointers.
> 2) They allow the implementation of copying collectors.
> 3) They avoid scanning memory which does not contain pointers.
>> In my opinion, 1) isn't significant. The additional memory required for
> the run-time type information far exceeds the memory lossage of pointer
> aliasing.

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