RFR (S) 8134758: Final String field values should be trusted as stable

[Per Liden]

Hi Aleksey,

I'm trying to figure out if this has any impact on String deduplication 
(which can change the String.value field), but I can't see any obvious 
problems. Dedup already handles the case where GraphKit treats it as a 
stable field and I don't see that this adds any new cases. Just wanted 
to double check that you reached the same conclusion?

cheers,
/Per

On 2015-08-31 16:59, Aleksey Shipilev wrote:
> Hi,
>
> I would like to make a forward move and make VM to trust all final
> String fields. I cannot quickly find the scenario where it helps current
> JDK -- there is only String.value field, which components are not
> treated as constants anyway. But, it helps a lot the upcoming Compact
> Strings change, which introduces String.coder field.
>
> String.value is actually handled as stable in the GraphKit with
> UseImplicitStableValues, but it does not affect "normal" Java code.
> Therefore, in a way, this change extends the same behavior to the normal
> code. See more here:
>    https://bugs.openjdk.java.net/browse/JDK-8134758
>
> Here is a patch:
>    http://cr.openjdk.java.net/~shade/8134758/webrev.00/
>
> Passes JPRT and eyeballed assembly looks fine on Linux x86_64.
>
> Does the change itself look generic enough to consider straight in the
> mainline? Otherwise, we can keep it in Compact Strings sandbox, but it
> will eventually arrive back entangled in a much larger code change, and
> shall still require review.
>
> Thanks,
> -Aleksey
>