JDK-8331353 : Test java/util/Base64/TestEncodingDecodingLength.java fails with OOME using ParallelGC after JDK-8330670
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 23
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2024-04-30
  • Updated: 2024-06-03
  • Resolved: 2024-06-03
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 23
23Resolved
Related Reports
Relates :  
Relates :  
Description
After JDK-8330670 was integrated this test started to fail under ParallelGC:

----------System.err:(17/1114)----------
java.lang.OutOfMemoryError: Java heap space
	at java.base/java.util.Base64$Decoder.decode(Base64.java:569)
	at TestEncodingDecodingLength.main(TestEncodingDecodingLength.java:56)
	at java.base/java.lang.invoke.LambdaForm$DMH/0x000001e001002000.invokeStatic(LambdaForm$DMH)
	at java.base/java.lang.invoke.LambdaForm$MH/0x000001e001003400.invoke(LambdaForm$MH)
	at java.base/java.lang.invoke.Invokers$Holder.invokeExact_MT(Invokers$Holder)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(DirectMethodHandleAccessor.java:154)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.runWith(Thread.java:1588)
	at java.base/java.lang.Thread.run(Thread.java:1575)

JavaTest Message: Test threw exception: java.lang.OutOfMemoryError: Java heap space
JavaTest Message: shutting down test

The test likely needs adjusting to account for the changes in ParallelGC behaviour, but initially assignng to GC team for investigation in case JDK-8330670 needs reconsideration.
Comments
The original test wrongly assumed that actually -Xmx memory would be available for "long-term" java object allocation. I.e. the old test allocated more than what was possibly available in old generation with the given settings; it only worked by the coincide that before JDK-8330670 the last allocation would fit into young gen (the additional young-gc before the full gc caused by that feature made it expand more than now) and the test basically exited after that allocation. The new, current test uses less memory and should work.
03-06-2024

The issue seems to be that the additional GCs due to ScavengeBeforeFullGC expand the young gen more than without; when the last object is being allocated by line 56 of the (original) test, that object does not fit into young gen because it has not expanded enough yet (actually, with ScavengeBeforeFullGC disabled, I had the test pass once), and the old gen is already too full to store that result array. The application would probably have failed on the next larger allocation anyway because that object can't be moved anywhere. It is kind of surprising that the original test actually always worked before.
29-05-2024

Using the build before the JDK-8330670 change (with the old test), it also fails with -XX:-ScavengeBeforeFullGC. However with ParallelGCThreads=1 it passes. Memory allowance (although total 8gb) seems to be very tight given that old gen is much smaller; in the failing cases Parallel GC correctly expands old gen to the allowed maximum already. Maybe some fragmentation issue that is just avoided well enough when doing a young gc before the full gc.
29-05-2024

This is an investigation to confirm that the issue is now more frequent due to removal of the flag/change of behavior and that is to be expected after that change on the old test.
03-05-2024