RFR (S/M): 8159440: Move marking of promoted objects during initial mark into the concurrent phas

[Stefan Johansson]

Hi Thomas,

Nice clean up, looks good in general. Just one minor nit.

On 2018-11-29 11:23, Thomas Schatzl wrote:
> Hi all,
> 
>    can I have reviews for this cleanup change that unifies how we handle
> "roots" from survivor and old gen regions?
> 
> So at the moment, after the concurrent start pause, we have a "scan
> root regions phase" that walks through the objects in the survivor
> regions to find roots for the marking. This is needed because the ntams
> of survivor regions is bottom, i.e. the objects are above so that
> marking will not otherwise come across these.
> 
> For promoted objects we have a different mechanism: we mark those
> objects on the next bitmap, and set ntams to the end of the promoted
> objects, i.e. the scan of the marking will automatically follow their
> references.
> 
> This special handling has several drawbacks:
> - additional special handling of old gen regions manually adjusting the
> nTAMS
> - the promoted objects need to be marked in the pause.
> 
> This change makes handling of the promoted objects (from ntams to top)
> equal to survivor regions.
> 
> For this reason we extend the existing G1RootRegions data structure to
> remember the regions (both survivor and promoted-into old gen regions).
> That saves quite a bit of code.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8159440
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8159440/webrev/
src/hotspot/share/gc/g1/g1ConcurrentMark.hpp
--------------------------------------------
  239   uint _max_regions;
  240   volatile size_t _cur_regions;
  ...
  245   volatile size_t _claimed_root_regions;

I would like these names to feel more connected. Maybe rename 
_cur_regions to _used_root_regions or _num_root_regions (as the getter). 
Is there any reason _max_regions can't be size_t as well to be even more 
consistent?

Thanks,
Stefan


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