RFR: 8291555: Implement alternative fast-locking scheme [v56]

[Dean Long]

On Tue, 11 Apr 2023 15:29:16 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> OK. Given that I haven't looked at the rest of the patch, I leave it up to you and the Reviewers to figure out what to do about this code. Cheers.
>
> Given that the race with new lightweight locking is virtually the same as the race
> with legacy stack locking, please do not put back the 'LockingMode == 2' check
> which would make `jmm_GetThreadInfo()` calls slower with new lightweight locking
> than with legacy stack locking.
> 
> Perhaps I'm not understanding the risk of what @stefank means with:
> 
> It looks to me like the code could read racingly read the element just above _top,
> which could contain a stale oop. If the address of the stale oop matches the
> address of o then contains would incorrectly return true.

The `_base` array is only initialized to nullptr in debug builds.  I don't see a release barrier in LockStack::push between the update to _base[] and the update to _top, nor a corresponding acquire barrier when reading.  Doesn't this mean it is possible to racily read an uninitialized junk oop value from _base[], especially on weak memory models?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1163243827