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

[Kim Barrett]

> On Jun 5, 2018, at 6:16 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> 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

Thanks Stefan and Thomas.