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