Request for review: Race conditions in java.nio.charset.Charset (original) (raw)

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