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

[Roman Kennke]

On Wed, 22 Mar 2023 18:05:49 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> I don't think so, unless we also want to change all the stuff in x86_32.ad to not fetch the thread before calling into fast_unlock(). However, I think it is a nice and useful change. I could break it out of this PR and get it reviewed separately, it is a side-effect of the new locking impl insofar as we always require a thread register, and allocate&fetch it before going into fast_lock().
>
> I missed that it is under #ifndef LP64. Yes, it make since since you are now passing `thread` in register.
> And why we need to `get_thread()` at line 708 if we already have it?
> 
> It is still hard to follow this 32-bit code. What each register is holding, what is value `3` and why we don't have checks similar to LP64 code after CAS?

Good point about using the existing thread register.
I am not sure why we use '3' in x86_32 instead of the 1 (unlocked_value) that we are using elsewhere. It probably doesn't matter as long as it is not 0 which indicates recursive locking.
We don't do extra works after the CAS in x86_32 because x86_64 additionally optimizes the recursive case, while x86_32 drops into the slow-path there. It might be worth investigating if we could consolidate the two implementations and maybe even merge them into a single one. But perhaps not as part of the new locking effort?

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

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