-
Bug
-
Resolution: Fixed
-
P4
-
22, 23
-
b22
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8332180 | 22.0.2 | Thomas Stuefe | P4 | Resolved | Fixed | b06 |
When using the compiler memory limit with the crash suboption (e.g. `-XX:CompileCommand=MemLimit,*.*,1g~crash`), the JVM may fail to produce a replay file. We also may see partly corrupted hs-err files.
This happens if the memlimit was caused by growing ResourceAreas, not the node arena (c2). During handling of the limit, as well as when producing the replay file, we also use ResourceArea (mainly to copy strings around). If those RA usages cause another Arena chunk to be allocated, we are in recursion and will abort replay generation or abort error handling altogether if a stack overflow happens.
This happens if the memlimit was caused by growing ResourceAreas, not the node arena (c2). During handling of the limit, as well as when producing the replay file, we also use ResourceArea (mainly to copy strings around). If those RA usages cause another Arena chunk to be allocated, we are in recursion and will abort replay generation or abort error handling altogether if a stack overflow happens.
- backported by
-
JDK-8332180 No compiler replay file with CompilerCommand MemLimit
-
- Resolved
-
- blocks
-
JDK-8331185 Enable compiler memory limits in debug builds
-
- Resolved
-
- links to
-
Commit openjdk/jdk22u/61792bc2
-
Commit openjdk/jdk/389f6fe9
-
Review openjdk/jdk22u/191
-
Review openjdk/jdk/19005
(1 links to)