Request for review: Race conditions in java.nio.charset.Charset

[Xueming Shen]

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 
>> invocation.
>> So you should at least consider to put the sync block in a separate 
>> lookup2.
>
> Agreed:
> (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
first done.

>>
>> 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 
> argumentation.
> ... 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.


sherman