RFR: Implement stable access optimization on arrays

[Roman Kennke]

>>> http://cr.openjdk.java.net/~rkennke/stable-arrays/webrev.00/
>>
>> Do you really need base_type? Doesn't that work with adr_type too? Also
>> why not push this upstream now that shenandoah is upstream?
> 
> Yeah I guess adr_type would also work. The adr_type of a Load and the
> bottom_type of the address that feeds into the Load should be the same?
> At least regarding the is_stable() property?
> 
> Yeah, I'll do this upstream.
> 
> I am wondering if we should enable this optimization by default?
> 
> 1. It's 'private' within the OpenJDK implementation, and thus under our
> control: should we find that any use of it violates the JMM (e.g. by
> exposing half-initialized object via initializer), then we can just fix it.
> 2. Hotspot also does similar optimization via FoldStableValues which
> defaults to true.
> 
> It seems unlikely that this causes actual problems.
> 
> I'm currently running benchmarks to see if it has any measurable effects:
> 
> no stable optimization vs. current stable optimization vs. improved
> stable optimization.

It couldn't see an effect regardless the optimization setting.

That makes me wonder if we would get the optimization anyway: if Hotspot
already optimizes stable fields/elements to constants, and we elide
barriers on constants anyway, may we already get the desired effect that
way? Also for final fields? If this is true, we can get rid of the 3
ShenandoahOptimize* flags altogether and remove the related code.
Roland, wdyt?

Roman