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

[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.

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

Commit messages:
 - Remove test that only accidentally worked: G1 never sent the AllocationRequiringGC
 - Fixed test
 - Initial import

Changes: https://git.openjdk.java.net/jdk/pull/177/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=177&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8240556
  Stats: 336 lines in 12 files changed: 216 ins; 66 del; 54 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