finalization vs References

Thu May 11 17:32:00 GMT 2000

On 2000年5月11日, Boehm, Hans wrote:
>I assume you include a pass somewhere that marks objects reachable from
>finalizable objects, so that they don't get collected until the next cycle?
>
Right, the unreferenced but finalizable objects get added to the gray
list and scanned before finalization.
>The main difference between this and what I currently do is the data
>structure used to represent finalizable objects. You use a bitmap; I use a
>linked list.
>>It seems to me the question of which is better mostly boils down to what
>fraction of the heap you expect to be finalizable (which might depend on
>perceived finalization cost ...). The bitmap clearly does better if a large
>fraction of the heap is finalizable. The list does better if it's a small
>fraction. A linked list of vectors might be preferable somewhere in the
>middle. Any ideas what it is for typical Java apps? (I know that for Xerox
>Cedar, it was around 0.1%, clearly favoring linked lists. But it's not at
>all clear that Java code is very similar to that.)
>
The main problem with linked lists is insuring you have enough memory
available to at collection time to create the ancilliary list objects required
for an arbitrarily large number of objects requiring finalization. In the
worst case, you'd need a separate list element for each object being collected.
Now on a Unix box you can always call sbrk() to ask for more heap; on an
embedded environment, this is not possible. The bitmaps provide a fixed
overhead that eliminates the need to allocate any memory during collection.
>It seems to me that you need a second data structure, representing the queue
>of objects ready to be finalized, which can then be handed to the finalizer
>thread. In the list case, you can recycle the list nodes. It seems to me
>that in the bitmap case, you need a third bit per object (marked,
>finalizable, ready to finalize), or a different data structure, for this
>purpose.
>>Hans

True, I need more than just the finalize bits.
Actually, my strategy divides memory into 512 byte blocks. Each block has
the following four 32-bit bitmaps which gives me a bit per 16 bytes.
	objectbits	true if an object is an allocated object
	graybits	true if an object is gray
	blackbits	true if an object is black
	finalizebits	true if an object needs finalization
These bitmasks give me an overhead of 16 bytes/512 byte block, or about
3% of total memory, to give an allocation granularity of 16 bytes.
An object needs finalization if its (finalizebits) bit is set but its
(objectbits) bit is clear. Note that this is distinct from objects which
are not awaiting finalization which would have the (objectbits) set.
After invoking the finalizer, I clear the an object's finalize bit and set its
object bit. The next GC pass, the collector will then collect it if it's still
unreferenced.
 -- 
Jon Olson, Modular Mining Systems
	 3289 E. Hemisphere Loop
	 Tucson, AZ 85706
INTERNET: olson@mmsi.com
PHONE: (520)746-9127
FAX: (520)889-5790