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

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Mon Oct 16 20:23:07 UTC 2017


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