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

[Patricio Chilano Mateo]

On Tue, 30 Jan 2024 02:08:54 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ThreadsListHandle required for Handshake
>
> My understanding is that monitor chunks are temporary native heap storage for BasicObjectLock records that are being moved from compiled frames to interpreter frames.  So the answer is, they will be found in the new interpreter frames that deoptimization pushes, assuming the monitors are not inflated in the process.

@dean-long will be actually encounter this native addresses when looking at a monitor owner? Because the value of `adr` that we pass to `JavaThread::is_lock_owned()` is either the address that we read from the markword for the stack-locked case, or the value of the _owner field for the inflated monitor case. If I see `Deoptimization::relock_objects()`, the BasicLock* that we use to relock the monitor should be a valid stack address. Then when we "move" the monitors from the stack to the monitor chunk in [1], `BasicLock::move_to()` will inflate the lock but I don't see we are using the native destination address. Am I missing something here? In other words, do we even need to traverse this monitor chunks?

[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/vframeArray.cpp#L90

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

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