[master] RFR: Fix BasicLock to test for UseObjectMonitorTable rather than LM_LIGHTWEIGHT [v3]
Coleen Phillimore
coleenp at openjdk.org
Thu Jun 20 12:47:34 UTC 2024
On Thu, 20 Jun 2024 12:32:47 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:
>> So I was unsure of this. It's only LM_LEGACY that needs the displaced header? Lightweight locking doesn't use it even without the table?
>
> Correct, one of the main features with `LM_LIGHTWEIGHT` is that it does not need to displace the header when fast locking. It only displaces it when doing inflated locking, but then it is displaced in the ObjectMonitor*, not on the thread stack. (And with the table we also avoid this second displacement)
>
> `LM_LEGACY` uses this stack slot for two things. If it is 0 it means that it was recursively fast locked. Otherwise if it is the address which the markWord points to it is the displaced header which should be restored when unlocking. And when doing inflated locking a non-zero value is written so it does not look like a recursive fast lock.
I got my displaced headers mixed up between ObjectMonitor and BasicLock. Thanks for the explanation, I don't really know the legacy locking code that well.
-------------
PR Review Comment: https://git.openjdk.org/lilliput/pull/182#discussion_r1647516639
More information about the lilliput-dev
mailing list