JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1)

[Xueming Shen]

On 04/10/2014 11:08 AM, Chris Hegarty wrote:
>> On 10 Apr 2014, at 18:40, Mike Duigou<mike.duigou at oracle.com>  wrote:
>>
>>
>>> On Apr 10 2014, at 03:21 , Chris Hegarty<chris.hegarty at oracle.com>  wrote:
>>>
>>>> On 10 Apr 2014, at 11:03, Ulf Zibis<Ulf.Zibis at CoSoCo.de>  wrote:
>>>>
>>>> Hi Chris,
>>>>
>>>> Am 10.04.2014 11:04, schrieb Chris Hegarty:
>>>>> Trivially, you could ( but of not have to ) use java.nio.charset.StandardCharsets.ISO_8859_1 to avoid the cost of String to CharSet lookup.
>>>> In earlier tests Sherman and I have found out, that the cost of initialization of a new charsets object is higher than the lookup of an existing object in the cache.
>>>> And it's even better to use the same String instance for the lookup which was used to cache the charset.
>>> Interesting… thanks for let me know.  Presumably, there is an assumption is StandardCharsets is not initialized elsewhere, by another dependency.
>> Generally it's safe to assume that StandardCharsets will already be initialized. If it isn't initialized we should consider it an amortized cost.
> I'm which case why would the string version be more performant than the version that already takes the Charset? Doesn't the string version need to do a lookup?
>

String version has the cache mechanism of charset -> CharsetDe/Encoder, so if
cache hits, you don't need to have String->Charset lookup.

We don't cache the "external" charset though for de/encode(Charset ...), so we
always need to create a "new" CharsetDe/Encoder everytime the de/encode()
method gets invoked.

-Sherman