RFR (M): 8224741: Optimize the scan area during the Scan Heap Roots phase

[Kim Barrett]

> On Jul 3, 2019, at 5:17 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
>> src/hotspot/share/gc/g1/heapRegion.inline.hpp
>> 296     // If obj is not an objArray and mr contains the start of
>> the
>> 297     // obj, then this could be an imprecise mark, and we need to
>> 298     // process the entire object.
>> 299     int size = obj->oop_iterate_size(cl);
>> 300     return MAX2((HeapWord*)obj + size, mr.end());
>> 
>> Maybe mention here also that there aren't any objects after obj in
>> the region.
> 
> Fixed.

 300     // There are no objects after this humongous object in the region, so we
 301     // can return the end of the object.

That’s not quite what I had in mind.  I was thinking something like

We've scanned to the end of the object, but since there are no objects
after this humongous object in the region, we can return the end of
the region of that's greater.

>> src/hotspot/share/gc/g1/heapRegion.inline.hpp
>> 300     return MAX2((HeapWord*)obj + size, mr.end());
>> 
>> obj + size could be in a region following this region.  I think
>> rather
>> than the above result, we could instead return the end of the region
>> containing obj + size.  But I suspect this case also rarely occurs,
>> and even then there's rarely going to be anything to be saved by
>> that.
> 
> I kept the code as is. The result will most likely exceed the current
> chunk to avoid any further processing anyway. This does not seem to be
> worthwhile to optimize.

Agreed.  I think it could only (possibly) help if there are stale cards in the last region.

> http://cr.openjdk.java.net/~tschatzl/8224741/webrev.1_to_2 (diff)
> http://cr.openjdk.java.net/~tschatzl/8224741/webrev.2 (full)
> 
> (These are only comment adjustments as suggested here, so no testing)

Looks good, other than the above suggested further comment tweak.