RFR: 8151670: Unexpected concurrent refinement deactivation and reactivation

[Kim Barrett]

> On Mar 22, 2016, at 8:52 AM, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:
> On 2016-03-21 21:39, Kim Barrett wrote:
>>> On Mar 21, 2016, at 4:15 AM, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:
>>> In
>>> 111 void ConcurrentG1RefineThread::run_service() {
>>> 
>>> It took me a while to notice the "break" after the call to apply_closure_to_completed_buffer.
>>> Perhaps there is a way to restructure the control flow to make this a bit more obvious?
>>> 
>>> One variant could be to save the result of apply_closure_to_completed_buffer in a boolean and check boolean in the while() loop header.
>> 
>> Would it help to change the comment to be more prescriptive?  Such as
>> 
>>   Deactivate because number of buffers fell below threshold.
>> 
>> Or split the if-then-else-if into two distinct ifs?  I'm not keen on
>> introducing a boolean flag whose assignment is far away from its use,
>> as would be the case if it were checked in the while loop test.
> 
> Splitting it into distinct ifs would be ok with me.

I rearranged the code a bit.  Hope it helps.  New webrev coming soon.