RFR: 8254623: gc/g1/TestHumongousConcurrentStartUndo.java still fails sometimes [v2]

[Thomas Schatzl]

> Hi all,
> 
>   can I have reviews for this change of the gc/g1/TestHumongousConcurrentStartUndo.java test to make it even more
>   resilient to timing?
> 
> Previously the test tried to create a stable initial condition by performing a full gc before that test step, but the
> problem is about when the first concurrent mark happens while building up the large set of humongous object kept alive:
> if it happens too early, and the concurrent undo operation takes too long, the next concurrent start will just be
> another undo because the large set of humongous objects will already be unreferenced and may as well cause a concurrent
> undo and not a concurrent mark.  The solution I came up with is that *after* creating all the humongous objects of the
> large set trigger an extra concurrent mark (and wait for its completion). That one (or some before) must have been a
> concurrent mark because at least at that point the heap must have been occupied by more than the IHOP value.  Testing:
> 2k iterations on failing platform (always aarch64-linux) without issues.  Thanks,
>   Thomas

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  kbarrett review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/632/files
  - new: https://git.openjdk.java.net/jdk/pull/632/files/bcc33c20..718347ca

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

  Stats: 68 lines in 1 file changed: 34 ins; 17 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/632.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/632/head:pull/632

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