RFR(S): 8200374: Add ThreadsSMRSupport::verify_hazard_pointer_scanned() to verify threads_do()
Daniel D. Daugherty
daniel.daugherty at oracle.com
Mon Apr 2 15:11:16 UTC 2018
This fix has been revised due to additional testing and due to
feedback from David H.
Here's the incremental webrev:
And here's the full webrev:
My usual Thread-SMR stress testing on my Solaris-X64 is still running;
so far there has been only one unrelated intermittent test failure. The
Mach5 builds-tier1, jdk-tier[1-3], and hs-tier[1-3] run is still in
Thanks, in advance, for any comments, suggestions, or feedback.
On 3/28/18 9:52 PM, Daniel D. Daugherty wrote:
> 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