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
Changeset: e7ad502130ba
Author:darcy
Date: 2009-10-07 14:04 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e7ad502130ba
6480728: Byte.valueOf(byte) returns a cached value but Byte.valueOf(String)
6655735: Integer.toString() and String.valueOf(int) contain slow delegations
Rev
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
Joe,
These look ok to me
-lance
Joseph D. Darcy wrote:
Hello.
Please review these simple cleanup fixes in the wrapper classes:
6480728: Byte.valueOf(byte) returns a cached value but
Byte.valueOf(String)
6655735: Integer.toString() and String.valueOf(int) contain slow
delegations
The fix
Changeset: 14bd992a
Author:tbell
Date: 2009-10-07 13:53 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/14bd992a
688: new javah throws NullPointerException when building in
jdk/make/java/nio
Summary: Use the bootstrap javah during the build until bug-ID 6889255 is
Hello.
Please review these simple cleanup fixes in the wrapper classes:
6480728: Byte.valueOf(byte) returns a cached value but Byte.valueOf(String)
6655735: Integer.toString() and String.valueOf(int) contain slow delegations
The fix for the first bug is for the valueOf(String) and decode method
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
Joe,
Here are a few more resources that you may want to investigate for
java.util.Objects:
*
http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/common/base/Objects.html
*
http://static.springsource.org/spring/docs/3.0.0.M4/javadoc-api/org/springframework/util/ObjectUtils.html
David Holmes - Sun Microsystems wrote:
Stephen Colebourne said the following on 10/07/09 18:10:
BTW, I don't accept the argument that one and only one way to do
something is part of the JDK.
While the JDK is far from a model example of providing "one way" to do
something, that doesn't mean w
Changeset: f864c15f6779
Author:chegar
Date: 2009-10-07 17:23 +0100
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f864c15f6779
6887364: SetOutgoingIf.java fails if run on multihomed machine without PIv6 on
all interfaces
Reviewed-by: alanb
! test/java/net/MulticastSocket/SetOutgo
> Hi Stephen,
>
> [...]
> > In key places there are multiple options. NIO Path vs File and
> > Calendar vs Date are examples.
>
> As you know, Path (resp. Calendar) is just an attempt to correct the
> mess introduced by File (resp. Date).
> So yes, there is duplication but this duplication is
Stephen Colebourne a écrit :
Paul Benedict wrote:
If you want Objects.toString() to provide value, consider mimicking
the functionality from Apache Commons:
http://commons.apache.org/lang/api-2.4/org/apache/commons/lang/ObjectUtils.html
My biggest complaint about String.valueOf(Object) is t
Am 07.10.2009 01:43, Joe Darcy schrieb:
I don't think having a one-line forwarding method in Objects is that
harmful.
On the other hand Character.MAX_SUPPLEMENTARY_CODE_POINT was rejected
for JDK footprint reason.
-Ulf
Stephen Colebourne said the following on 10/07/09 18:10:
BTW, I don't accept the argument that one and only one way to do
something is part of the JDK.
While the JDK is far from a model example of providing "one way" to do
something, that doesn't mean we should gratuitously add superfluous an
Paul Benedict wrote:
If you want Objects.toString() to provide value, consider mimicking
the functionality from Apache Commons:
http://commons.apache.org/lang/api-2.4/org/apache/commons/lang/ObjectUtils.html
My biggest complaint about String.valueOf(Object) is that it will
actually return "null
Changeset: f69b40e43bff
Author:kamg
Date: 2009-10-06 22:01 -0400
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f69b40e43bff
6885916: Memory leak in inferencing verifier (libverify.so)
Summary: Use the memory management already present to track allocated memory
Reviewed-by: coleenp
21 matches
Mail list logo
