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

[Nick Gasson]

Hi Derek,

Thanks for doing this testing!

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

The patch for 8216350 doesn't apply cleanly on 11u, but it should be 
easy to fix up. It's up to Andrew of course to decide whether it's worth 
backporting though...

Thanks,
Nick

On 06/03/2019 07:22, Derek White wrote:
> 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
> 
>