[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-dev
Subject:    RFC: 8249585: Define a NoAsyncExceptionCheckVerifier utility
From:       David Holmes <david.holmes () oracle ! com>
Date:       2020-08-11 10:14:41
Message-ID: 8913f9f7-d34a-fb0a-1c85-d3b85286bc1b () oracle ! com
[Download RAW message or body]

RFE: https://bugs.openjdk.java.net/browse/JDK-8249585
webrev: http://cr.openjdk.java.net/~dholmes/8249585/webrev/

I've been working around async exception handling issues over the past 
couple of months and the question that keeps cropping up is "will this 
code path reach any code that might install a pending async exception?". 
So this is an attempt to create such a little utility. Similar to 
NoSafepointVerifier the NoAsyncExceptionCheckVerifier can be used to 
"ensure" that a section of code cannot lead to a check for, and thus 
installation of, a pending async exception.

The actual code the for NAECV and the check is quite trivial. In 
addition the webrev shows a number of initial experiments with placing 
the NAECV in some interesting code paths:

- when code will use the CHECK_AND_CLEAR macro to clear all exceptions
   - In this case async exceptions should not just be cleared, but if we 
know they can't be installed then we don't have to worry about them.

- In the ThreadBlockInVM thread-state transition (entry and exit)

- Locking a Mutex (less interesting but a low-level bit of functionality 
you may want to know is "safe" wrt. async exception processing)


Please ignore the addition of the NoSafepointVerifier in 
src/hotspot/share/runtime/biasedLocking.cpp - that snuck into the 
initial webrev accidentally.

Now this utility is only as good as the code coverage that is applied to 
it. We might run a thousand tests, that always follow the same code path 
from the NAECV and so it never fires. But that doesn't mean it can't 
fire. So we really want to hammer this in testing if we want to be 
confident that there really can't be any async exceptions and so we can 
code (in product mode) accordingly. So far I've tested the above with 
tier 1-3 and with tiers 4-6 in progress.

Now it may be that we can't use this to gain sufficient confidence to 
guide product mode code. Hence this is a RFC not RFR. This might just be 
an interesting experiment with no usable outcome outside individual 
experimentation.

Comments welcome.

Thanks,
David
[prev in list] [next in list] [prev in thread] [next in thread]