RFR (S): 8185580: Refactor Threads::possibly_parallel_oops_do() to use Threads::parallel_java_threads_do()
Roman Kennke
rkennke at redhat.com
Tue Oct 17 04:55:31 UTC 2017
Am 17.10.2017 um 05:33 schrieb David Holmes:
> Hi Roman,
>
> On 12/10/2017 5:30 AM, Roman Kennke wrote:
>> 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.
>
> "should" be okay? It's not at all clear to me what processing the
> VMThread where previously it was not processed, will actually do ??
It ensures that both parallel thread iteration routines are doing the
same, and thus claim the same threads, which is later
assert_all_threads_are_claimed(). If we don't do this consistently, we
throw off the thread claiming mechanics.
>
>> I renamed the method to parallel_threads_do() to reflect that it not
>> only does the Java threads.
>
> Given it takes an is_par argument it really should be
> possibly_parallel_threads_do()
Ok. Differential diff:
http://cr.openjdk.java.net/~rkennke/8185580/webrev.01.diff/
<http://cr.openjdk.java.net/%7Erkennke/8185580/webrev.01.diff/>
Full webrev:
http://cr.openjdk.java.net/~rkennke/8185580/webrev.01/
<http://cr.openjdk.java.net/%7Erkennke/8185580/webrev.01/>
Good?
Roman
More information about the hotspot-runtime-dev
mailing list