RFR : 8186517: sun.nio.cs.StandardCharsets$Aliases and ClassMap can be lazily loaded
peter.levart at gmail.com
Thu Aug 24 17:11:41 UTC 2017
On 08/24/2017 05:56 PM, Xueming Shen wrote:
>> While looking at the code of StandardCharsets, I noticed a real
>> danger of using a thread-unsafe object while it is being modified.
>> The method charsets() returns an Iterator<Charset> which lazily
>> invokes an unsynchronized lookup() method for each charset as it
>> returns them. lookup() uses a Cache (a PreHashedMap) which is not a
>> thread-safe object. private lookup() is called from a synchronized
>> block of public charsetForName() method, but it is invoked
>> unsynchronized from iterator.
> There were tasty initialization/synchronization/deadlock issues here
> in the past (decade ago,
> happened only on customers' site with specific use scenarios). Our
> system initialization
> "sequence" has been changed and the way the standard charset provider
> is being loaded has
> been changed since, it might be reasonable to reconsider how this part
> of code should work,
> but I would still be very cautious here as the initial goal is for
> startup performance.
It would be nice if startup performance improvement extended to programs
using just constants from java.nio.charset.StandardCharsets too.
Here's a variant of that:
>> One way to fix it would be to enclose the lookup() invocation in
>> Iterator.next with a synchronized block, but then I thought that
>> maybe a PreHashedMap is not the right tool for the job. What if the
>> cache was simply a ConcurrentHashMap which need not be pre-populated
>> with all possible keys (saving on footprint) and could therefore be
>> constructed eagerly. The whole lookup() could then be unsynchronized.
>> Here's what I came up with:
>> I also ensured that the same instance of Charset object gets returned
>> for all aliases of a charset (including standard 3).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nio-dev