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

[Richard Reingruber]

On Thu, 25 May 2023 19:12:22 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Let's see if @rkennke remembers. Roman I wonder why you've implemented the C2HandleAnonOMOwnerStub instead of just taking the slow path into the runtime? @TheRealMDoerr wants to implement the logic inline and I'm actually worried if that will pay off the cost.
>> Maybe we should add an illegal instruction to see if it's reached. Do you know a benchmark that would be good for such a test?
>
>> Let's see if @rkennke remembers. Roman I wonder why you've implemented the C2HandleAnonOMOwnerStub instead of just taking the slow path into the runtime? @TheRealMDoerr wants to implement the logic inline and I'm actually worried if that will pay off the cost. Maybe we should add an illegal instruction to see if it's reached. Do you know a benchmark that would be good for such a test?
> 
> Handling the anonymous owner there is a rather rare situation. Handling this inline is possible, but it goes against static branch prediction: branch predictors in modern CPUs (at least in x86 and aarch64, not sure about ppc) assume that forward-branches are commonly *not* taken. However, we would very often branch forward in this situation and tend to cause a pipeline stall. It is better to leave the common path clean and short, and branch out to the stub in the uncommon case of handling the anonymous owner. Some of the renaissance benchmarks have been rather sensitive to the performance of monitor-locking (but I don't remember which ones ;-) ).

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.

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

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