All,
Thanks for the replies!
Aleksey,
Thanks for pointing me to the CR (JDK-4806753). I’m a bit confused though. The
CR was resolved as fixed but Mark’s patch doesn’t seem to have made it to the
StringCoding.java file (I checked the JDK 8 and 9 source repos; also the class
sources in src.zip
On 02/25/2016 12:48 PM, Tony Printezis wrote:
Hi all,
We recently noticed that in several of our production services there are very
frequent allocations / promotions of coder objects from the StringCoding class
(e.g. java.lang.StringCoding$String{Encoder,Decoder} instances). We are pretty
sur
On 02/25/2016 01:29 PM, Richard Warburton wrote:
Hi,
+1. I was confused by this behaviour when I submitted a String
related
patch a while back but never got round to submitting a fix. It actually
means that in String decoding often passing the charset to use by
Str
Hi,
+1. I was confused by this behaviour when I submitted a String related
>>>
>> patch a while back but never got round to submitting a fix. It actually
>> means that in String decoding often passing the charset to use by String
>> is
>> faster than passing it Charset object - counter-intuitive a
On 02/25/2016 12:57 PM, Richard Warburton wrote:
Hi,
Finally, the StringCoding coder c'tor allocates a new Charset coder
(Charset{Encoder,Decoder}) for the specific charset. But such Charset
coders already seem to be cached in ThreadLocals in the
sun.nio.cs.ThreadLocalCoders class. Any reason w
t;
> Envoyé: Jeudi 25 Février 2016 21:57:56
> Objet: Re: Frequent allocations / promotions of StringCoding$String{Encoder,
> Decoder} objects
>
> Hi,
>
> Finally, the StringCoding coder c'tor allocates a new Charset coder
> > (Charset{Encoder,Decoder}) for th
On 02/25/2016 11:48 PM, Tony Printezis wrote:
> Has anyone identified this issue before?
Hm, there is a blast from the past:
https://bugs.openjdk.java.net/browse/JDK-4806753
In comments there, Mark suggests a patch that apparently handles
multiple coders. I wonder where did that go. Also, Marti
Hi,
Finally, the StringCoding coder c'tor allocates a new Charset coder
> (Charset{Encoder,Decoder}) for the specific charset. But such Charset
> coders already seem to be cached in ThreadLocals in the
> sun.nio.cs.ThreadLocalCoders class. Any reason why we cannot re-use those?
> (Oh, and also not
