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