RFC: Adding generational support to ShenandoahHeapRegion

[Nilsen, Kelvin]

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.)