RFR: 8257774: G1: Trigger collect when free region count drops below threshold to prevent evacuation failures [v9]

Kirk Pepperdine kirk at kodewerk.com
Fri Jun 4 04:09:52 UTC 2021


Traditionally in the logs you would see that the current collection is “closed out” and a new record is started for the “new” full collection.

Kind regards,
Kirk



> On Jun 1, 2021, at 1:29 PM, Aditya Mandaleeka <adityam at openjdk.java.net> wrote:
> 
> On Mon, 31 May 2021 14:44:50 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:
> 
>>> Another option is to disable preventive gcs for this case, which is probably the safer bet - I can imagine that in some cases this change would prevent the evacuation failures necessary for the test to complete successfully (to actually do an evacuation failure).
> 
>> I think this sounds like a good approach. If we test to get evac failures it is reasonable to turn of "preventive" GCs.
> 
> Yup. I'll revert the test change that was made in the original PR and instead disable preventive collections for `GCTestWithEvacuationFailure`.
> 
>> 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?
> 
> I think you're right, this cause can be confusing when it's on a full collection. The question then is where to switch the cause, and what to switch it to. The problem is that we don't know at the point the cause is set what kind of collection will end up happening. We may decide to upgrade to a full collection in `G1CollectedHeap::do_collection_pause_at_safepoint` or in `satisfy_failed_allocation_helper`. We could put a check in `do_full_collection` that checks if the cause is preventive collection and changes it (to Allocation Failure? something else?), but that seems a bit clunky. Stefan/Thomas, do you have any suggestions?
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3143



More information about the hotspot-gc-dev mailing list