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

[Martin Doerr]

On Thu, 25 May 2023 20:14:50 GMT, Roman Kennke <rkennke 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.
>
>> 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!

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

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