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

[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 ??

> 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()

Thanks,
David

> 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