RFR: 8133051: Concurrent refinement threads may be activated and deactivated at random

[Kim Barrett]

> On Apr 4, 2016, at 2:48 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
> Please review this change to the G1 concurrent refinement thread
> controller.  […] It also addresses
> delayed activation due to mis-configuration of the dirty card queue
> set's notification mechanism.
> 
> This change continues to use (more or less) the existing control
> model, only avoiding obviously wasted effort or undesirable delays.
> Further enhancements to the control model will be made under
> JDK-8137022 or subtasks from that.
> 
> - As part of the above, changed G1ConcRefinementThresholdStep to have
> a minimum value of one, a default value of 2, and to be used to
> determine a lower bound on the thread activation step size.  A larger
> step size makes it less likely a thread will be woken up and discover
> other threads have already completed the work "allocated" to it.  Too
> large a minimum may overly restrict the number of refinement threads
> being activated, leading to missed pause targets.
> 

I've been so focused on the many-refinement-thread problems that I
forgot to consider the small-number-of-threads case here.  Please hold
off on reviewing...