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

Thomas Schatzl thomas.schatzl at oracle.com
Tue Jun 5 10:16:25 UTC 2018


Hi,

On Mon, 2018-06-04 at 14:31 -0400, Kim Barrett wrote:
> > On May 31, 2018, at 3:34 PM, Kim Barrett <kim.barrett at oracle.com>
> > wrote:
> > 
> > > On May 31, 2018, at 4:41 AM, Stefan Johansson <stefan.johansson at o
> > > racle.com> wrote:
> > > 
> > > 
> > > 
> > > On 2018-05-30 19:33, 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/
> > > 
> > > Looks good,
> > > Stefan
> > 
> > Thanks, Stefan.
> 
> The new need_balance_queues function has an optimization to avoid
> balancing in a case where we already know the queues are balanced.
> This assumes it's being called for initial balancing after discovery,
> and not for some re-balancing after a processing phase.  But that's
> problematic for JDK-8043575 (recently RFR'ed).  And if we're already
> balanced, balance_queues doesn't have very much to do.  (And
> eventually the optimization would be rendered moot anyway, by the
> elimination of balancing; see JDK-8202328.)  So I'm taking that bit
> out.
> 
> New webrevs:
> full: http://cr.openjdk.java.net/~kbarrett/8203319/open.01/
> incr: http://cr.openjdk.java.net/~kbarrett/8203319/open.01.inc/

  still good.

Thomas




More information about the hotspot-gc-dev mailing list