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

Christian Thalinger christian.thalinger at oracle.com
Fri Feb 19 22:40:40 UTC 2016

> On Feb 19, 2016, at 9:03 AM, John Rose <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.

More information about the core-libs-dev mailing list