On Mon, 26 Jun 2023 07:59:17 GMT, David Holmes <dhol...@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
