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

Roman Kennke rkennke at openjdk.org
Thu May 25 19:14:55 UTC 2023


On Thu, 25 May 2023 18:54:36 GMT, Richard Reingruber <rrich 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?

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 ;-) ).

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

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


More information about the hotspot-dev mailing list