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

Martin Buchholz martinrb at google.com
Wed Oct 7 22:01:59 UTC 2009


IIRC correctly, I am the author of the hacky 2-element charset cache.
Certainly improvements can be made, but it's hard to balance
memory usage vs. the cost and complexity of writing a good cache.

I agree with Sherman that a race in the cache itself is not a bug
(or at best, a performance bug).

I don't think it's worth a point fix here unless an actual wrong result
can be demonstrated.  I do think a more sophisticated charset cache
would be good, but hard to get right.

Martin

On Wed, Oct 7, 2009 at 14:01, Xueming Shen <Xueming.Shen at sun.com> wrote:
> 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
>



More information about the core-libs-dev mailing list