finalization vs References

Thu May 11 14:14:00 GMT 2000

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?
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.)
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
> -----Original Message-----
> From: Jon Olson [ mailto:olson@mmsi.com ]
> Sent: Thursday, May 11, 2000 1:15 PM
> To: Boehm, Hans; 'Per Bothner'; java-discuss@sourceware.cygnus.com
> Subject: RE: finalization vs References
>>> 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
>