System.identityHashCode performance
I would like to ask about any plans of speed improvements to System.identityHashCode or IdentityHashMap I use EclipseLink and it uses IdentityHashMap for storing entities and their clones. In my case System.identityHashCode consumes 54% of time during insert data to database. There are lots of other project using IdentityHashMap and identityHashCode. Thank you very much Martin PS sorry for my english
hg: jdk7/tl/jdk: 2 new changesets
Changeset: 023063a403ed Author:chegar Date: 2009-09-22 14:42 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/023063a403ed 6882654: Remove dependency on java.util.concurrent from KeepAlive implementaion Reviewed-by: michaelm ! src/share/classes/sun/net/www/http/KeepAliveCache.java ! src/share/classes/sun/net/www/http/KeepAliveStream.java ! src/share/classes/sun/net/www/http/KeepAliveStreamCleaner.java Changeset: 44ccaa4bb8a0 Author:chegar Date: 2009-09-22 14:49 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/44ccaa4bb8a0 6882384: Update http protocol handler to use PlatformLogger Reviewed-by: jccollet, alanb ! src/share/classes/sun/net/www/http/HttpCapture.java ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/protocol/http/HttpLogFormatter.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/net/www/protocol/http/NTLMAuthenticationProxy.java ! src/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java ! src/share/classes/sun/util/logging/PlatformLogger.java
Re: Re: System.identityHashCode performance
It was on JDK 1.6.0_u16 client compiler. Persisting about 2 000 large entities (~45 attributes) and 200 000 entities (~4 attributes) in one transaction (tuned with: batch writes, cache all statements, batch size = 200, bind all parameters) Profiler: JProfiler version 4.2.4 I'm not JDK guru so I'm not able to make a patch. I just found that there is used RegisterNatives in Object.hashCode, but not in System.identityHashCode. Thank you. - Original Message - From: Christian Thalinger christian.thalin...@sun.com To: Tom Hawtin thomas.haw...@sun.com Cc: Janda Martin jan...@crcdata.cz, core-libs-dev@openjdk.java.net Sent: Tuesday, September 22, 2009 1:47:44 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: System.identityHashCode performance Tom Hawtin wrote: Janda Martin wrote: I would like to ask about any plans of speed improvements to System.identityHashCode or IdentityHashMap I use EclipseLink and it uses IdentityHashMap for storing entities and their clones. In my case System.identityHashCode consumes 54% of time during insert data to database. There are lots of other project using IdentityHashMap and identityHashCode. CR 6378256 seems to cover this for the client/C1 compiler. Presumably the server/C2 compiler already intrinsifies the method. It's been in fix understood for a couple of years... http://bugs.sun.com/view_bug.do?bug_id=6378256 Martin, are you having performance problems with client or server compiler? -- Christian
hg: jdk7/tl/jdk: 2 new changesets
Changeset: b8004f6f4812 Author:kevinw Date: 2009-09-22 17:01 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b8004f6f4812 6882768: (launcher) test for 6842838 is broken Summary: Testcase correction. Reviewed-by: ksrini ! test/tools/launcher/6842838/Test6842838.sh Changeset: f708138c9aca Author:kevinw Date: 2009-09-22 17:16 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f708138c9aca Merge
Re: 4206909 - adding Z_SYNC_FLUSH support to deflaters
Thanks Alan! The webrev has been updated accordingly to address your comments (use syncFlush instead of doSyncFlush and those suggestions for Deflater.java). http://cr.openjdk.java.net/~sherman/zipflush/webrev Sherman PS. There was a take2 for DOS that I think might be more consistent with the existing APIs, but it might be the time to focus on one approach. If you're interested the take2 is at http://cr.openjdk.java.net/~sherman/zipflush/webrev.take2/src/share/classes/java/util/zip/DeflaterOutputStream.java.sdiff.html Alan Bateman wrote: Welcome back (for some reason I thought you were gone for two weeks). It would be best to send the proposal to the mailing list so that others can comment. Personally, I don't like exposing the flush mode to subclasses but you are right that it is more consistent with the original design. If this approach is chosen then I would suggest that the flush implementation make a copy of the flush mode before testing and using it. Also, the new constructors will need to say that they initialize the flush mode based on the parameter (since it can change on the fly). BTW: What is the reason for renaming the parameter to flushDef. I prefer syncFlush over doSyncFlush. I'm happy with Deflater. In the description of SYNC_FLUSH I would suggest changing the , into a ; or else make it into two sentences. In the new deflate method the description of NO_FLUSH needs a comma after accumulate for it to flow well. Similar issue in the SYNC_FLUSH description where you need a comma after is flushed. There is also a typo [ comparssed :-) ] -Alan.
Re: hg: jdk7/tl/jdk: 2 new changesets
Hi Rob, Rob Leland wrote: ..Mandy, Three questions. -import java.util.logging.Logger; +import sun.util.logging.PlatformLogger; It seems counter intuitive that a dependency would be change from a java.* - sun.* since this the OpenJDK ,why not add it to java.util.log.* ? Alan answered this question (thanks Alan). sun.util.logging.PlatformLogger is a private unsupported API added for internal JDK implementation use. Then the JavaDocs says : This enables the runtime components to eliminate the static dependency of the logging facility In addition, the PlatformLogger API can be used if the logging module does not exist. What use case required this ? Then is this meant to be similar to Apache commons-logging which also has a basic logging functionality ? No. PlatformLogger is not designed to provide basic logging functionality but instead as a proxy to avoid direct dependency on java.util.logging for internal use. I guess the last sentence caused the confusion. Mandy On 9/18/2009 9:51 PM, mandy.ch...@sun.com wrote: Changeset: d3281fa8e46c Author:mchung Date: 2009-09-17 14:24 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d3281fa8e46c 6882376: Add internal support for JRE implementation to eliminate the dependency on logging Summary: Added sun.util.logging.PlatformLogger for JRE implementation to log messages. Reviewed-by: alanb, naoto ! make/java/logging/Makefile ! src/share/classes/java/util/Currency.java ! src/share/classes/java/util/jar/Attributes.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/LogRecord.java ! src/share/classes/sun/util/LocaleServiceProviderPool.java + src/share/classes/sun/util/logging/PlatformLogger.java ! src/windows/classes/java/util/prefs/WindowsPreferences.java + test/sun/util/logging/PlatformLoggerTest.java Changeset: 7b4e73ca6fd7 Author:mchung Date: 2009-09-18 17:27 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7b4e73ca6fd7 Merge __ Information from ESET NOD32 Antivirus, version of virus signature database 4439 (20090918) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
hg: jdk7/tl/jdk: 2 new changesets
Changeset: bbb543254c63 Author:martin Date: 2009-09-22 18:30 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bbb543254c63 4245470: algorithm of java.lang.Byte.hashCode() is not specified Summary: Specify some hashCode methods are equivalent to intValue Reviewed-by: darcy ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/Short.java + test/java/lang/HashCode.java Changeset: eb92c939b8a7 Author:martin Date: 2009-09-22 18:30 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/eb92c939b8a7 6582946: Add suite of compare(T, T) methods for ints, longs etc Reviewed-by: darcy Contributed-by: kev...@google.com ! src/share/classes/java/lang/Boolean.java ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java + test/java/lang/Compare.java
Re: What methods should go into a java.util.Objects class in JDK 7?
Joe Darcy wrote: Stephen Colebourne wrote: Joe Darcy wrote: What other utility methods would have broad enough use and applicability to go into a common java.util class? Joe, You've asked for a call for ideas, but not given any indication of process. Are you going to evaluate everything that comes in and pick the best a la Coin? Or allow anyone to send in patches? Those options are not mutually exclusive; patches are welcome subject to the usual terms and conditions. Who decides what is in and what is out? This is a little side project of mine and I wanted to get some feedback before preparing a formal change for review, possibly including patches from others. -Joe I'm getting caught up after the JVM Languages Summit and will post some java.util.Objects code for review in the near future. -Joe
