Overlap in G1 gc modes

Thomas Schatzl thomas.schatzl at oracle.com
Tue Nov 3 15:58:24 UTC 2015


Hi,

On Mon, 2015-11-02 at 17:19 -0500, Derek White wrote:
> Hi Thomas, others,
> 
> I'm trying to replace 3 collection state booleans into a simple GC
> mode variable. This is technically collapsing 8 states into 3. But
> when would we ever be in both young-only GC and full-gc at the same
> time?

Can we please also have separate states for initial-mark and last
young-only?
> 
> OK, so the handy debug code I threw in notices the following:
> 
>         In G1CollectedHeap::do_collection()
>          around line 1279:
>            G1CollectorPolicy::record_full_collection_start()
>               -> collector_state()->set_full_collection(true); 
>         
>           around line 1340:
>                -> collector_state()->set_gcs_are_young(true);
>         
>           around line 1474:
>             G1CollectorPolicy::record_full_collection_end()
>               ->  collector_state()->set_full_collection(false); 
> 
> Now this overlap doesn't really matter if no code checks the state the
> the gc mode between lines 1340-1474, but of course it does.
> 
> Strangely, the ONLY code that cares if we're doing a full collection
> is some verification code - it bypasses certain verification when
> doing full-collections, unless G1VerifyRSetsDuringFullGC is true.
> 
> Going the other way, once remembered set processing occurs (after line
> 1340), some of the accounting treats the GC as a young-only GC, and
> there may be other cases that depend on gcs_are_young.

I think gcs_are_young is set there to indicate the kind of the _next_
gc, that is used to determine the young gen size for the next gc.

Maybe current/next gc state should be better separated and used
consistently. I.e. the next state for predictions on the next GC, and
the current state for decisions related to the current GC.

> As Kim pointed out to me earlier, I can expose this mixed state as
> "young-only-coming-out-of-full-collection", and make it all work, but
> that seems a bit awkward.

It sounds like a current/next state should work fine in this case.
> 
> Does anyone know why the verification around
> "G1VerifyRSetsDuringFullGC" is ignored for full collections by
> default? Should we just always do the verification for all gc-types?
> Or should we move the verification before line 1340?

See the description in CR 8015244. I do think it could be worthwhile to
just remove that flag.
> 
> Any other suggestions?
> 
> Thanks,
> 
>  - Derek

Thomas




More information about the hotspot-gc-dev mailing list