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.
E.g.
bool SafepointMechanism::local_poll_armed(JavaThread* thread) {
assert(thread->poll_allowed(), "Hit poll site");
What you think?
/Robbin
>
> 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