[master] RFR: 8302209: [Lilliput] Optimize fix-anon monitor owner path [v2]

[Thomas Stuefe]

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Tue, 14 Feb 2023 14:47:41 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> When trying to exit a monitor, we need to check if the current owner is anonymous, and if so, fix it before exiting the monitor. So far, we have been doing this by calling into the slow-path and handle it in the runtime. However, it is fairly easy to do in the fast-path and avoid calling into the runtime altogether. I also included those changes in [upstream fast-locking PR](https://github.com/openjdk/jdk/pull/10907).
>> 
>> Testing:
>>  - [x] tier1 (x86_64, aarch64)
>>  - [x] tier2 (x86_64, aarch64)
>>  - [ ] jcstress -t sync -m quick
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into JDK-8302209
>  - 8302209: [Lilliput] Optimize fix-anon monitor owner path

Reading through fast_unlock() some more...

What I did not understand at first is why you pop the object twice in fast_unlock: once in the stub, then again in fast_unlock_impl. But "Stacked" means thin-locked, right? So the section at 948ff is for handling stack-based thin locks?

If that is so, at some point in time we may want to rename things to make it simpler. E.g. "Stacked"->"Thin" or similar. "Thin" would be a good fit for both new-style locks and old stack-based locks. I understand that you don't want to do this downstream though to keep the delta small.

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

PR: https://git.openjdk.org/lilliput/pull/74