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

[Aditya Mandaleeka]

On Thu, 22 Apr 2021 21:40:39 GMT, Aditya Mandaleeka <adityam at openjdk.org> wrote:

>> _This PR picks up from [this previous PR](https://github.com/openjdk/jdk/pull/1650) by @charliegracie._
>> 
>> I won't repeat the full description from the prior PR, but the general idea is to add the notion of a "proactive GC" to G1 which gets triggered in the slow allocation path if the number of free regions drops below the amount that would be required to complete a GC if it happened at that moment. The threshold is based on the survival rates from eden and survivor spaces along with the space required for tenured space evacuations.
>> 
>> There are a couple of outstanding issues/questions known:
>> - _Interaction with GCLocker_: In the case where we determine that a proactive GC is required and GC locker is active, we don't allow the young gen to expand (instead threads will stall). @tschatzl raised this and suggested that it should be discussed as part of the review.
>> - _Disable proactive GC heuristic during initialization_: I ran into an issue in testing where code in the universe initialization codepath was tripping the proactive GC heuristic, leading to a GC being triggered before the VM has finished initialization. I need to find a good way to prevent this from happening. There may already be a mechanism for this, but I couldn't find one so I added a temporary placeholder (`zzinit_complete`) just to unblock testing.
>
> Aditya Mandaleeka has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Remove temp init variable, update code after rebase.
>  - Refactor allocation funcs, removing attempt_lock_free_first.
>  - Fix format specifiers.
>  - Fix a few warnings as well as a Windows build error.
>  - Fix whitespace and comment.
>  - Further refactoring/changes.
>  - Address feedback and make other changes.
>  - Improve G1GC accounting for humongous objects
>    
>    If there is a burst of humongous allocations they can
>    consume all of the free regions left in the heap. If
>    there are no free regions for to-space a collect will
>    fail to evacuate all objects. This makes the GC very
>    slow. Since, humongous regions can be collected in
>    G1GC young collects force a young collect before the
>    number of free regions becomes less than the number
>    the GC is likely to require.
>    
>    Fix TestGCLogMessages.java so it still causes Evacuation
>    failures.
>    
>    Signed-off-by: Charlie Gracie <charlie.gracie at microsoft.com>

Thanks again for the review. I agree that the proposed refactor of the alloc functions looks good, and I've applied it. Functional testing of the latest code is ongoing (doing hs_gc and vmTestbase_vm_gc  in release and fastdebug on x64 Linux) but so far everything that's run has passed.

What are your thoughts on further steps involved before getting this change merged? For instance, is there value/interest in putting the proactive GCs behind an -XX: option? Every such flag adds complexity and surface area for testing, so I'm somewhat hesitant but I'm interested to hear others' opinions on this...

src/hotspot/share/gc/g1/g1Policy.cpp line 786:

> 784:   update_rs_length_prediction();
> 785: 
> 786:   // Is this the right place? Should it be in the below?

Can a reviewer confirm this so that I can remove the comment?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3143