[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-gc-dev
Subject:    Re: RFR: 8257774: G1: Trigger collect when free region count drops below threshold to prevent evacua
From:       Kirk Pepperdine <kirk () kodewerk ! com>
Date:       2021-05-31 21:07:32
Message-ID: D26DD5BD-C0E0-4ED8-86C8-517E80D188ED () kodewerk ! com
[Download RAW message or body]

Hi Stefan,


> 
> The failing test made me look a bit more at the logs when running with this feature \
> and I found at least one thing I think we need to fix.  
> What I did was to run SPECjbb2015 with a fixed injection-rate and and with tweaked \
> parameters to force a bit more live objects. Running this with an 8g heap was fine \
> and I saw no "preventive" GCs. Turning the heap size down to 6gb the preventive GCs \
> started to show and we do a lot more GCs with this patch than without, but looking \
> at the total GC time it is pretty similar to before. So not sure how much to care \
> about this. 
> What I think we should change, or at least discuss is the fact that we now get:
> 
> [340,066s][info][gc             ] GC(3148) Pause Full (G1 Preventive Collection) \
> 6091M->3082M(6144M) 726,846ms 
> A "preventive" Full GC looks a bit strange to me, I mean the Full GC occurs because \
> we failed not prevent it. So I think we should avoid using this GC cause for Full \
> collections. What do others think?

This is certainly not preventing a full GC implying that the name is misleading.

At 8G, I'm not sure that I care all that much about a full collection being triggered \
but it's at a threshold where I'm going to take notice. At issue is… it's very \
unlikely that we'd want to see a full collection when heaps get bigger than this. I'd \
much rather set a larger reserve or take other measures to prevent the failure rather \
than endure the penalty of a full collection.

Kind regards,
Kirk


[prev in list] [next in list] [prev in thread] [next in thread]