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 graal-dev
mailing list