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