When selecting collection set candidates for reclamation in old gen there is this limit on the regions dictated by G1HeapWastePercent: i.e. G1 may leave G1HeapWastePercent unreclaimed space after garbage collection even if there is enough time left.

The rationale is that such regions are particularly costly to reclaim, and the prediction too unreliable, so do not reclaim them.

So during old region selection we loop over all candidate regions, and should stop if the percentage of reclaimable space is below that threshold.

With JDK-8218668 the code changed significantly, separating determining the collection set regions to evacuate next and collection set candidate management.

Which means that that loop does not update the currently amount of reclaimable bytes in that loop any more. So that threshold is not used as it has been before.

Before the JDK-8218668 change, G1CollectionSet::finalize_old_part() determined the old gen regions in the collection set. The loop starts at https://hg.openjdk.java.net/jdk/jdk/rev/c4f16445675a#l3.223. It calls the add_as_old/optional() methods that call pop_front(), which immediately removed that candidate from the candidate list and updated the reclaimable bytes.

With JDK-8218668, the actual removal of selected regions from the candidate list happens later outside the loop and the update to reclaimable bytes does not occur in the loop any more.

Which means that that condition is effectively only checked at the start of the method.

There is another detail to consider here: with optional regions, that consideration of HeapWastePercent does not really make a difference - if there is time left after GC g1 will continue evacuating these "expensive" regions anyway, countering the purpose of that flag. So maybe it is not needed any more.

Another option than restoring old behavior is just acknowledging the current behavior (and moving the code out of the loop as it is constant as found by [~iwalulya]).

We agreed in an internal discussion to remove that check from region selection completely - the rationale is that when we already started a (mixed) gc, we should evacuate as much as possible. So that check may at least moved out of the loop or completely removed.