What is the relationship about JVM monitor and linux OS mutex api

Question

I am trying to figure out what is the relationship about monitor and the operation system mutex lock, the java implement the synchronization keywords by monitor, does the monitor invoke the operation system mutex api? or the monitor implement the mutex by himself? I have read the source code src/hotspot/share/runtime/objectMonitor.cpp but still could not figure out.

Mutexes are always (AFAIK) implemented in hardware. So the jvm must use the OS mutex api. — SimGel, Oct 22 '22 at 09:10
seems befire jdk 6, invoke the os mutex lock, after the jdk 6, using monitor. @SimGel — Dolphin, Oct 22 '22 at 14:21
What precisely do you mean by OS mutex? Are you referring to a C library data structure / functions? A system call? And what operating system are you referring to? — Stephen C, Oct 24 '22 at 07:19
I have tweaked the title about more details, the OS mutex refer to linux/unix system call api. @StephenC — Dolphin, Oct 24 '22 at 07:41

score 1 · Answer 1 · answered Oct 24 '22 at 06:48

Just as shown in the source code of src/hotspot/share/runtime/objectMonitor.cpp, it uses Atomic::cmpxchg_ptr (CAS ops) to try to obtain the lock of the thread.

bool ObjectMonitor::try_enter(Thread* THREAD) {
  if (THREAD != _owner) {
    if (THREAD->is_lock_owned ((address)_owner)) {
       assert(_recursions == 0, "internal state error");
       _owner = THREAD ;
       _recursions = 1 ;
       OwnerIsThread = 1 ;
       return true;
    }
    if (Atomic::cmpxchg_ptr (THREAD, &_owner, NULL) != NULL) {
      return false;
    }
    return true;
  } else {
    _recursions++;
    return true;
  }
}

The implementation of Atomic::cmpxchg_ptr is dependent on the actual arch of the system. In x86 Atomic::cmpxchg_ptr is done by adding the lock prefix to ensure CPU has exclusive ownership of memory during operation.

I have already read this source code, and I just want to figure out the jvm monitor invoke the linux mutex api or not, seems the new version of jvm did not invoke the linux mutex api. @danyfang — Dolphin, Oct 24 '22 at 07:31

Stephen C · Accepted Answer · 2022-10-24T13:19:58.733

Your question is (still!!) unclear, but I assume that "linux/unix system call api" is referring to the pthread_mutex_t type and its associated library functions. Strictly, these are not syscalls, though they may make syscalls if there is lock contention.

While JVM implementations (Java 6 onwards) do use pthread_mutex_t and associated functions, they are not used in the implementation of Java primitive mutexes.

As the comments say (Java 17 version):

// * The monitor synchronization subsystem avoids the use of native
//   synchronization primitives except for the narrow platform-specific
//   park-unpark abstraction.  See the comments in os_solaris.cpp regarding
//   the semantics of park-unpark.  Put another way, this monitor implementation
//   depends only on atomic operations and park-unpark.  The monitor subsystem
//   manages all RUNNING->BLOCKED and BLOCKED->READY transitions while the
//   underlying OS manages the READY<->RUN transitions.

So, the answer to your question is that there is no relationship.

Note that the JVM's monitor code has changed a number of times since Java 6 and the latest version (Java 19). But the above seems to hold true for all of the versions I could look at.

(I don't have a copy of the JVM source code prior to Java 6.)

What is the relationship about JVM monitor and linux OS mutex api

2 Answers2