Am 07.10.2009 23:01, Xueming Shen schrieb:
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 s
Ulf Zibis said the following on 10/08/09 21:58:
Am 08.10.2009 12:59, David Holmes - Sun Microsystems schrieb:
It's a memory model issue. The code is like this:
public String getName() {
if (name == null)
name = getName0();
return name;
}
but in theory, a
Am 08.10.2009 12:59, David Holmes - Sun Microsystems schrieb:
Hi Ulf,
It's a memory model issue. The code is like this:
public String getName() {
if (name == null)
name = getName0();
return name;
}
but in theory, accoridng to the JMM experts, it could ac
Am 08.10.2009 06:35, David Holmes - Sun Microsystems schrieb:
Ulf,
Ulf Zibis said the following on 10/08/09 08:58:
For my better understanding:
Can you explain me the real bug in
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6881442.
In my understanding, loading the "name" field twice is
Hi Ulf,
Ulf Zibis said the following on 10/08/09 20:07:
Am 08.10.2009 06:35, David Holmes - Sun Microsystems schrieb:
Ulf Zibis said the following on 10/08/09 08:58:
For my better understanding:
Can you explain me the real bug in
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6881442.
In
If you can show that a simple test program that appears to access
only 2 charsets in fact causes accesses to 3 or 4, that is a serious
problem with the 2-element cache.
People at Google are working on better caches,
but I don't think they are quite ready today.
Perhaps, instead of a small charset
Ulf,
Ulf Zibis said the following on 10/08/09 08:58:
For my better understanding:
Can you explain me the real bug in
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6881442.
In my understanding, loading the "name" field twice is too only a
performance bug. Please correct me!
Class.getName
On Wed, Oct 7, 2009 at 15:58, Ulf Zibis wrote:
> For my better understanding:
> Can you explain me the real bug in
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6881442.
> In my understanding, loading the "name" field twice is too only a
> performance bug. Please correct me!
Take a look a
Martin, thank for your review.
Am 08.10.2009 00:01, Martin Buchholz schrieb:
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 guess, the memo
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
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 syn
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 e
Ulf,
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 sy
I.) Internal charset cache will be corrupted in theoretical race conditions:
Startpoint:
cache1 --> Charset1
cache2 --> Charset2
Scenario 1:
- Thread1 asks for Charset2 via Charset.forName("Charset2").
- If Thread1 is interrupted after code line: cache2 = cache1
in method lookup2(String chars
14 matches
Mail list logo
