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

[Roman Kennke]

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

Hi Thomas,

> What is the advantage of using a stub here? The code section between aarch64 and x64 are different and only used in one place each. So you don't really save much by reuse here. Seems you could have just written them out as a conditional path into the various xxfastlock() functions. Then you would have saved the jumps into and out of the stub in the case owner==ANONYMOUS case.

This is not about saving memory. The very common path here is that owner is not ANONYMOUS. Using a stub means that we forward-jump only in the very uncommon path, and not branch in the common path. If we were not using a stub, we would have to forward-jump in the common path and not branch in the uncommon path. In my experience, forward-jumping in the common path throws off static branch prediction and performs significantly worse. This is also mentioned in the Intel optimization guide as important consideration.

> Anonymous means some other thread T2 inflated my lock while I (T1) was thin-lock-waiting on the lock, right?

Yes, exactly.

I'll address your other comments later today or tomorrow.

Thank you!
Roman

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

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