RFR: 8242054: Shenandoah: New incremental-update mode

[Roman Kennke]

>>> *) shenandoahBarrierSetAssembler_aarch64.cpp: flag check should be first?
>>>
>>>   62       if (dest_uninitialized && !ShenandoahStoreValEnqueueBarrier) {
>>
>> Yeah. In-fact, it is cleaner to check for ShenandoahSATBBarrier instead.
> 
> Eh. shenandoahBarrierSetAssembler_x86.cpp should do the same for consistency? I understand it would
> require both branches initializing "flags".

Ok, done.

>>> *) TestHeuristicsUnlock.java change actually raises a question: should this mode be experimental?
>>>   52         testWith("-XX:ShenandoahGCMode=iu", Mode.PRODUCT);
>>
>> I am not sure. On one side we now have all the tests that we considered
>> sufficient for traversal in place. Should we make it experimental, run
>> it for a while in our CIs (which also needs changing from traversal ->
>> iu), and then declare it product soon-ish? What do you think?
> 
> Yeah, I think it should be experimental for a while. We would say it is product-ready explicitly.

Ok. I introduced some machinery to make GC mode diagnostic or
experimental, and also report its name. This mirrors what we do for
heuristics:

Differential:
http://cr.openjdk.java.net/~rkennke/JDK-8242054/webrev.05.diff/
Full:
http://cr.openjdk.java.net/~rkennke/JDK-8242054/webrev.05/

Ok now?

Roman