RFR: 8369111: G1: Determining concurrent start uses inconsistent predicates

[Thomas Schatzl]

Hi all,

  please review this change that fixes an inconsistency between requesting a concurrent start garbage collection during humongous object allocation and then actually starting it.

I.e. in `G1CollectedHeap::attempt_allocation_humongous` we check whether the allocation would cross the IHOP threshold taking the current allocation into account, and if so, see if G1 should start a concurrent marking, eventually starting a GC pause.

That GC pause did not take the prospective allocation into account, so we could do that GC for nothing (i.e. not start a concurrent marking although we already knew that the allocation would cause one).

This, in conjunction with JDK-8368959 can cause hundreds of extra GCs for the test in the CR (without eager reclaim of humongous arrays with references); otherwise it could cause the marking starting too late.

There is a second bug in the calculation whether G1 crossed the threshold: for humongous objects it only takes the actual size into account, not the size that is needed for allocating it. The same issue existed for determining to start a concurrent mark after any other collection too.

The change also tries to unify naming of the parameter to pass the allocation size (`alloc_word_size` -> `allocation_word_size`) and the parameter order where this size is passed along in multiple related methods.

Testing: mentioned test case now behaving correctly, tier1-5

Thanks,
  Thomas

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

Commit messages:
 - 8369111

Changes: https://git.openjdk.org/jdk/pull/27789/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27789&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369111
  Stats: 111 lines in 9 files changed: 35 ins; 8 del; 68 mod
  Patch: https://git.openjdk.org/jdk/pull/27789.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27789/head:pull/27789

PR: https://git.openjdk.org/jdk/pull/27789