RFR (M): 8224741: Optimize the scan area during the Scan Heap Roots phase
Kim Barrett
kim.barrett at oracle.com
Tue Jul 2 17:06:16 UTC 2019
> On Jul 2, 2019, at 6:40 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> Updated webrevs:
> http://cr.openjdk.java.net/~tschatzl/8224741/webrev.0_to_1 (diff)
> http://cr.openjdk.java.net/~tschatzl/8224741/webrev.1 (full)
Looks good.
A couple minor comment nits, and one (highly) optional suggestion.
------------------------------------------------------------------------------
src/hotspot/share/gc/g1/heapRegion.hpp
Thanks for the "card" => "memregion" renamings.
------------------------------------------------------------------------------
src/hotspot/share/gc/g1/heapRegion.hpp
296 // Returns the address after the last actually scanned or NULL if the area could
"the address after the last actually scanned" isn't really accurate.
More accurate might be "the next unscanned address".
------------------------------------------------------------------------------
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.
------------------------------------------------------------------------------
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.
------------------------------------------------------------------------------
More information about the hotspot-gc-dev
mailing list