RFC: Adding generational support to ShenandoahHeapRegion

[Roman Kennke]

Hi Kelvin,

the change itself seems relatively uncontroversial as it is.

I have sent you my w-i-p a while ago, which also covers this suggested
change, and much more (tracking age, promoting objects, dynamically
allocating regions for old-gen, etc), have you considered it?

http://cr.openjdk.java.net/~rkennke/generation.patch


I am not quite sure how it makes sense to use Shenandoah 'primarily for
young gen collection'. Intuitively I'd use Shenandoah for both old and
young gen, or even just for old-gen and a STW scavenger for young-gen.

Regarding point #4, it may at some point be worth to use a similar
mechanism like we use to quickly determine object-in-cset, i.e. a
biased lookup-table. That's more efficient than finding a region, and
then looking up the field there. But that is certainly an optimization
for later.

Thanks for your work on this!

Cheers,
Roman

On Fri, 2020-08-14 at 00:34 +0000, Nilsen, Kelvin wrote:
> This webrev details a suggested change to the definition of
> ShenandoahHeapRegion for the purpose of enabling multi-generational
> garbage collection: 
> 
>     http://cr.openjdk.java.net/~kdnilsen/two-generations/webrev.00/
> 
> Here is some background on how we anticipate this facility will be
> used:
> 
>   1. Our thoughts are to use Shenandoah as currently implemented
> primarily for young-gen collection, so the default constructor shows
> that all heap regions are allocated as belonging to the young
> generation.
> 
>   2. Eventually, we will set aside certain heap regions to represent
> old-generation memory.  As objects are tenured, the Shenandoah
> collector evacuates these objects out of a young-gen HeapRegion into
> an old-generation heap region.
> 
>   3. Certain existing operations of the existing Shenandoah collector
> (marking, for example) need to efficiently determine whether
> particular objects referenced by pointers reside in young-gen memory
> or old-gen memory.   Shenandoah GC will give non-traditional
> treatment to any pointers residing outside the young-generation. 
> 
>   4. We intend to use the heap->heap_region_containing(address)
> service to find the heap region that corresponds to a particular
> object address and then consult the value of the _gen field to
> determine whether a particular object resides in old-gen or new-gen
> memory.
> 
>   5. Fast-path mutator operations do not need to know which
> generation holds particular objects.  The most common requirement is
> for a background GC thread to be processing pointers within a tight
> loop.  In this common use case, we expect that the loop-invariant
> variables RegionSizeBytesShift, _base, and _regions would all reside
> in registers and their content would be loaded within the loop's pre-
> header.
> 
> I welcome discussion and recommendations for improvement.
> 
> (We are doing prototype development off trunk.  We would not expect
> to merge any of this code until it is all working and performance
> benefits are demonstrated.)
> 
> 
> 
> 
>