On Wed, 22 Mar 2023 18:05:49 GMT, Vladimir Kozlov <k...@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
