RFR: 8314225: SIGSEGV in JavaThread::is_lock_owned

[Dan Heidinga]

On Thu, 25 Jan 2024 11:04:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> JavaThread's _monitor_chunks member is temporary storage used by deoptimization.
> When other threads inspect it using JavaThread::monitor_chunks(), if it is non-null that means a deoptimization is in progress, and the value will be removed shortly.
> 
> There are a few places where we attempt to follow the MonitorChunk*, but that would only be valid if deopt is in progress, and only safe if we could know the deopt is not going to complete.  But that the deopt will complete, and will free the MonitorChunks and clear the value.  So this is rare but there is a race and a risk of following a MonitorChunk* as it gets freed, and crashing.

src/hotspot/share/runtime/javaThread.cpp line 1043:

> 1041:     chunks = _monitor_chunks; // will be null, as deopt frees when finished
> 1042:   } else {
> 1043:     ReadMonitorChunksHandshake rmch;

How expensive is the Handshake versus the direct read?  Is it worth optimistically reading using `monitor_chunks()` and only attempt the handshake if it returns non-null?

Or is there an API to probe if a thread is in a deopt that we can wrap around the handshake?

If the handshake is cheap enough, then this isn't worth looking at further.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17566#discussion_r1466401816