RFR (S): 8205426: Humongous continues remembered set does not match humongous start region one in Kitchensink

[Kim Barrett]

> On Jun 26, 2018, at 1:15 PM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi all,
> 
>  can I have reviews for this bug in keeping remembered sets consistent
> between HC and HS regions, causing crashes with verification?
> 
> The problem occurs during updating the remembered sets during the
> Remark pause. This process is parallel; it uses liveness information
> from marking to set the new remembered set states.
> 
> However during marking G1 attributes all liveness information of a
> humongous object to the HS region; if that liveness information has not
> been updated yet for HC regions, and another thread is responsible for
> determining that HC region's remembered set state, the new remembered
> set state of the HC region will get a state as the HS region.
> 
> The fix is to, for HC regions, just pass the liveness data of the HS
> region into the method that determines the new remembered set state.
> Further, in that latter method, make sure that the predicate for
> determining whether a region gets a remembered set assigned is
> completely disjoint for humongous and non-humongous regions.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8205426
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8205426/webrev/
> Testing:
> new test case, hs-tier1-4,jdk-tier1-3
> 
> Thanks,
>  Thomas

The new live_bytes_for seems like it's overly verbose and complicated,
and could instead just be something like:

size_t live_bytes_for(HeapRegion* r) {
  // For humongous regions, use liveness of associated starts region.
  HeapRegion* hr = r->is_humongous() ? r->humongous_start_region() : r;
  return _cm->liveness(hr->hrm_index()) * HeapWordSize;
}

However, I wonder if this is the right way to go?

It seems to me that the underlying problem is that we're even asking
the live_bytes question of humongous_continues regions, when nobody
really cares about the answer (after fixing the policy).  We're also
computing it for young regions and for humongous_start regions
containing an objarray, where again the (fixed) policy doesn't care.

It seems to me that things would be simpler if it were the policy that
asked the live_bytes question, after it has determined that it was
interested in the answer.  The only downside I can think of is that
the G1RemSetTrackingPolicy would be additionally coupled to the
G1ConcurrentMark object.