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

[David Holmes]

Hi Mandy,

On 2/11/2013 7:11 AM, Mandy Chung wrote:
> On 11/1/13 1:37 PM, mark.reinhold at oracle.com wrote:
>> 2013/11/1 4:15 -0700, mandy.chung at oracle.com:
>>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.00/
>> Looks good.
>>
>> Just one question: In Finalizer.java, at line 97 you look up the
>> JavaLangAccess object every single time.  Is it worth caching that
>> earlier, maybe when the finalize thread starts, since it will never
>> change?
>
> I was expecting that would get optimized during runtime and it's a
> simple getter method. It's a good suggestion to cache it at the finalize
> thread start time and here is the revised webrev:
>
> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.01/

I'm missing something basic - how did you get this to compile:

    public void invokeFinalize(Object o) throws Throwable {
      o.finalize();
    }

given finalize is protected ??

Also VM.awaitBooted seems inherently risky as a general method as you 
would have to make sure that it is never called by the main VM 
initialization thread. Perhaps handle this in 
sun.misc.SharedSecrets.getJavaLangAccess so it is less 'general'? That 
said I think Peter may be right that there could be races with agents 
triggerring explicit finalization requests early in the VM 
initialization process - which means any blocking operation dependent on 
other parts of the initialization sequence could be problematic.

Overall I think a safer approach may be to fix the native JNI code so 
that if it gets a private version of finalize() it looks up the method 
in the superclass.

David


> Thanks for the review.
> Mandy
>