RFR: 8240556: Abort concurrent mark after effective eager reclamation of humongous objects

[Thomas Schatzl]

Hi,

On 16.09.20 18:05, Thomas Schatzl wrote:
> Hi all,
> 
>    please review this change that implements concurrent mark abort as proposed by Liang Mao from Alibaba.
> 
> Basically, if at the end of the concurrent start pause we notice that we went below the IHOP threshold (and it has been
> a concurrent start pause caused by humongous allocation), instead of scheduling a mark operation, we schedule a
> "concurrent undo" operation that undoes the changes.
> 
> Regarding the removal of the test/hotspot/jtreg/gc/stress/jfr/TestStressBigAllocationGCEventsWithG1.java test: it only
> ever accidentally worked in G1. G1 never sent the AllocationRequiringGC events for GCs caused by going over the IHOP
> threshold for humongous allocations that the test actually expects.
> 
> That test previously only worked because G1 could not reclaim the humongous objects fast enough so crossing the IHOP
> threshold causes a full concurrent mark. Allocations during that concurrent mark do not cause a GC that can reclaim
> these objects, so ultimately some young GC that sends the AllocationRequiringGC event will be sent.
> 
> With concurrent undo this is not guaranteed any more, i.e. only in environments where concurrent undo is slow (and
> we'll improve it soon) this test works.
> 
> The test is too timing dependent, and checking for the wrong thing in this case, so removing it.

We could also change that GC pause to send the AllocationRequiringGC 
event in case of these GCs caused by crossing the IHOP threshold. Not 
sure if that is in the intent of the AllocationRequiringGC event.

That GC is not strictly required (we are not out of eden) but a "random" 
proactive GC. Adding jfr-dev label for their comments.

Thanks,
   Thomas