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

[Mandy Chung]

On 11/4/2013 6:03 PM, David Holmes wrote:
> Hi Mandy,
>
> This all seems quite reasonable to me.
>
> Two minor nits:
>
> 1. The "delay ntil" typo in Finalizer.java is still present.
>

Missed that :(

> 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.
>

Fixed.  Revised webrev at:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.03/

Thanks for the review.
Mandy

> 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