JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass

[David Holmes]

Hi Mandy,

This all seems quite reasonable to me.

Two minor nits:

1. The "delay ntil" typo in Finalizer.java is still present.

2. In VM.java. booted need not be volatile now that it is only accessed 
within a locked region. Also awaitBooted might as well be void as it can 
only ever return true.

Thanks,
David

On 5/11/2013 6:04 AM, Mandy Chung wrote:
> Thank you all for the suggestions.
>
> Before the VM initialization is completed, any agent ought to be careful
> in what things it can do and what shouldn't do.  I think it's reasonable
> to ignore System.runFinalization if it's called at early startup phase.
> I'm unclear if there is any use case that we really require finalization
> to happen before VM is booted (I can imagine other problems may happen).
> I change the runFinalization and runAllFinalizers methods to return if
> it's not booted and also change runFinalizer method to take
> JavaLangAccess to simplify the synchronization instead of caching it in
> the static field.
>
> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.02/
>
> David - I decided to leave VM.awaitBooted as it is.  Having the callsite
> to call awaitBooted makes it explicit and clear that it's blocking and
> we will keep SharedSecrets.getJavaLangAccess method consistent with the
> other SharedSecrets methods that they are all getter methods.  If any
> future change calls SharedSecrets.getJavaLangAccess before it's booted,
> it's a little easier to diagnose (NPE vs hangs).
>
> Peter - thanks for the ObjectAccess idea.  I don't think supporting
> finalization to happen before VM is booted buys us anything and I would
> rather keep this change simple.
>
> Mandy