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

Aleksey Shipilev aleksey.shipilev at oracle.com
Mon Aug 31 20:36:21 UTC 2015

On 08/31/2015 08:25 PM, Vladimir Kozlov wrote:
> On 8/31/15 10:15 AM, Aleksey Shipilev wrote:
>> On 08/31/2015 07:25 PM, Vladimir Kozlov wrote:
>>> On 8/31/15 7:59 AM, Aleksey Shipilev wrote:
>>>> String.value is actually handled as stable in the GraphKit with
>>>> UseImplicitStableValues, but it does not affect "normal" Java code.
>>> What do you mean by "normal" code?
>> The code that is not handled by intrinsics on any other special explicit
>> magic in a compiler. Just plain Java code, like the length() method
>> above. How do you call it?
> Got it. LoadNode::Value() has special case for String fields when string
> is constant. We can add UseImplicitStableValues code there for
> non-constant String.

Ohhhh, thanks! In fact, that where it should be fixed.

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.

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.



-------------- 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/20150831/2006ea5d/signature.asc>

More information about the hotspot-compiler-dev mailing list