Codereview request for 7183053: Optimize DoubleByte charset for String.getBytes()/new String(byte[])

Xueming Shen xueming.shen at
Mon Jul 16 18:42:28 UTC 2012

Hi Alan,

I gave the "continue ->else if " a try, it appears the server vm 
obviously likes
the "continue" approach (it is consistent with what we experienced in 
the past
when we did similar approach for ascii, in which we separate/singled the 
path out). So I guess we probably want to keep the continue here.

Here are the data. dbcs2_new is to replace the continue with else if and the
dbcs2 is the "continue".


On 07/13/2012 10:09 AM, Xueming Shen wrote:
>>> In JDK7,  the decoder and encoder implementation of most of our 
>>> single-byte charsets
>>> and UTF-8 charset are optimized to implement the internal interfce 
>>> sun.nio.cs.ArrayDecoder/
>>> Encoder to provide a fastpath for String.getBytes(...) and new 
>>> String(byte[]...) operations. I
>>> have an old blog regarding this optimization at
>>> This rfe, as the followup for above changes, is to implement 
>>> ArrayDe/Encoder for most
>>> of the sun.nio.cs.ext.DoubleByte based double-byte charsets. Here is 
>>> the webrev
>> I've taken a pass over this and it's great to see 
>> DoubleByte.Decoder/Encoder implementing 
>> sun.nio.cs.ArrayDecoder/Encoder. The results looks good too, a small 
>> number of regressions (Big5 at len=32 for example) but this is a 
>> micro benchmark and I'm sure there are fluctuations. I don't see 
>> anything obviously wrong with the EBCDIC changes I'd need a history 
>> book to remember how the shifts between DBCS and SBCS. I think our 
>> tests our good for this area so I'm happy. One minor nit is the 
>> continue in both encode methods, I think it would be cleaner to use 
>> "else if (bb ..." instead.
> The continue might make the vm happy, but this is the code I did last 
> Oct, so I might be
> wrong. Will give a couple run later with "else"

More information about the core-libs-dev mailing list