Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8288064

Class initialization locking

    XMLWordPrintable

Details

    • Enhancement
    • Resolution: Fixed
    • P4
    • 20
    • 20
    • hotspot
    • None
    • b03

    Description

      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.

      Attachments

        Issue Links

          Activity

            People

              coleenp Coleen Phillimore
              coleenp Coleen Phillimore
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: