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

Disentangle JvmtiRawMonitor from ObjectMonitor and clean it up



    • Subcomponent:
    • Resolved In Build:


      From jvmtiRawMonitor.cpp:

      // The raw monitor subsystem is entirely distinct from normal
      // java-synchronization or jni-synchronization. raw monitors are not
      // associated with objects. They can be implemented in any manner
      // that makes sense. The original implementors decided to piggy-back
      // the raw-monitor implementation on the existing Java objectMonitor mechanism.
      // This flaw needs to fixed. We should reimplement raw monitors as sui-generis.
      // Specifically, we should not implement raw monitors via java monitors.
      // Time permitting, we should disentangle and deconvolve the two implementations
      // and move the resulting raw monitor implementation over to the JVMTI directories.
      // Ideally, the raw monitor implementation would be built on top of
      // park-unpark and nothing else.
      // raw monitors are used mainly by JVMTI
      // The raw monitor implementation borrows the ObjectMonitor structure,
      // but the operators are degenerate and extremely simple.

      In JDK-8229160 we looked at trying to reimplement JvmtiRawMonitor on top of PlatformMonitor, but the need for Thread.interrupt support made that a much more difficult exercise than had been envisaged.

      So instead we simply break the connection between JvmtiRawMonitor and ObjectMonitor by copying across any state and code that is needed. We can also simplify and copy the ObjectWaiter class, to break all external ties.

      There is additional cleanup needed in the JVMTI code involving raw monitors:
      - the unused PROPER_TRANSITIONS ifdefs
      - the disconnect between the upper and lower layers of code regarding non-JavaThreads - see below

      In JvmtiEnv::RawMonitorEnter we have this code for non-JavaThreads:

            if (thread->is_Named_thread()) {
              r = rmonitor->raw_enter(thread);
            } else {

      but in JvmtiMonitor::raw_enter we have:

        if (!THREAD->is_Java_thread()) {
           // No other non-Java threads besides VM thread would acquire
           // a raw monitor.
           assert(THREAD->is_VM_thread(), "must be VM thread");

      so there is a mismatch of expectations here. We appear to get away with this because the non-JavaThreads, other than the VMThread, seem to hit uncontended raw monitors and so avoid the assertion.

      By disentangling JvmtiRawMonitor from ObjectMonitor we're free to make modifications to ObjectMonitor more easily.


          Issue Links



              dholmes David Holmes
              dholmes David Holmes
              0 Vote for this issue
              1 Start watching this issue