RFR: 8297431: [JVMCI] HotSpotJVMCIRuntime.encodeThrowable should not throw an exception

Tom Rodriguez never at openjdk.org
Tue Nov 22 16:32:20 UTC 2022


On Tue, 22 Nov 2022 14:30:01 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 du
 ring a deoptimization causing an unexpected execution path. This PR increases the robustness of the exception translation code in light of such issues.

src/hotspot/share/jvmci/jvmciEnv.cpp line 321:

> 319:       jlong buffer = (jlong) NEW_RESOURCE_ARRAY_IN_THREAD_RETURN_NULL(THREAD, jbyte, buffer_size);
> 320:       if (buffer == 0L) {
> 321:         decode(THREAD, runtimeKlass, 0L);

Can we add an argument so that each of these call sites reports a unique message?  Should we get the class name from the pending exception and include that as well?  I think we should include enough breadcrumbs for future failures in the this path that we might have a better guess what's happening.

-------------

PR: https://git.openjdk.org/jdk/pull/11286


More information about the hotspot-compiler-dev mailing list