Details
-
Bug
-
Resolution: Fixed
-
P4
-
22, 23
-
b22
Backports
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8332180 | 22.0.2 | Thomas Stuefe | P4 | Resolved | Fixed | b06 |
Description
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.
Attachments
Issue Links
- 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)