RFR (S) 8134758: Final String field values should be trusted as stable
per.liden at oracle.com
Tue Sep 1 11:43:38 UTC 2015
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?
On 2015-08-31 16:59, Aleksey Shipilev wrote:
> 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:
> Here is a patch:
> 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.
More information about the hotspot-compiler-dev