Frequent allocations / promotions of StringCoding$String{Encoder, Decoder} objects

[Xueming Shen]

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 sure that these are allocated to replace the coders cached in the StringCoding ThreadLocals (we also see SoftReferences being allocated / promoted along with the coder objects):
>
>      /** The cached coders for each thread */
>      private final static ThreadLocal<SoftReference<StringDecoder>>  decoder =
>          new ThreadLocal<>();
>      private final static ThreadLocal<SoftReference<StringEncoder>>  encoder =
>          new ThreadLocal<>();
>
> We seem to be doing encoding / decoding using at least two different charsets (we also see Encoder / Decoders for those two charsets being allocated / promoted) which is causing this churn (i.e., the coder allocations are not caused by the SoftReferences being cleared; they are frequently replaced when a coder for a different charset is required). Even though we observed this behavior with JDK 8 it should also exist in JDK 9 (StringCoding still has the same two ThreadLocals; we can confirm this very easily).
>
> Has anyone identified this issue before? We believe that caching a small number of coders per thread (instead of just one) could avoid this unnecessary churn. We’ll be happy to contribute such a fix if there’s interest in getting it accepted.
>

The assumption here is that "most programs to use one Charset repeatedly, especially
in one thread...". Obviously the assumption is wrong in your use case. It might be possible
to add multiple-entry/level cache for >= 1 coders, as we do in Charset class (it's not
threadlocal in Charset though).

sherman