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

[Dean Long]

On Thu, 1 Feb 2024 05:30:05 GMT, David Holmes <dholmes 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.
>
>> > 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).

@dholmes-ora, maybe in earlier versions of the code the mark word in the object was updated to point to the monitor chunk, which would result in a weird "monitor chunk stack-locked" object, if we considered the monitor chunks a logical extension of the native stack.  At least that appears to be what is_locked_owned is doing.  But as Patricio pointed out, stack-locked monitors get inflated, so we would only see the monitor lock record on the native stack in the compiled frame (before inflation), or not on the native stack at all (after inflation).

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

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