i2c conversion should not cost anything; it'll just make jit use low 16 bits of the registers for (unsigned) comparisons. I haven't checked this though, but that's what I'd expect.
Sent from my phone On Feb 5, 2014 7:27 PM, "Xueming Shen" <xueming.s...@oracle.com> wrote: On 02/05/2014 03:28 PM, Ulf Zibis wrote: > Additionally you could use Character.isSurrogate() and > Character.isSupplementaryCode<point() at appropriate places. Both are > better optimized for JIT. > j.l.C.isSupplementaryCodePoint() checks up boundary of supp, we probably don't need it here, as the returning code point is either a ERROR or a valid unicode code point. I'm not sure about the j.l.C.isSurrogate(), which takes a char and we have an int here. I would expect the javac will inline the constants for me, but I don't know whether jit can inline and then optimize away the explicit casting i2c. Not a big deal though. -sherman > -Ulf > > > Am 05.02.2014 22:30, schrieb Xueming Shen: > >> Hi Remi, >> >> Good suggestion. Now the "common case" path is much simple and faster :-) >> I'm seeing a 5%-10% boost for the normal-non-surrogates case. And it >> appears >> the bmp+surr mixed is getting faster as well. Though I would assume the it >> would get slower in case of "no-case-folding" + surrogates. But the common >> case wins here. >> >> http://cr.openjdk.java.net/~sherman/8032012/webrev/ >> > >
