Currently, the StringCoding class caches per thread a single StringDecoder and a single StringEncoder. This means that, if an application does string decoding / encoding using more than one charset, the entries for those caches will be frequently replaced and new StringDecoders/Encoders will be frequently allocated and maybe promoted. We have observed this happening in a lot of our services at Twitter.

Furthermore, those caches use SoftReferences. This means that, if the cached entries are replaced frequently, new SoftReferences also need to be frequently allocated and potentially promoted.

We are proposing to introduce a per-thread cache that can hold a small number of StringDecoders/Encoders (i.e., not just one) to reduce the amount of unnecessary allocations / promotions we have observed.

Further we are also proposing to eliminate the use of SoftReferences in those caches. We believe their use is unnecessary and it in fact imposes avoidable overheads (mainly: extra ref processing work during GC).