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

David Holmes david.holmes at oracle.com
Mon Apr 2 20:34:25 UTC 2018


Hi Dan,

Only query, that I overlooked before is:

  void TracingExport::set_sampler_thread(Thread * thread) {
-  _sampler_thread = thread;
+  OrderAccess::release_store_fence(&_sampler_thread, thread);
  }

why a release_store_fence() rather than simple release_store()?

Thanks,
David

On 3/04/2018 1:11 AM, Daniel D. Daugherty wrote:
> Greetings,
> 
> This fix has been revised due to additional testing and due to
> feedback from David H.
> 
> Here's the incremental webrev:
> 
> http://cr.openjdk.java.net/~dcubed/8200374-webrev/1_for_jdk_hs_open.inc/
> 
> And here's the full webrev:
> 
> http://cr.openjdk.java.net/~dcubed/8200374-webrev/1_for_jdk_hs_open.full/
> 
> 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
> process...
> 
> Thanks, in advance, for any comments, suggestions, or feedback.
> 
> Dan
> 
> 
> On 3/28/18 9:52 PM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> I have a (mostly) small enhancement for Thread-SMR:
>>
>> JDK-8200374 Add ThreadsSMRSupport::verify_hazard_pointer_scanned() to 
>> verify threads_do()
>> https://bugs.openjdk.java.net/browse/JDK-8200374
>>
>> Here's the webrev URL:
>>
>> http://cr.openjdk.java.net/~dcubed/8200374-webrev/0_for_jdk_hs_open/
>>
>> 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()
>> https://bugs.openjdk.java.net/browse/JDK-8199813
>>
>> 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_*()
>>   functions.
>> - 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
>> ThreadsSMRSupport::verify_hazard_pointer_scanned().
>>
>> Thanks, in advance, for any comments, suggestions, or feedback.
>>
>> Dan
>>
>>
> 


More information about the hotspot-runtime-dev mailing list