-
Bug
-
Resolution: Fixed
-
P3
-
17, 20
-
b26
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8298830 | 17.0.7-oracle | Tobias Hartmann | P3 | Resolved | Fixed | b01 |
JDK-8299823 | 17.0.7 | Goetz Lindenmaier | P3 | Resolved | Fixed | b01 |
JVMCI has a mechanism for translating exceptions from libjvmci to HotSpot and vice versa. This is important for proper error handling when a thread calls between these 2 runtime heaps.
This translation mechanism itself needs to be robust in the context of resource limits, especially heap limits, as it may be translating an OutOfMemoryError from HotSpot back into libjvmci. The existing code in HotSpotJVMCIRuntime.encodeThrowable[1] and TranslatedException.encodeThrowable[2] should handle translation failures by falling back to non-allocating code. However, we still see a rare OOME that breaks the translation mechanism (e.g., https://github.com/oracle/graal/issues/5470#issuecomment-1321749688). One possibility for this is an OOME rematerializing oops during a deoptimization causing an unexpected execution path. The exception translation code should be made more robust against such paths.
[1] https://github.com/graalvm/labs-openjdk-17/blob/f6b18b596fa5acb1ab7efa10e284d106669040a6/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java#L237
[2] https://github.com/graalvm/labs-openjdk-17/blob/f6b18b596fa5acb1ab7efa10e284d106669040a6/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/TranslatedException.java#L153
This translation mechanism itself needs to be robust in the context of resource limits, especially heap limits, as it may be translating an OutOfMemoryError from HotSpot back into libjvmci. The existing code in HotSpotJVMCIRuntime.encodeThrowable[1] and TranslatedException.encodeThrowable[2] should handle translation failures by falling back to non-allocating code. However, we still see a rare OOME that breaks the translation mechanism (e.g., https://github.com/oracle/graal/issues/5470#issuecomment-1321749688). One possibility for this is an OOME rematerializing oops during a deoptimization causing an unexpected execution path. The exception translation code should be made more robust against such paths.
[1] https://github.com/graalvm/labs-openjdk-17/blob/f6b18b596fa5acb1ab7efa10e284d106669040a6/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java#L237
[2] https://github.com/graalvm/labs-openjdk-17/blob/f6b18b596fa5acb1ab7efa10e284d106669040a6/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/TranslatedException.java#L153
- backported by
-
JDK-8298830 [JVMCI] HotSpotJVMCIRuntime.encodeThrowable should not throw an exception
-
- Resolved
-
-
JDK-8299823 [JVMCI] HotSpotJVMCIRuntime.encodeThrowable should not throw an exception
-
- Resolved
-
- links to
-
Commit openjdk/jdk17u-dev/339b93b8
-
Commit openjdk/jdk/952e1005
-
Review openjdk/jdk17u-dev/1033
-
Review openjdk/jdk/11286
(1 links to)