[aarch64-port-dev ] FYI: RFR: 8216350: AArch64: monitor unlock fast path not called

[Derek White]

Hi Nick + Arm China Team,

This is to tie together some issues we've been following related to this fix.

We've been looking at a major performance regression in JDK 9 of more than 10% (SPECjbb critical) on ThunderX2. Andrey Sudnik tracked this down to support for ObjectInputFilters in JDK 9. This added a global lock in object deserialization. It was a very short lock – basically a synchronized getter. This only gets painful under contention on many-core machines, where the lock definitely gets inflated and sometimes contended (even when the new feature is not used).

Your fix for JDK-8216350 reduced the regression in SPECjbb to only 4% or so (after back-porting to JDK 9+139). The new code in JDK 9 exactly matched the path that you fixed! I.E. a global lock eventually gets inflated given enough cores to hit the getter method, and from then on they take the slower (and broken) path.

So I wanted to acknowledge that your fix didn't just help some microbenchmarks, but also a fairly realistic transaction processing benchmark, and likely many actual applications. Great work!

For the remaining 4%:
I was able to identify a similar 4-6% regression on a 112 HW thread 2-socket Xeon Pentium due to the same global lock. Roger Riggs agrees that the global lock is not actually needed in the getter, and will be removing it. See JDK-8220166 “Performance regression in deserialization (4-6% in SPECjbb)” for details: https://bugs.openjdk.java.net/browse/JDK-8220166

Note that this regression was not detected by Oracle's internal performance tracking system, mostly likely run on smaller x86 servers. This is a great example of the core-scaling issues that we'll keep running into on many-core Arm server chips.

I'm not sure if the fixes for JDK-8216350 or JDK-8220166 would qualify for a backport to JDK 11, but they would certainly help performance.

Thanks again,
 - Derek