RFR: 8312116 GenShen: make instantaneous allocation rate triggers more timely [v3]

[Kelvin Nilsen]

> When heuristics fail to trigger because an instantaneous "allocation spike" is not so large as to consume all available memory before GC completes, this assessment is based on an assumption that the allocation rate remains constant, and it ignores the time that will be lost due to the _interval between consecutive allocation spike measurements.
> 
> This PR watches for "acceleration" of allocation rates.  When acceleration of allocation is detected in 3 consecutive allocation spike measurements, it calculates a best-fit curve (assuming constant acceleration) and predicts the memory to be consumed during the time that spans both the next sample interval and the GC effort that follows it.  If the memory to be allocated according to anticipated acceleration of allocations during this time span exceeds what is available, we trigger immediately.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Checkpoint this code so we can pursue suspected deadlock JBS issue
  
  I'm filing a new ticket to explore deadlock issue related to
  ShenandoahControlThread::_regulator_lock.  The issue was last observed
  on this branch.  New changes that we are about to integrate will likely
  make it much more difficult to reproduce the issue.

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/327/files
  - new: https://git.openjdk.org/shenandoah/pull/327/files/734ca370..d6bc97eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=327&range=02
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=327&range=01-02

  Stats: 53 lines in 4 files changed: 48 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/shenandoah/pull/327.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/327/head:pull/327

PR: https://git.openjdk.org/shenandoah/pull/327