RFR (S) 8229416: Shenandoah: Demote or remove ShenandoahOptimize*Final optimizations

[Roman Kennke]

Am 12.08.19 um 18:21 schrieb Roman Kennke:
>> RFE:
>>   https://bugs.openjdk.java.net/browse/JDK-8229416
>>   https://cr.openjdk.java.net/~shade/8229416/webrev.01/
>>
>> There are three Shenandoah optimizations at the moment:
>>  ShenandoahOptimizeStaticFinals (enabled by default)
>>  ShenandoahOptimizeInstanceFinals (disabled by default)
>>  ShenandoahOptimizeStableFinals (disabled by default)
>>
>> The last two are known to break some programs, and they are definitely incorrect in
>> post-LRB/post-nofwdptr world, where exposing the from-space object with unusual markword would wreck
>> some havoc. These should be removed.
> 
> That is ok by me.
> 
>> The first optimization is eliminating barriers on constants, that are handled separately, and never
>> get exposed as from-space objects. We should keep that optimization on, but to add future debugging,
>> we would want to keep the flag as diagnostic.
> 
> I believe this optimization actually does nothing (interesting). C2
> already optimizes access to static-finals to inlined constants, and we
> eliminate barriers on inlined constants. We might want to check & verify
> this, but I strongly suspect this optimization is actually a no-op (at
> least in most/all interesting cases).

And notice that this also covers, transitively, the interesting cases of
instance-final and stable-final. For example, if C2 encounters a String
constant, it will inline that to be an embedded oop. However, the
backing 'value' (e.g. byte[]) is final, and thus C2 might also embed
this guy as constant in code. It goes even further because the byte[] is
also @Stable, from which C2 can determine that the array elements
themselves are constant, and thus subject to inlining and constant
propagation.

Roman