RFR: 8203319: JDK-8201487 disabled too much queue balancing

Thomas Schatzl thomas.schatzl at oracle.com
Wed May 30 17:49:16 UTC 2018


Hi,

On Wed, 2018-05-30 at 13:33 -0400, Kim Barrett wrote:
> Please review this change to the ReferenceProcessor's test for
> whether
> to balance a set of queues before processing them with multiple
> threads.  The change to that test made by JDK-8201487 doesn't peform
> balancing for some (potential, see Testing below) states where not
> doing so will result in some discovered References not being
> processed.  In particular, there are cases where we must ignore
> -XX:-ParallelRefProcBalancingEnabled and balance anyway.
> 
> We also now avoid balancing in some cases where we know the set is
> already balanced, even with -XX:+ParallelRefProcBalancingEnabled.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8203319
> 
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8203319/open.00/
> 
> Testing:
> Mach5 tier{1,2,3}, hs-tier{4,5}
> 
> I tried to write a test directed at the problematic cases, but
> couldn't find a way to produce a setup with
>   1 < # of processing threads < # of discovery theads
> 
> In particular, a configuration with ParallelGCThreads < ConcGCThreads
> is disallowed by option checking, so the VM won't even start with
> such a configuration.  So it seems the problematic cases described in
> the bug report can't currently arise in practice.  

Due to UseDynamicNumberOfGCThreads the number of active threads for the
work queue may be < ConcGCThreads. Just run on a small heap (iirc it
selects 1 thread per 32MB of heap) on a large machine.

> However, that will change with JDK-8043575, where a reduced number of
> processing threads may be selected.
> 

That change will make it more likely, yes.

Looks good. Thanks for fixing this.

Thomas



More information about the hotspot-gc-dev mailing list