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
