[gclist] Allowing finalizers to wait for the messiah.

[Mark Tillotson]

someone wrote:
> >If I had time, I'd tell you in detail, but I don't.  Basic
> >idea, if you have optional finalization, is to keep a table
> >full of "hidden" pointers (either "encrypted", or simply explicitly
> >not scanned by the GC).  After the GC runs, the table must be
> >checked for each about-to-be freed cell, and those found in the
> >table, are placed in a queue (accessible to the garbage collector,
> >now) and the elements in the queue are processed by running
> >their finalizers.  Details, such as answers to "what order is
> >used to place elements in the queue?" and "what do you do if
> >A and B are on the finalizer queue, and running A's finalizer
> >makes B reachable from an ordinary root?" seem to provoke long
> >and fruitless (no consensus is ever reached) debate.

Charles Fiterman <cef@geodesic.com> replied:
> You've missed the ugliest question. What if a finalizer stores
> a pointer to its object. You now have a pointer to free space.
The normal way to do things is to
1  trace from everything but the finalizer list
2  identify the moribund objects by traversing the list
   looking for untraced objects, which you remove from the list
   place on a second "finalize now" list.
3  trace from everything on the "finalize now" list
4  reclaim dead objects
5  pop the objects off the "finalize now" list and call the finalize
   method 

steps 1&2 identify finalizable objects dead to the application.
step 3 resurrects these objects and everything they refer to.
step 5 calls the finalizers (usually in the mutator context)
Because the objects were taken off the finalizer list, they won't
normally be finalized again.  It is up the the finalize method to
determine whether the object remains resurrected or gets collected
next time round.  You could for instance recycle resource handles this
way.  You could also interleave 3&5 and do 4 at the end, I guess.
> 
> Consider this in the context of Java. Java makes the promise
> that you can't write a virus in Java. This is the whole point
> of the language. You can have Java apps in your web site and
> people can download them and they wont take over.
> 
> So I write an app that allocates an object which contains a 
> large byte array and a finalizer. The finalizer comes along
> and stores a pointer to the array in a static area. Now the
> program keeps running building objects and watching the array
> until an object shows up inside it. Java objects have pointers
> to machine language functions but you can't normally see or
> change them. But now you have this Java object inside a byte
> array. So you aim one of those pointers to your own machine
> language and trigger it via its object's methods. Now your
> virus takes over.

Java's object finalization protocol is pretty much as above, and hence
typesafe.  See the Java Language Spec. section 12.6

__Mark
[ markt@harlequin.co.uk | http://www.harlequin.co.uk/ | +44(0)1954 785433 ]