RFR(S): 8200374: Add ThreadsSMRSupport::verify_hazard_pointer_scanned() to verify threads_do()

Daniel D. Daugherty daniel.daugherty at oracle.com
Thu Mar 29 01:52:33 UTC 2018


I have a (mostly) small enhancement for Thread-SMR:

JDK-8200374 Add ThreadsSMRSupport::verify_hazard_pointer_scanned() to 
verify threads_do()

Here's the webrev URL:


This is Erik O's improvement on the assertion added by the following
bug fix (with some minor tweaking done by me):

JDK-8199813 SIGSEGV in ThreadsList::includes()

Summary of the changes:

- Replace the assertion that I added in JDK-8199813 with a closure
   based function that verifies the threads_do() contract depended
   on by Thread-SMR.
- Add ThreadsSMRSupport::verify_hazard_pointer_scanned() to verify
   that the calling thread's hazard pointer is scanned by threads_do().
   The new function is called from both ThreadsSMRSupport::acquire_*()
- Refactor the non-JavaThread part of Threads::threads_do() into
   Threads::non_java_threads_do() so that the non-JavaThread part
   can also be called by other threads_do() functions. Yes, the
   Threads::threads_do() contract is still to scan every thread in
   the system.
- Add hooks for a "tracing sampler thread" to be optionally scanned
   by Threads::non_java_threads_do().

This fix has gone thru a couple of Mach5 builds-tier1, jdk-tier[1-3],
and hs-tier[1-3] runs. I've also started my usual 24+ hour Thread-SMR
stress testing run on my Solaris-X64 server.

Just to be extra sure, I backed out the fix from JDK-8199813 to
JavaThread::verify_not_published() (which started this round of
Thread-SMR fixes) and we catch the issue in the new function

Thanks, in advance, for any comments, suggestions, or feedback.


More information about the hotspot-runtime-dev mailing list