[gclist] Buffy finalizer slayer.

[Charles Fiterman]

At 10:36 AM 6/11/99 -0600, you wrote:
>From: Charles Fiterman <cef@geodesic.com>
>> All problems with finalizers come from the fact they raise dead objects to
>> alter the bits of the living. Eliminate that and all the problems turn into
>> dust.
>
>My own preference is that objects are finalized in topolological order
>and finalizers are strictly forbidden from raising the dead or creating
>more living.  Call it the "last rites" approach if you will, or perhaps
>the "bardo" if you prefer a different religion.

When the collector hands the mutator a dead object it has raised the dead.
The mutator then runs in the entire language unless you have some way to
enforce a subset. If the dead object fails to alter the bits of the living
why invoke the mutator with the dead object.

If the mutator takes the pointer to the dead object and saves it you must
either declare it undead and have a meaning for that state or you have a
loose pointer. The greatest value of a strongly typed language like Java is
you can't write a virus in it. Once you create a loose pointer you can
create a virus. Allocate a 10,000 byte character array in a finalizer
object, force the finalizer to run saving a pointer to the object. Now run
more stuff waiting for an object to appear in your character array. Now you
can corrupt the pointers in the array to execute your hand coded assembler.
Gotcha.

Strictly forbidden is meaningless without enforcement. How do you enforce
your limits and what are they? Because if the user figures out how to cheat
you have a virus that spreads when you view the wrong web site.

According to my medieval text in the seventh century a finalizer raised a
dead object named Gorth who infected every computer in Cappidocia ending
Roman rule in the region.