RFR (S/M): 8178105: Switch mark bitmaps during Remark

Stefan Johansson stefan.johansson at oracle.com
Tue Apr 3 10:58:04 UTC 2018


Hi Thomas,

On 2018-03-29 16:35, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for this small change that makes G1 switch the
> mark bitmaps already during the Remark pause as opposed waiting until
> Cleanup?
>
> This is the last step before G1 can reclaim regions at Remark, which
> means that empty regions can be cleaned up more more quickly than
> before (JDK-8154528, coming soon :)).
>
> The main changes apart from actually switching the bitmaps consist of
> updating the liveness information, i.e. how many bytes are live in a
> region, now already available at Remark since JDK-8197850, also at the
> same time.
>
> Previously G1 used the Rebuild Remsets phase to calculate that at the
> same time.
>
> I could not find significant differences in timing.
>
> This change depends on the recent g1ConcurrentMark refactorings,
> particularly JDK-8200234.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8178105
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8178105/
Looks good, but a few comments:

src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
1031     for (uint i = region_idx; i < (region_idx + 
num_regions_in_humongous); i++) {
1032       HeapRegion* const r = _g1h->region_at(i);
1033       size_t const words_to_add = MIN2(HeapRegion::GrainWords, 
marked_words);
1034       r->add_to_marked_bytes(words_to_add * HeapWordSize);
1035       marked_words -= words_to_add;
1036     }
Could be nice to assert that marked_words is zero after the iteration, 
i.e. that everything got distributed and maybe also that marked_words is 
greater than 0 during the iteration.

1047       log_trace(gc)("Added " SIZE_FORMAT " words to region %u 
(%s)", marked_words, region_idx, hr->get_type_str());
I think the logging should use at least one more tag, maybe "region" or 
"marking", but you probably know what makes most sense in this area. I 
also think it would be nice if we got this same log-line for all 
regions. Now we get this for "normal" regions, but we get 
"Distributing..." for humongous start regions and "Not Added..." for 
humongous continuous. So I would suggest adding the same log-line to the 
distribute-function after line 1034.

1045     if (!hr->is_humongous()) {
Since the comment talks about humongous regions I would prefer not 
negating the statement and have something like:
if (hr->is_humongous()) {
   if (hr->is_starts_humongous()) {
     distribute_marked_bytes(hr, marked_words);
   } else {
     assert(marked_words == 0, "continuous humongous are not accounted 
separately");
   }
} else {
   hr->add_to_marked_bytes(marked_words * HeapWordSize);
   log_trace(gc)("Added " SIZE_FORMAT " words to region %u (%s)", 
marked_words, region_idx, hr->get_type_str());
}

1058 }
Newline before public :)

1686   if (mark_completed) {
1687     is_alive = &is_alive_prev;
1688   } else {
1689     is_alive = &is_alive_next;
1690   }
1691   _gc_tracer_cm->report_object_count_after_gc(is_alive);

I would prefer moving the call into the if and only setup the closure 
when needed:
if (mark_completed) {
   G1ObjectCountIsAliveClosure is_alive(_g1h);
   _gc_tracer_cm->report_object_count_after_gc(&is_alive);
} else {
   G1CMIsAliveClosure is_alive(_g1h);
   _gc_tracer_cm->report_object_count_after_gc(&is_alive);
}
----

Thanks,
Stefan


> Testing:
> hs-tier 1-5
>
> Thanks,
>    Thomas
>

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


More information about the hotspot-gc-dev mailing list