finalization vs References

Thu May 11 13:29:00 GMT 2000

On 2000年5月11日, Boehm, Hans wrote:
What I did in my embedded mark/sweep collector was allocate a bitmap
which contains whether each object requires finalization. Once an object
becomes unused, it gets reclaimed immediately if it doesn't require
finalization. If it does need finalization, the last phase of the collection
sweeps through the finalization bitmap invoking finalizers and clearing
finalization bits for all objects that need finalization. The finalization pass
is extremely cheap since it just looks at bitmaps, and doesn't get executed
at all if no unreferenced objects require finalization. Note that during the
finalization pass, an object being finalized can create a reference to itself
again, preventing it from being collected but its finalization bit cannot get
set again.
The only real penalty to finalized objects is that they don't get collected
immediately, but wait until the next GC to get collected. It only delays
collection of these objects but doesn't actually require another sweep.
Now if an application made every object require finalization, GC would
get invoked again real soon. However, I doubt that many applications use
finalization for a significant number of objects.
>Finalization isn't free, but it isn't that expensive either. Every
>finalizable object requires the allocation of another small object to keep
>track of it inside the collector. All of these small objects are examined
>twice during every collection.
>>I haven't measured this, but I would expect that if you had a heap full of
>small objects, and every oject in the heap somehow became finalizable, with
>an empty finalizer, you would roughly double or triple GC costs, in both
>time and space. There is no change in the asymprotic behavior; GC costs are
>still linear in the heap size.
>>The current incremental collector doesn't handle large volumes of
>finalizable objects very well, since much of the finalization work is done
>with the world stopped. Fixing that is a small matter of programming ...
>>I haven't thought enough recently about Java 2 references. I suspect all of
>these mechanisms have comparable costs.
>>Hans
>
-- 
Jon Olson, Modular Mining Systems
	 3289 E. Hemisphere Loop
	 Tucson, AZ 85706
INTERNET: olson@mmsi.com
PHONE: (520)746-9127
FAX: (520)889-5790