RFR: 8335553: [Graal] Compiler thread calls into jdk.internal.vm.VMSupport.decodeAndThrowThrowable and crashes in OOM situation [v2]

David Holmes dholmes at openjdk.org
Wed Jul 10 06:23:15 UTC 2024


On Wed, 10 Jul 2024 05:48:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I'm not so sure this is in fact a bug. If we are throwing with a cause, but we can't actually throw and so will do vm_exit, then the exception of interest is the cause not the more generic exception that would otherwise contain the cause.
>> 
>> Though I have to wonder why there is not an original `_throw` for the "cause" exception, that would have triggered the special_exception handling anyway?
>
> Though I see this is inconsistent with `Exceptions::_throw_msg_cause`

Okay I think I see how the logic works. If we were going to abort we would never reach `_throw_cause` as the initial `_throw` would have exited. But for the `!thread->can_call_Java()` case the original `_throw` would replace the intended real exception with the dummy `VM_exception()`, which is then "caught" and we try to replace with a more specific exception to be thrown via `throw_cause`, which will again replace whichever exception is requested with the dummy `VM_exception()` - so the end result is we will throw the dummy regardless of whether the cause or wrapping exception is specified. So your fix here makes sense.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20083#discussion_r1671680471


More information about the core-libs-dev mailing list