If G1 Full GC uses more than one worker then the set of live objects is potentially distributed into more than one region. It is possible that in this case one of the regions has less than G1MixedGCLiveThresholdPercent live objects and therefore gets selected for the collection set of a later gc. This causes the test to fail.

On PPC the page size is 64k. On such a system the test is executed with 32M heap even though -Xms10m is given because for every page in the CardTable there has to be corresponding heap space (see CardTable::ct_max_alignment_constraint()). In that setup the test TestMixedGCLiveThreshold fails due to the issue discribed above.

The issue can be reproduced on x86 if it is run with -Xms32m. My system has 20 cores. Maybe a higher number of cores is a prerequisite too.

I have build and run the testcase with -XX:G1MixedGCLiveThresholdPercent=25.
The output is attached as TestMixedGCLiveThreshold_<platform>.log

TestMixedGCLiveThreshold_linuxppcle.log shows:

- L18: Heap size is 32m
- L67: 2 workers for full gc
- L80: Live data was distributed to 2 old regions
- L127: One of the old regions has 248k live bytes. This is less than 25% (256k) so it is selected which is unexpected by the test.


TestMixedGCLiveThreshold_linuxx86_64.log shows:

- L18:Hheap size is 10m
- L67: 1 worker for full gc
- L80: Live data was collected into 1 old region
- L127: That region has 591k live bytes and therefore is not selected.

The issue can be avoided if -XX:ParallelGCThreads=1 is given as L128 of attachment TestMixedGCLiveThreshold_linuxppcle_ParallelGCThreads_1.log shows.