RFR: 8308469: [PPC64] Implement alternative fast-locking scheme [v2]

[Richard Reingruber]

On Fri, 26 May 2023 09:28:09 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>>> Sorry I was unclear about what I meant with 'inline': I meant part of the instruction sequence that `FastUnlock` is expanded to which isn't just a basic block. In that sequence it is out-of-line because it is at the end. So the forward branch that needs to be taken if it has an anonymous owner will be well predicted: not taken; continue with the next instruction. Reading again the inflation coding I see that there was a misunderstanding on my side. I though the actual owner will be set right when the monitor was successfully installed, but this isn't done of course, because finding the actual owner is expensive with LM_LIGHTWEIGHT locking. Sorry my bad. So it is not as unlikely as I thought, I'm still not totally convinced though that it is beneficial to handle the anonymous owner as part of `FastUnlock` case but I won't object against it.
>> 
>> Ah I understand what you mean. Handling the anonymous owner in FastUnlock is necessary for correctness. If we unlock a monitor and observe that it is locked anonymously, we must 1. update the owner and 2. pop the object from the lock-stack. The alternative here would be to detect this case and branch into the runtime to handle this, but handling it in compiled code is much more lightweight and not too difficult to do, nor does it add all that much to the code-size. Infact, this is very likely smaller, because calling to the runtime needs a lot of scaffolding to push/pop all registers, etc.
>
> Thanks for your explanation!

> The alternative here would be to detect this case and branch into the runtime to handle this, but handling it in compiled code is much more lightweight and not too difficult to do, nor does it add all that much to the code-size. Infact, this is very likely smaller because calling to the runtime needs a lot of scaffolding to push/pop all registers, etc.

But Roman of course the RT call wouldn't be part of the FastUnlock. Instead FastUnlock would return NE to indicate failure and then the slow path to the RT would be taken. So this is the smaller version.
You'll have lots of uncontended unlocks with dead code. And you'll handle the anonymous case just once / inflation on the other hand.
But everything's said now. I'm ok with it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14069#discussion_r1206520593