RFR: 8242054: Shenandoah: New incremental-update mode

[Aleksey Shipilev]

On 4/6/20 3:12 PM, Roman Kennke wrote:
>>
>> *) 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".

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

-- 
Thanks,
-Aleksey