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

[Aleksey Shipilev]

Hi Per,

Yes, I wondered how String Deduplication works with the String.value
stability. I guessed that as long as dedup is idempotent (e.g. it
switches the char[] to the semantically the same char[]), we are fine.
Even if we inline the "old" reference to char[] into the generated code,
it seems to become the GC root on its own.

And yes, this particular change does nothing new to that mechanics.

Thanks,
-Aleksey

On 09/01/2015 02:43 PM, Per Liden wrote:
> 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
>>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150901/4eb69fe3/signature.asc>