RFR (S): 8185580: Refactor Threads::possibly_parallel_oops_do() to use Threads::parallel_java_threads_do()

Roman Kennke rkennke at redhat.com
Mon Oct 16 20:26:58 UTC 2017


Thank you!

Roman

>
> This looks good to me.  I will sponsor it for you.   Maybe Dan can 
> provide a second review since he tracked down the bug caused by the 
> former inconsistency of these functions.
> thanks,
> Coleen
>
> On 10/16/17 12:19 PM, Roman Kennke wrote:
>> Am 11.10.2017 um 21:30 schrieb Roman Kennke:
>>> This is a follow-up to my earlier safepoint parallel cleanup work.
>>>
>>> Currently we have 2 places where we apply the parallel claiming 
>>> protocol when iterating threads, that is 
>>> Threads::parallel_java_threads_do() and 
>>> Threads::possibly_parallel_oops_do(). In order to avoid code 
>>> duplication, the latter should call the former, using a private 
>>> ThreadClosure. We already had one bug (JDK-8185273) that was caused 
>>> by an inconsistency between the two.
>>>
>>> The only other user of parallel_java_threads_do() already filters 
>>> out any non-Java-threads, which means that doing the extra 
>>> processing of the VMThread should be ok. I renamed the method to 
>>> parallel_threads_do() to reflect that it not only does the Java 
>>> threads.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~rkennke/8185580/webrev.00/ 
>>> <http://cr.openjdk.java.net/%7Erkennke/8185580/webrev.00/>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8185580
>>>
>>> Tested successfully by running hotspot_gc tests, which should cover 
>>> most if not all uses of those methods.
>>>
>>> Roman
>>
>> Ping?
>>
>> Roman
>>
>



More information about the hotspot-runtime-dev mailing list