In an environment of conservative GC, there cannot be any guarantee that the
finalize() method of a given object will ever be called before exit. In our runtime
we don't call outstanding finalization at normal runtime exit, so we can't offer a
guarantee that a finalize() method will be called at all. I think that this may be
unnecessary.

When the runtime exits, there may be objects needing finalization. We should at
least call runFinalization() to synchronously finalize these on normal exit. However,
just prior to actual exit all Java objects suddenly become logical garbage. We don't
necessarily need to call GC to know that, and because of the conservative scanning
we wouldn't want its opinion anyhow. Instead, we should be able to just take the
HasFinalizerQ, the list of existing objects with finalize() methods, and move it
(retaining appropriate order) onto the FinalizeMeQ, queueing *all* finalizable
objects independent of the conservative scan. We can then finalize synchronously,
and should know that we've got *everything*. We don't really want to touch the
existing objects, because finalization may need some of them to do its job.

If this can be made to work it would provide a guarantee that all finalizers *will*
be called, although their calling could be arbitrarily delayed. But that's OK for
someone running Purify on their C code, or who is using finalization to write out
objects to a persistant object store.

Of course, finalization might create threads and arbitrarily prolong the computation.
I don't know whether at-exit finalization causes any new problems here, and need
to think about that.