Request for review: Race conditions in java.nio.charset.Charset
Ulf.Zibis at gmx.de
Wed Oct 14 11:35:15 PDT 2009
Am 07.10.2009 23:01, Xueming Shen schrieb:
> Ulf Zibis wrote:
>> Sherman, thanks for your review ...
>> Am 07.10.2009 19:56, Xueming Shen schrieb:
>>> Though I did not write the cache code my reading suggests the
>>> existing cache
>>> impl tries to avoid the relatively "expensive" synchronization for
>>> most use scenarios,
>>> your approach however hits the synchronization for each/every lookup
>>> So you should at least consider to put the sync block in a separate
>> (But why separate lookup2? I suspect that Charset.forName() would
>> occur in excessive loops, so hotspot potentially cold inline it.)
> Maybe I meant to say "to put the sync in a separate block"
I have updated the changeset accordingly:
>> Is synchronization more expensive, than instantiating new Object
>> each time + 2 castings (to String + to Charset)?
> The difference is fast cpu + a good gc probably can make
> "instantiating new Object each time + 2 castings" trivial,
> but a synchronization only allows one thread run into the code block
> and keeps anyone else outside waiting till the
> first done.
See my benchmark I posted yesterday.
The synchronized cache is ~10-20 % slower, if only 2 charsets are
retrieved, but this should not count much, because the operations after
(de/encoding some/many characters) should be much more expensive.
If 4 charsets are retrieved, the new synchronized cache is up to 800 %
More information about the core-libs-dev