Overlap in G1 gc modes

[Derek White]

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?

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.

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.

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?

Any other suggestions?

Thanks,

  - Derek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20151102/fe2b60ec/attachment.htm>