RFR: 8314225: SIGSEGV in JavaThread::is_lock_owned [v2]

[David Holmes]

On Wed, 31 Jan 2024 08:04:42 GMT, Dean Long <dlong at openjdk.org> wrote:

> > does "on the native stack" equate to being in a compiled vframe ?? I thought checking the native stack simply found if the BasicObjectLock addr was allocated on the thread's native stack.
> 
> @dholmes-ora Yes, the lock record could be on the native stack in either an interpreter frame or a compiled frame, but I don't know if that's what you mean by being in a compiled vframe. If you mean what is returned by `compiledVFrame::monitors`, that returns all the monitors locked by the compiled frame, both inflated and fast/stack locked.

As monitor chunks were described as temporary storage for moving a monitor from a compiled frame to an interpreter frame, my question is whether checking "on the native stack" will actually find those monitors in compiled frames (or interpreter frames for that matter)? If the answer is yes then I'm starting to see a picture here where we check for all the monitor that can be found in the stack (compiled frames or interpreted frames) then recognize that if deopt is in progress then we scan monitor_chunks for any monitors that might still be transitioning across and only reside in a monitor_chunk. (It is still racy of course).

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

PR Comment: https://git.openjdk.org/jdk/pull/17566#issuecomment-1920544883