Currently, the JVM takes out a hidden Object lock while linking and while calling class initializers. The Object lock is injected in the Java mirror so that class initializers have no visibility to it and cannot unlock it. This lock is an Object so that we can hold it across upcalls to Java. We cannot hold VM Mutex/Monitor locks across upcalls to Java.

There's code to remove this Object lock when initialization is complete so that it doesn't use space in the Java heap. When InstanceKlass used to be in PermGen, this Object lock was simply the klassOop.

For the Object Monitors in Java project (moving synchronized support to Java), this init_lock Object taken in the VM will cause Java code to run while we're locking in order to link and initialize classes, and possibly the classes used for Java Object Monitor code itself. Also JVMTI events and bytecode tracing needs to be disabled for this VM->Java locking code, since the application shouldn't know this detail.

It's not a difficult change to make the init_lock be a JVM native Monitor that's taken and held to set InstanceKlass initialization state, and used to wait while another thread is linking and initializing the class. This would remove the problem of calling into Java in order to acquire a lock for mutual exclusion of linking and initializing classes.