RFR (S) 8134758: Final String field values should be trusted as stable
aleksey.shipilev at oracle.com
Tue Sep 1 00:22:32 UTC 2015
On 08/31/2015 11:36 PM, Aleksey Shipilev wrote:
> 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  (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.
All right, how about this?
Respinned JPRT, plus length() benchmarks against Compact Strings,
Tobias, please take a look as well, since you are the one who would
probably do the merge to Compact Strings sandbox.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the hotspot-compiler-dev