JDK-8336856 : Efficient hidden class-based string concatenation strategy
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 24
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2024-07-21
  • Updated: 2024-08-29
  • Resolved: 2024-08-16
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 24
24 b12Fixed
Related Reports
Relates :  
JDK-8327247 - C2 uses up to 2GB of RAM to compile complex string concat in extreme cases
Relates :  
JDK-8338930 - StringConcatFactory hardCoded string concatenation strategy
Relates :  
JDK-8339166 - java/lang/String/concat/HiddenClassUnloading.java fails on AIX and Linux ppc64le after JDK-8336856
Relates :  
JDK-8085796 - JEP 280: Indify String Concatenation
Description
The current strategy for bootstrapping JEP 280 String concat expressions uses either an optimized MH expression tree, or, due to scalability issues with that implementation, a per call-site StringBuilder-based class generation scheme. 

This RFE seeks to unify these into a single strategy that uses per-shape class generation emitting code semantically similar to the optimized MH expression tree. Using hidden classes installed into java.lang with access to the StringConcatHelper set of utility methods this can achieve similar throughput performance, while reducing the number of generated classes at high arities, reducing startup overheads, and improving warmup characteristics. 

This RFE was initially prompted by a suggestion of [~redestad] in the discussion of PR #20253 (https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866), and then evolved after collaborating on this issue into this full re-implementation.
Comments
Good. So a test bug. Testing 32M + 12000 iterations on my M1 it adds about 8s to make test TEST=.../HiddenClassUnloading.java - seems acceptable then to increase across the board rather than adding special AIX/ppc64le logic to the test.
29-08-2024
on AIX (and also Linux ppc64le) "silently" ergonomics sets a different heap size for the test; see the output with enhanced logging : command: main -Xmx8M -Xms8M -Xverify:all -Xlog:class+unload,gc+init,gc+ergo*=debug HiddenClassUnloading ----------System.out:(89/9240)---------- [0.041s][info][gc,init] CardTable entry size: 512 [0.043s][debug][gc,ergo,heap] Expand the heap. requested expansion amount: 33554432B expansion amount: 33554432B [0.045s][info ][gc,init ] Memory: 98304M [0.045s][info ][gc,init ] Large Page Support: Disabled [0.045s][info ][gc,init ] NUMA Support: Disabled [0.045s][info ][gc,init ] Compressed Oops: Enabled (32-bit) [0.045s][info ][gc,init ] Heap Region Size: 1M [0.045s][info ][gc,init ] Heap Min Capacity: 32M [0.045s][info ][gc,init ] Heap Initial Capacity: 32M [0.045s][info ][gc,init ] Heap Max Capacity: 32M With 32M instead of 8M, of course the test works very differently and we need much higher number of iterations to see the GC + triggering of class unloading. With 12.000 iterations the test works nicely also on AIX.
29-08-2024
I think this points to a bug somewhere on these platforms, either with hidden class unloading itself or somewhere in the ManagementFactory.getClassLoadingMXBean().getUnloadedClassCount() machinery. I suggest problem listing the test on affected platforms and file a bug to investigate.
22-08-2024
This testcase is to detect whether the HiddenClass can be unloaded when there are too many generated HiddenClasses. If it still fails when changing from 2000 to 5000, can you help change it to 200000 and try again?
21-08-2024
I was too fast, there are also at least 2 test failures on Linux ppc64le : java.lang.RuntimeException: unloadedClassCount is zero at HiddenClassUnloading.main(HiddenClassUnloading.java:66) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:588) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1575) so it is probably not a BE/LE issue because Linux ppc64le showed it too.
20-08-2024
For some reason the new test java/lang/String/concat/HiddenClassUnloading.java fails on AIX : java.lang.RuntimeException: unloadedClassCount is zero at HiddenClassUnloading.main(HiddenClassUnloading.java:66) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:588) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1575)
20-08-2024
[~mbaeskenMatthias Baesken] I don't have an AIX environment, so I can't verify it. Can you change 2000 in HiddenClassUnloading to 3000 and then verify it?
20-08-2024
> I don't have an AIX environment, so I can't verify it. Can you change 2000 in HiddenClassUnloading to 3000 and then verify it? Increasing the number of iterations in test HiddenClassUnloading does not help much; we still fail with 3000 and 5000 instead of 2000 . (tested on Linux ppc64le and AIX; this time with optimized binaries. the errors mentioned before were using fastdebug binaries)
20-08-2024
Changeset: 5022109b Branch: master Author: Shaojin Wen <shaojin.wensj@alibaba-inc.com> Committer: Claes Redestad <redestad@openjdk.org> Date: 2024-08-16 13:18:02 +0000 URL: https://git.openjdk.org/jdk/commit/5022109b2a33a8cf2608eb829098b27641b731a4
16-08-2024
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/20273 Date: 2024-07-21 12:25:36 +0000
23-07-2024