RFR (M): 8136681: Factor out IHOP calculation from G1CollectorPolicy

[Thomas Schatzl]

Hi all,

  after Sangheon's review of 8136679 I looked for similar issues
(division by zero mainly), and in case of JDK-8136681 decided to add an
assert that verifies that _target_occupancy is always > 0 to make clear
that that cannot happen for the "static" IHOPControl.

New webrevs:
http://cr.openjdk.java.net/~tschatzl/8136681/webrev.0_to_1/ (diff)
http://cr.openjdk.java.net/~tschatzl/8136681/webrev.1/ (new)

Thanks,
  Thomas

On Thu, 2015-11-05 at 10:42 +0100, Thomas Schatzl wrote:
> Hi all,
> 
>   can I have reviews for this preparatory change for adaptive IHOP
> sizing, that factors out the IHOP calculation from G1Collectorpolicy
> into separate classes?
> 
> So instead of having this single line at G1CollectorPolicy:944
> 
>  944   size_t marking_initiating_used_threshold =
>  945     (_g1->capacity() / 100) * InitiatingHeapOccupancyPercent;
> [...]
>  949   if ((cur_used_bytes + alloc_byte_size) >
> marking_initiating_used_threshold) {
> 
> that determines whether marking should start, that decision is
> externalized into a G1IHOPControl class with a
> get_conc_mark_start_threshold() method.
> 
> This allows flexible replacement of the IHOP calculation algorithm
> depending on some switch using a factory method. 
> 
> In addition to that, this change tracks and passes several information
> IHOPControl instances need, like allocation between gcs, mutator time
> from initial mark to the first mixed gc, and others.
> 
> The change also adds some test.
> 
> It depends on all my recent patches in this area, namely:
> 8140689: Skip last young-only gc if nothing to do in the mixed gc phase
> 8140597: Forcing an initial mark causes G1 to abort mixed collections
> 8140585: PLAB statistics are flushed too late
> 8139874: After G1 Full GC, the next GC is always a young-only GC
> 8138740: Start initial mark right after mixed GC if needed
> 
> The problem is that it expects (and verifies) that the GC pauses are
> executed in the "correct" order.
> 
> There is no behavioral change in this CR.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8136681
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8136681/webrev/
> Testing:
> jprt, vm.gc, lots of manual testing, new VM test
> 
> Note that SQE will create additional tests.
> 
> Thanks,
>   Thomas
>