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

[Tobias Hartmann]

On 01.09.2015 08:52, Tobias Hartmann wrote:
> Hi Aleksey,
> 
> On 31.08.2015 22:36, Aleksey Shipilev wrote:
>> Current JDK 9 code captures T_INT constants there, but we need T_BYTE as
>> well. Compact Strings version has even more constant types handled, but
>> not T_BYTE [1] (this should be the leftovers from CompressedStrings).
>> Tried to hack T_BYTE there for Compact Strings, and the same performance
>> effect was achieved.
> 
> Yes, Compact Strings handles T_OBJECT and T_BOOLEAN as well because they were needed for the old String.value which was Object and the "coder" field which was boolean. Actually, I was just working on cleaning up that code and making it aware of the new T_BYTE coder field (discussed it with Vladimir last week).
> 
> The T_INT is most likely also legacy code from when we still had the String.count field. I think you can remove it.
> 
>> I'll see how and where to fix this properly. Tentatively, I'd say all
>> types should be handled in the mainline version, and Compact Strings
>> should purge its own version, to avoid further omissions.
> 
> Not sure if that makes sense, since JDK9 has no T_BYTE field in String.

I just noticed that you are using the make_from_constant() factory method in LoadNode::Value() and therefore don't require special casing for all possible types. That looks good to me!

Best,
Tobias

> 
>>
>> Thanks,
>> -Aleksey
>>
>> [1]
>> http://hg.openjdk.java.net/jdk9/sandbox/hotspot/file/c3a11189c852/src/share/vm/opto/memnode.cpp#l1732
>>