RFR: 8297431: [JVMCI] HotSpotJVMCIRuntime.encodeThrowable should not throw an exception [v2]
Tom Rodriguez
never at openjdk.org
Wed Nov 23 17:01:29 UTC 2022
On Wed, 23 Nov 2022 10:54:31 GMT, Doug Simon <dnsimon at openjdk.org> wrote:
>> 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`](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) and [`TranslatedException.encodeThrowable`](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) is designed to handle translation failures by falling back to non-allocating code. However, we still occasionally see [an OOME that breaks the translation mechanism](https://github.com/oracle/graal/issues/5470#issuecomment-1321749688). One speculated possibility for this is an OOME re-materializing oops d
uring a deoptimization causing an unexpected execution path. This PR increases the robustness of the exception translation code in light of such issues.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
>
> add more context when possible to exception translation errors
Marked as reviewed by never (Reviewer).
-------------
PR: https://git.openjdk.org/jdk/pull/11286
More information about the hotspot-compiler-dev
mailing list