RFR (S) 8150180: String.value contents should be trusted

[John Rose]

On Feb 19, 2016, at 2:40 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
>> 
>> On Feb 19, 2016, at 9:03 AM, John Rose <john.r.rose at oracle.com <mailto:john.r.rose at oracle.com>> wrote:
>> 
>> On Feb 19, 2016, at 9:57 AM, Christian Thalinger <christian.thalinger at oracle.com <mailto:christian.thalinger at oracle.com>> wrote:
>>> 
>>> Why don’t you change the values to:
>>> 
>>>    static final byte LATIN1 = 1;
>>>    static final byte UTF16  = 2;
>> 
>> 
>> Not sure what you are asking, but here's my take on why 0,1 is the (slight) winner.
>> The values 0,1 are the log2 of the array element sizes 1,2, so they can be used with shift instructions.
>> With 1,2 they would have to be used with multiply instructions, or else tweaked back to shift inputs.
>> Most loops will speculate on the scale factor, but those loops which must work with a non-constant scale will be slightly cleaner with 0,1.
> 
> I see what you are saying:
> 
>   int len = val.length >> coder;  // assume LATIN1=0/UTF16=1;
> 
> But if coder is stable for both values the compiler can constant fold the if-statement for the shift value:
> 
>   int len = val.length >> (coder == LATIN1 ? 0 : 1);
> 
> That should produce the same code and we would avoid:
> 
> 143      * Constant-folding this field is handled internally in VM.


Yes, the coder value can usually be speculated, especially if we encourage the JIT to pay special attention.
I'm only talking about the parts where the coder cannot be speculated upon.
— John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160219/8c07eaee/attachment-0001.html>