-
Bug
-
Resolution: Fixed
-
P3
-
19, repo-loom
-
b08
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8297691 | 17.0.7-oracle | Adithya Haradi Gopal | P3 | Resolved | Fixed | b01 |
JDK-8299579 | 17.0.7 | Goetz Lindenmaier | P3 | Resolved | Fixed | b01 |
resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java is failing in the loom repo, even when not using the vthread wrapper:
java.lang.RuntimeException: 'truncating to' missing from stdout/stderr
The test is pretty simple. The target app creates a very large array:
int[] hugeArray = new int[Integer.MAX_VALUE/2];
When doing a heap dump, the following is expected in the output but is missing for some reason:
WARNING: Cannot dump array of type int with length 1073741823; truncating to length 1073741819
This doesn't happen when specifying no VM args, but does with the following args:
-Xcomp -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:+TieredCompilation
This also happens with just -Xcomp. It's unclear why the warning message is not produced. 1073741823 * 4 is 0x7fffffff. Add some room for the object header and the overall size of the object exceeds SA's limit, which is why SA would normally truncate it to 1073741819. Why in this case it is not exceeding the limit is unclear. Possibly the object is not even being dump, so the warning message is never triggered.
java.lang.RuntimeException: 'truncating to' missing from stdout/stderr
The test is pretty simple. The target app creates a very large array:
int[] hugeArray = new int[Integer.MAX_VALUE/2];
When doing a heap dump, the following is expected in the output but is missing for some reason:
WARNING: Cannot dump array of type int with length 1073741823; truncating to length 1073741819
This doesn't happen when specifying no VM args, but does with the following args:
-Xcomp -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:+TieredCompilation
This also happens with just -Xcomp. It's unclear why the warning message is not produced. 1073741823 * 4 is 0x7fffffff. Add some room for the object header and the overall size of the object exceeds SA's limit, which is why SA would normally truncate it to 1073741819. Why in this case it is not exceeding the limit is unclear. Possibly the object is not even being dump, so the warning message is never triggered.
- backported by
-
JDK-8297691 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java can fail if GC occurs
-
- Resolved
-
-
JDK-8299579 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java can fail if GC occurs
-
- Resolved
-
- links to
-
Commit openjdk/jdk17u-dev/d3c4a14c
-
Commit openjdk/jdk/be9f984c
-
Review openjdk/jdk17u-dev/1017
-
Review openjdk/jdk/7236
(1 links to)