RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in ExceptionTranslation::doit [v2]
Doug Simon
dnsimon at openjdk.org
Mon Jun 26 13:10:05 UTC 2023
On Mon, 26 Jun 2023 07:59:17 GMT, David Holmes <dholmes at openjdk.org> wrote:
> if the first decode encounters a class initialization error then it will just return with the exception pending and no decoding will actually have occurred
That's fine - if VMSupport fails class initialization, then no "rich" decoding can occur (by definition) and so throwing the clinit error is the best we can do.
> If we get to the encode first and it encounters an initialization error it will still attempt to do a decode that must in turn fail
You have to keep in mind that `encode` and `decode` are called in different runtimes. If encoding an exception in the HotSpot runtime fails (e.g. due to an OOME calling `VMSupport.<clinit>` in the HotSpot heap), then it's still fine to try call `VMSupport.decode` in the libgraal runtime. If `VMSupport.decode` in the libgraal runtime also fails, then it throw the exception describing the secondary failure. There's simply no way to guarantee all info is shown when secondary issues occur during exception handling.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/14641#issuecomment-1607433634
More information about the hotspot-dev
mailing list