RFR (S) 5103339: Strengthen NoSafepointVerifier

Robbin Ehn robbin.ehn at oracle.com
Tue Aug 6 07:45:02 UTC 2019

Hi Coleen,

On 2019-08-05 18:00, coleen.phillimore at oracle.com wrote:
> Summary: Add NSV check at possible safepoint transition or places that could 
> take out locks.  Consolidate with clearing unhandled oops.

I would like us to instead poison the poll check it's self.
So any polls between A and B will just assert directly.
It doesn't matter if there is actually a safepoint or not, the poll is not
allowed. check_for_valid_safepoint_state is also only checked for safepoint,
not handshakes. Handshakes should not be allowed either.

bool SafepointMechanism::local_poll_armed(JavaThread* thread) { 

   assert(thread->poll_allowed(), "Hit poll site");

What you think?


> This change checks for NoSafepointVerifier no_safepoint_counts at possible 
> safepoints.  The starting set is at transitions, and in the "else" clauses where 
> CHECK_UNHANDLED_OOPS were clearing unhandled oops. Some of these were removed 
> because they weren't places with possible safepoints, so were wrong.
> The unhandled oops clearing and no_safepoint counter check are now done in the 
> same function.  MemAllocator -> check_for_valid_allocation_state calls 
> check_for_valid_safepoint_state which calls check_possible_safepoint.
> Calls to check_possible_safepoint are in DEBUG_ONLY when Thread::current() is 
> called.
> I had to remove it from the else clause in JvmtiThreadState because it's called 
> from a place that cannot safepoint (see vtableStubs.cpp).
> os.cpp ResourceMark needed for debugging.
> Tested with tier1 on all Oracle platforms, and tier 1-3 on linux-x64-debug.
> open webrev at http://cr.openjdk.java.net/~coleenp/2019/5103339.01/webrev
> bug link https://bugs.openjdk.java.net/browse/JDK-5103339
> Thanks,
> Coleen

More information about the hotspot-runtime-dev mailing list