[jdk11u] Backport the fix of JDK-8180450 to JDK 11?

[Ziyi Lin]

Hi,
JDK-8180450(https://bugs.openjdk.org/browse/JDK-8180450) has a mojor performance impact on concurrent Java applications. Thanks to Andrew Haley to get it fixed in OpenJDK 23.
However, some applications suffered from this issue have to stay in the older OpenJDK version. For example, Spark requires OpenJDK11, but suffers the secondary supertype cache problem as well(https://github.com/scala/bug/issues/9823). 
I have run a snall test on query29 of TPC-DS on Spark 3.5.1, JDK11 with Francesco Nigro's fantastic agent tool(https://github.com/RedHatPerf/type-pollution-agent) to check how Spark is affected by the issue. The report shows there are around 2.4M secondary super cache invalidations in 108 seconds.It suggests the Spark is severely affected.
I modified the JDK11 a little bit by removing the updating of Klass::_secondary_super_cache:
diff --git a/src/hotspot/cpu/x86/macroAssembler_x86.cpp b/src/hotspot/cpu/x86/macroAssembler_x86.cpp
index 721134f84e..36f2146438 100644
--- a/src/hotspot/cpu/x86/macroAssembler_x86.cpp
+++ b/src/hotspot/cpu/x86/macroAssembler_x86.cpp
@@ -5044,7 +5044,7 @@ void MacroAssembler::check_klass_subtype_slow_path(Register sub_klass,
   else  jcc(Assembler::notEqual, *L_failure);

   // Success.  Cache the super we found and proceed in triumph.
-  movptr(super_cache_addr, super_klass);
+  // movptr(super_cache_addr, super_klass);

   if (L_success != &L_fallthrough) {
     jmp(*L_success);

And the performance of query29 get improved by 2% (average of 5 times' testing) instantly. 
It seems Spark and other concurrent applications will gain significant performance improvement from the fix. Is there a plan to backport the fix to JDK 11 in the future?

Ziyi Lin
cengfeng.lzy at alibaba-inc.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-updates-dev/attachments/20241012/1fe5f900/attachment.htm>