Request for review: Race conditions in java.nio.charset.Charset
Xueming.Shen at Sun.COM
Wed Oct 7 21:01:42 UTC 2009
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"
> 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
>> But personally I doubt we really care this "race condition", it's a
>> cache, a cache miss
>> is not a disaster,
> OK, but why didn't you you reject Bug Id 6881442 with the same
> ... and missing the class's name in Class.name could only happen once,
> in contrast to "my" race condition, which theoretically could happen
> every time.
The difference is that race condition may cause a wrong result, In this
case the result is still correct though it
might come out at a relatively slow speed should the race condition occur.
More information about the core-libs-dev