Hi,
Please ignore the previous webrev and see this instead:
http://cr.openjdk.java.net/~khazra/7146763/webrev.03/
This has Stuart's suggestion integrated correctly. In addition, I
realized that
make/sun/rmi/rmic/Makefile is not yet ready to have the
JAVAC_WARNINGS_FATAL
flag turned on, since
On 02/24/2012 08:01 PM, Kurchi Hazra wrote:
Hi Stuart,
Thanks for the detailed explanation. Here is an updated webrev:
http://cr.openjdk.java.net/~khazra/7146763/webrev.02/
Hi Kurchi,
the field logClassConstructor should not be changed after all,
it should be declared as a Constructor so yo
Changeset: 4893a89b4916
Author:sla
Date: 2012-02-24 20:09 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4893a89b4916
7079093: TEST_BUG: java/lang/instrument/ManifestTest.sh fails with cygwin
Summary: Work around problems in some cygwin installations
Reviewed-by: alanb, sspit
Changeset: 585f2c72d042
Author:sla
Date: 2012-02-24 20:02 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/585f2c72d042
7073626: RmiBootstrapTest.sh and RmiSslBootstrapTest.sh fail under Cygwin
Summary: Detect and handle cygwin correctly
Reviewed-by: alanb, sspitsyn
! test/Pro
Hi Stuart,
Thanks for the detailed explanation. Here is an updated webrev:
http://cr.openjdk.java.net/~khazra/7146763/webrev.02/
- Kurchi
On 2/24/2012 12:54 AM, Stuart Marks wrote:
On 2/22/12 1:25 PM, Kurchi Hazra wrote:
On 2/22/2012 10:01 AM, Rémi Forax wrote:
Hi Kurchi, hi all,
in Rel
Changeset: e6b5c3aff85c
Author:jjg
Date: 2012-02-24 10:40 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e6b5c3aff85c
7137836: tidy up Names.java
Reviewed-by: mcimadamore
! src/share/classes/com/sun/tools/javac/util/Names.java
Hi Dan,
I got a bounce from serviceability-dev because I wasn't subscribed to
it, but the message went out to core-libs-dev because I was subscribed
to that. That probably explains what you saw.
Regards,
Éamonn
On 24 February 2012 09:33, Daniel D. Daugherty
wrote:
>
> Just FYI: I haven't seen
Hi, Dan.
> Just FYI: I haven't seen Éamonn's posting come in. Just replies to his
> posting. This may mean that other comments are stuck in the ether
> somewhere...
>
> I suspect that the OpenJDK list server is again having issues...
I just checked the core-libs-dev admin interface to see if an
Just FYI: I haven't seen Éamonn's posting come in. Just replies to
his posting. This may mean that other comments are stuck in the
ether somewhere...
I suspect that the OpenJDK list server is again having issues...
Dan
On 2/24/12 8:21 AM, Olivier Lagneau wrote:
I think I have not been clear e
I think I have not been clear enough here.
I Agree with Eammon's argument, and anyway ok with this change.
Olivier.
Olivier Lagneau said on date 2/24/2012 12:38 PM:
Hi Éamonn,
Eamonn McManus said on date 2/23/2012 8:44 PM:
I am not sure it is worth the complexity of extra checks. Do you ha
Hi Éamonn,
Eamonn McManus said on date 2/23/2012 8:44 PM:
I am not sure it is worth the complexity of extra checks. Do you have
data showing that ObjectName.equals usually returns false?In a
successful HashMap lookup, for example, it will usually return true
since the equals method is used to
Changeset: 0a350fb8b174
Author:coffeys
Date: 2012-02-24 09:17 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a350fb8b174
7144488: Infinite recursion for some equals tests in Collections
Reviewed-by: alanb, dholmes, mduigou
! src/share/classes/java/util/Collections.java
+ te
On 2/23/12 7:46 PM, David Schlosnagle wrote:
Was the main bottleneck the contention on the interned string pool
that prevented concurrent addition of ObjectNames? Are there other
places within the JDK where use of intern() should be analyzed for
similar scalability bottlenecks? I'm also curious
Changeset: a589a8dbde79
Author:coffeys
Date: 2012-02-24 09:10 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a589a8dbde79
7133138: Improve io performance around timezone lookups
Reviewed-by: okutsu
! make/tools/src/build/tools/javazic/Mappings.java
! src/share/classes/sun/ut
Hi,
Though "compareTo" tends to be less efficient than "equals", it offers better
type safety.
When we (mistakenly!) compare objects of different type, "equals" silently
accepts parameter of wrong type,
but returns false. Comparison with "compareTo" is rejected by compiler.
Consider,
String
Making String.intern() more scalable doesn't seem to be a
solution for short (or medium?) time frame. Even if the
computation cost of ObjectName.equals() is increased by
this fix, there's no performance measurement in favor or
against this change. I've looked for benchmarks stressing
the ObjectNam
The fix looks good.
Thanks,
Masayoshi
On 2/22/2012 3:19 AM, Seán Coffey wrote:
I've worked with Masayoshi on this issue. Hoping to push to JDK8 and
backport to 7u and a jdk6 once baked for a while.
Some windows boxes were showing performance issues when attempting to
iterate through all avai
On 02/24/2012 09:54 AM, Stuart Marks wrote:
On 2/22/12 1:25 PM, Kurchi Hazra wrote:
On 2/22/2012 10:01 AM, Rémi Forax wrote:
Hi Kurchi, hi all,
in ReliableLog, you can get ride of the @SupressWarnings,
getLogClassConstructor should return a Constructor and not a
Constructor
extends LogFile>,
On 2/22/12 1:25 PM, Kurchi Hazra wrote:
On 2/22/2012 10:01 AM, Rémi Forax wrote:
Hi Kurchi, hi all,
in ReliableLog, you can get ride of the @SupressWarnings,
getLogClassConstructor should return a Constructor and not a Constructor,
the field logClassConstructor should be typed Constructor and
i
I'm in favor of not adding complexity to ObjectName.equals().
The goal of this CR is to remove a bottleneck created by the use
of String.intern() in ObjectName's constructors. This CR doesn't
aim to optimize the ObjectName.equals() method.
An application can define an optimized method to compare
20 matches
Mail list logo
