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