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

Peter Levart peter.levart at gmail.com
Mon Nov 4 10:03:32 UTC 2013

On 11/04/2013 09:48 AM, Alan Bateman wrote:
> On 04/11/2013 08:33, Peter Levart wrote:
>> :
>> What about the following helper class in java.lang package:
> If public then it leaks into the Java SE API. I think using 
> SharedSecrets should be okay, assuming we can sort out any potential 
> races getting to JavaLangAccess.
> -Alan.

The problem is that we would like Finalizers to be executed even before 
VM.isBooted(). Currently this is possible, because native code is used 
to access Object.finalize(). java.lang.Thread is initialized earlier, 
but initializing SharedSecrets.javaLangAccess in Thread's static 
initializer doesn't work (VM crashes). I think this is because 
SharedSecrets also initialize sun.misc.Unsafe via .getUnsafe() method 
and this needs the caller ClassLoader to check access... SharedSecrets 
is already too encumbered to be used that early in boot-up sequence.

So what about the following simple class in sun.misc:

package sun.misc;

  * Access to protected Object methods.
public abstract class ObjectAccess {
     private static ObjectAccess theInstance;

     public static ObjectAccess getInstance() {
         return theInstance;

     public static void setInstance(ObjectAccess instance) {
         theInstance = instance;

     public abstract void finalizeObject(Object o) throws Throwable;

...with the following initialization in java.lang.Thread:

class Thread implements Runnable {
     /* Make sure registerNatives is the first thing <clinit> does. */
     private static native void registerNatives();
     static {
*        sun.misc.ObjectAccess.setInstance(new ObjectAccess() {**
**            @Override**
**            public void finalizeObject(Object o) throws Throwable {**
**                o.finalize();**
**            }**
**        });*

I tried executing JVM with these two changes and is seems to work - i.e. 
does not cause JVM to crash at startup.

Regards, Peter

More information about the core-libs-dev mailing list