RFR: 8240556: Abort concurrent mark after effective eager reclamation of humongous objects [v2]

[Thomas Schatzl]

> Hi all,
> 
>   please review this change that implements concurrent mark abort as proposed by Liang Mao from Alibaba.
> 
> Basically, if at the end of the concurrent start pause we notice that we went below the IHOP threshold (and it has been
> a concurrent start pause caused by humongous allocation), instead of scheduling a mark operation, we schedule a
> "concurrent undo" operation that undoes the changes.  Regarding the removal of the
> test/hotspot/jtreg/gc/stress/jfr/TestStressBigAllocationGCEventsWithG1.java test: it only ever accidentally worked in
> G1. G1 never sent the AllocationRequiringGC events for GCs caused by going over the IHOP threshold for humongous
> allocations that the test actually expects.  That test previously only worked because G1 could not reclaim the
> humongous objects fast enough so crossing the IHOP threshold causes a full concurrent mark. Allocations during that
> concurrent mark do not cause a GC that can reclaim these objects, so ultimately some young GC that sends the
> AllocationRequiringGC event will be sent.  With concurrent undo this is not guaranteed any more, i.e. only in
> environments where concurrent undo is slow (and we'll improve it soon) this test works.  The test is too timing
> dependent, and checking for the wrong thing in this case, so removing it.  Testing: tbd.

Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since
the last revision:

 - reviews sjohanns and ayang; merged Command and Status plus cleanup
 - Remove test that only accidentally worked: G1 never sent the AllocationRequiringGC
   event for GCs caused by going over the IHOP threshold for humongous allocations.
   
   That test previously only worked because G1 could not reclaim the humongous objects
   fast enough so crossing the IHOP threshold causes a full concurrent mark. Allocations
   during that concurrent mark do not cause a GC that can reclaim these objects, so
   ultimately some young GC that sends the AllocationRequiringGC event will be sent.
   
   With concurrent undo this is not guaranteed any more, i.e. only in environments where
   concurrent undo is slow (and we'll improve it soon) this test works.
   
   The test is too timing dependent, so removing it.
 - Fixed test
 - Initial import

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/177/files
  - new: https://git.openjdk.java.net/jdk/pull/177/files/6ea4a1f5..bf7d3333

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=177&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=177&range=00-01

  Stats: 8375 lines in 270 files changed: 4551 ins; 3050 del; 774 mod
  Patch: https://git.openjdk.java.net/jdk/pull/177.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/177/head:pull/177

PR: https://git.openjdk.java.net/jdk/pull/177