This is reproducible using `tomcat`, `jython` and other benchmarks from the Dacapo suite. It seems to happen in the first few cycles, but I have also seen it happen on the 7th cycle. It is evident in the logs as:
```
[189.667s][trace][gc,ergo,cset ] GC(7) Added young regions to CSet. Eden: 64 regions, Survivors: 0 regions, predicted eden time: 342093961900175.06ms, predicted base time: 181.72ms, target pause time: 200.00ms, remaining time: 0.00ms
```

The unrealistically high time prediction causes G1 to not select any old regions for mixed collections.

Possibly caused by this change: https://github.com/openjdk/jdk/pull/16344/files#diff-c9ffd02739befc1333f3d79c5b9dd13dd443b28db1a0172081c41e5750c97dd8R1102

Which seems to subvert the boundary checking here:
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/g1/g1SurvRateGroup.hpp#L78

In the cases I've seen, `count` has been equal to `G1SurvRateGroup::_stats_arrays_length`, so `count -1` ducks under the check that `age < _stats_arrays_length`.