On 11/04/2013 05:45 AM, Mandy Chung wrote:
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.
Hmm... agents calling System.runFinalization during startup - like
Alan described, the agent is playing fire.
The potential issue that could happen is that during the VM
initialization the heap is so small that triggers GC and also the
startup code has finalizers and those objects with finalizers are
awaiting for finalization in order for the sufficient memory to be
freed up. The VM initialization couldn't get completed and the
Finalizer thread is blocked and thus due to insufficient memory,
eventually it would get out of memory. An agent instrumenting classes
early in the startup and creates lots of objects and finalizers, that
might also cause problem.
I think it's good to have the secondary finalizer thread to call
ensureAccessAvailable (with some modification to ensure jla is
initialized).
Hi Mandy,
What about the following helper class in java.lang package:
package java.lang;
import sun.misc.VM;
import sun.reflect.CallerSensitive;
import sun.reflect.Reflection;
/**
* Access to protected Object methods. Only accessible to system classes.
*/
public final class ObjectAccess {
private static final ObjectAccess theInstance = new ObjectAccess();
@CallerSensitive
public static ObjectAccess getInstance() {
Class<?> caller = Reflection.getCallerClass();
if (!VM.isSystemDomainLoader(caller.getClassLoader()))
throw new SecurityException("ObjectAccess");
return theInstance;
}
public void finalizeObject(Object o) throws Throwable {
o.finalize();
}
public Object cloneObject(Object o) throws CloneNotSupportedException {
return o.clone();
}
}
...is such code permissible to be executed in the Finalizer's static
initializer even before VM.isBooted() ?
Regards, Peter
