From xuelei.fan at oracle.com Fri Mar 1 10:35:40 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Fri, 01 Mar 2013 10:35:40 +0000 Subject: hg: jdk8/tl/jdk: 7030966: Support AEAD CipherSuites Message-ID: <20130301103619.27EE547512@hg.openjdk.java.net> Changeset: def2e05299b7 Author: xuelei Date: 2013-03-01 02:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/def2e05299b7 7030966: Support AEAD CipherSuites Reviewed-by: weijun, wetmore, valeriep ! src/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java ! src/share/classes/sun/security/internal/spec/TlsKeyMaterialParameterSpec.java ! src/share/classes/sun/security/internal/spec/TlsKeyMaterialSpec.java ! src/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java + src/share/classes/sun/security/ssl/Authenticator.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/EngineInputRecord.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/EngineWriter.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/InputRecord.java ! src/share/classes/sun/security/ssl/JsseJce.java ! src/share/classes/sun/security/ssl/MAC.java ! src/share/classes/sun/security/ssl/OutputRecord.java ! src/share/classes/sun/security/ssl/Record.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! test/sun/security/ec/TestEC.java ! test/sun/security/pkcs11/fips/CipherTest.java ! test/sun/security/pkcs11/sslecc/CipherTest.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java + test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKeyGCM.java ! test/sun/security/ssl/sanity/ciphersuites/CipherSuitesInOrder.java ! test/sun/security/ssl/sanity/interop/CipherTest.java ! test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java From alexey.utkin at oracle.com Fri Mar 1 11:45:55 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Fri, 01 Mar 2013 15:45:55 +0400 Subject: Request for review: 7190897 (fs) Files.isWritable method returns false when the path is writable (win). - ver. 1 In-Reply-To: <512F7A9C.4030905@oracle.com> References: <512F4574.5090909@oracle.com> <512F6A4A.3080300@oracle.com> <512F7500.8010106@oracle.com> <512F7A9C.4030905@oracle.com> Message-ID: <513094F3.4000701@oracle.com> On 28.02.2013 19:41, Alan Bateman wrote: > On 28/02/2013 15:17, Alexey Utkin wrote: >> That is not single, but 4 additional parameters ( FILE_GENERIC_READ, >> FILE_GENERIC_WRITE, FILE_GENERIC_EXECUTE, FILE_ALL_ACCESS) - that are >> relatively complicate masks. That parameters have to be changed >> consistently to avoid the problem (there is the analogy with >> orthogonal basis in geometry If you understand what I mean). Now we >> use the [AccessCheckForFile] just in [nio] package. We can extend the >> implementation any time we need it. > Okay, I can live with this but would be nice to get it to AccessCheck > at most point. I did. >>> checkFileAccess ignores the exception from AccessCheck whereas I >>> should it should be translated to an IOException. >> That is by design. Any problem with the [checkFileAccess] need to be >> converted to the [false] return value. At the end point - in the >> [WindowsFileSystemProvider.checkAccess] function - the [false] return >> value would be converted to the [AccessDeniedException] exception - >> that is desired code flow. > My point is that AccessCheck can fail for other reasons too and it > would be good to get these reason into the exception so that it is not > lost. It might have to AccessDeniedException if there aren't specific > errors documented but at least the reason will be in the exception > message to help someone figure it the issue. So I think it would be > better to translate the exception rather than returning a boolean. Done. >>> >>> Otherwise I think this is good. You don't have a test case but I >>> can't think how this could be tested anyway as we already have tests >>> for checkAccess and isWritable. >> I have the test. It is attached to the bug as Netbeans project, but >> it need manual security setup in security tab of the [demofile.txt] >> file (as shown in attached screenshot). By changing the "Write" check >> box on the [demofile.txt] file security dialog, test result have >> varying accordingly. >> Seems the web bug-db interface is not synchronized yet. > Thanks, I guessed that an automated test would not be possible. That is possible, but includes pre-requirements for installed MS tools. That is not a good idea. New version of the fix was prepared. Bug description: http://bugs.sun.com/view_bug.do?bug_id=7190897 https://jbs.oracle.com/bugs/browse/JDK-7190897 The suggested fix: http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7190897/webrev.01/ Regards, -uta From Alan.Bateman at oracle.com Fri Mar 1 14:44:09 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 01 Mar 2013 14:44:09 +0000 Subject: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so In-Reply-To: References: <5128AD43.2000809@oracle.com> <51292295.4040802@oracle.com> <512F63AB.2050204@oracle.com> Message-ID: <5130BEB9.7080801@oracle.com> On 28/02/2013 16:11, Martin Buchholz wrote: > > > On Thu, Feb 28, 2013 at 6:03 AM, Alan Bateman > wrote: > > The update to make/java/zip/Makefile looks good to me, we should > have done it a long time ago. I assume you are pushing ahead on > this because you want to push it to jdk7u-dev (as it's not > interesting to jdk8 now because of the new build). > > > Yes I'm hoping you push this fix to jdk7u. > > Also, I'm not sure that the new build system will not try to be > bug-for-bug compatible with the old one and will reintroduce the problem. The old build is on life-support, I don't know how long it will before it will terminally break or be removed. In any case, I wouldn't expect anyone to decide to change it to not use the map files. > The exciting new exception detail change looks okay to me too > although it is hard to read. It wasn't immediately obvious to me > why stddef.h was needed and we'd need to make sure that is okay on > all platforms. > > > It's hard to find something more standard than stddef.h. > It's hard to find something as non-standard as Windows. My point was we just need to double check that this builds okay on Windows, which is does. So I think you are all set on this one. -Alan. From Alan.Bateman at oracle.com Fri Mar 1 15:02:10 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 01 Mar 2013 15:02:10 +0000 Subject: Request for review: 7190897 (fs) Files.isWritable method returns false when the path is writable (win). - ver. 1 In-Reply-To: <513094F3.4000701@oracle.com> References: <512F4574.5090909@oracle.com> <512F6A4A.3080300@oracle.com> <512F7500.8010106@oracle.com> <512F7A9C.4030905@oracle.com> <513094F3.4000701@oracle.com> Message-ID: <5130C2F2.8070604@oracle.com> On 01/03/2013 11:45, Alexey Utkin wrote: > > That is possible, but includes pre-requirements for installed MS > tools. That is not a good idea. I agree. > > New version of the fix was prepared. > Bug description: > http://bugs.sun.com/view_bug.do?bug_id=7190897 > https://jbs.oracle.com/bugs/browse/JDK-7190897 > The suggested fix: > http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7190897/webrev.01/ This looks much better, thank you. A minor point is that in checkAccessMask then you could call OpenThreadToken before the try/finally. That way you wouldn't need to check hToken. Otherwise I think this is good to go and it's nice to finally fix this issue. -Alan From pbenedict at apache.org Fri Mar 1 15:38:44 2013 From: pbenedict at apache.org (Paul Benedict) Date: Fri, 1 Mar 2013 09:38:44 -0600 Subject: Should "packages" be opened by default in javadoc? Message-ID: jdk8b78 makes "profiles" the default view in the javadoc. However, I find that very disruptive to my usage; 99% of the time I will not be looking for profiles but locating packages. Since this is a new feature, I am sure there's room to hear feedback on the decision. Thanks, Paul From kasperni at gmail.com Fri Mar 1 15:44:27 2013 From: kasperni at gmail.com (Kasper Nielsen) Date: Fri, 1 Mar 2013 16:44:27 +0100 Subject: Should "packages" be opened by default in javadoc? In-Reply-To: References: Message-ID: Auch, yeah not really interested in the profile view either. (http://download.java.net/jdk8/docs/api/ for link) - Kasper On Fri, Mar 1, 2013 at 4:38 PM, Paul Benedict wrote: > jdk8b78 makes "profiles" the default view in the javadoc. However, I find > that very disruptive to my usage; 99% of the time I will not be looking for > profiles but locating packages. Since this is a new feature, I am sure > there's room to hear feedback on the decision. > > Thanks, > Paul > From Alan.Bateman at oracle.com Fri Mar 1 15:55:22 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 01 Mar 2013 15:55:22 +0000 Subject: Should "packages" be opened by default in javadoc? In-Reply-To: References: Message-ID: <5130CF6A.8020308@oracle.com> On 01/03/2013 15:38, Paul Benedict wrote: > jdk8b78 makes "profiles" the default view in the javadoc. However, I find > that very disruptive to my usage; 99% of the time I will not be looking for > profiles but locating packages. Since this is a new feature, I am sure > there's room to hear feedback on the decision. > Yes, it's not right and there is more work needed here. I created 8006774 a few weeks ago to track this: http://bugs.sun.com/view_bug.do?bug_id=8006774 Click on the "All Packages" link to get the view that will be more familiar. -Alan From kelly.ohair at oracle.com Fri Mar 1 16:19:44 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 1 Mar 2013 08:19:44 -0800 Subject: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so In-Reply-To: <5130BEB9.7080801@oracle.com> References: <5128AD43.2000809@oracle.com> <51292295.4040802@oracle.com> <512F63AB.2050204@oracle.com> <5130BEB9.7080801@oracle.com> Message-ID: <88A911BC-ED7F-47FF-A213-0FDE2F1D14E3@oracle.com> On Mar 1, 2013, at 6:44 AM, Alan Bateman wrote: >> It's hard to find something more standard than stddef.h. >> > It's hard to find something as non-standard as Windows. My point was we just need to double check that this builds okay on Windows, which is does. The only issue I have seen with adding includes, even standard ones like these, is that they tend to drag in so many more hidden include files, and there could be a chance at a compiler error. But that's fairly easy to diagnose, either it builds or it doesn't. What makes it a bit dangerous is that if it creates warning errors that are significant, we probably won't easily see them because we are not using -Werror across the board. :^( Having said that, my job is to be paranoid, and this does border on paranoia, so I say add the stddef.h and damn the torpedos, full steam ahead. -kto From mark.reinhold at oracle.com Fri Mar 1 17:59:23 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 1 Mar 2013 09:59:23 -0800 (PST) Subject: JEP 176: Mechanical Checking of Caller-Sensitive Methods Message-ID: <20130301175923.6475FCF8@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/176 - Mark From mark.reinhold at oracle.com Fri Mar 1 18:13:41 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 1 Mar 2013 10:13:41 -0800 (PST) Subject: JEP 177: Optimize java.text.DecimalFormat.format Message-ID: <20130301181341.32214DDF@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/177 - Mark From jonathan.gibbons at oracle.com Fri Mar 1 19:35:15 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 01 Mar 2013 19:35:15 +0000 Subject: hg: jdk8/tl/langtools: 8008949: javadoc stopped copying doc-files Message-ID: <20130301193521.0B3404752A@hg.openjdk.java.net> Changeset: 6f988040a1c8 Author: jjg Date: 2013-03-01 10:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6f988040a1c8 8008949: javadoc stopped copying doc-files Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java + test/com/sun/javadoc/testDocFiles/TestDocFiles.java + test/com/sun/javadoc/testDocFiles/pkg/Test.java + test/com/sun/javadoc/testDocFiles/pkg/doc-files/test.txt From jim.gish at oracle.com Fri Mar 1 21:25:24 2013 From: jim.gish at oracle.com (Jim Gish) Date: Fri, 01 Mar 2013 16:25:24 -0500 Subject: RFR: 8002070 Remove the stack search for a resource bundle for Logger to use Message-ID: <51311CC4.5000106@oracle.com> Please review http://cr.openjdk.java.net/~jgish/Bug8002070-RemoveResourceBundleStackSearch/ This removes the stack search from Logger.findResourceBundle() Note that because this is a change in the spec/functionality, a CCC request will be filed. Thanks, Jim -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From sean.mullan at oracle.com Fri Mar 1 21:26:11 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Fri, 01 Mar 2013 21:26:11 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130301212643.176DB477C3@hg.openjdk.java.net> Changeset: 1652ac7b4bfd Author: mullan Date: 2013-03-01 16:12 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1652ac7b4bfd 8008908: Access denied when invoking Subject.doAsPrivileged() Summary: wildcard principal names are not processed correctly Reviewed-by: xuelei ! src/share/classes/sun/security/provider/PolicyFile.java + test/sun/security/provider/PolicyFile/WildcardPrincipalName.java + test/sun/security/provider/PolicyFile/wildcard.policy Changeset: 1ca712765acb Author: mullan Date: 2013-03-01 16:15 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1ca712765acb Merge From kumar.x.srinivasan at oracle.com Fri Mar 1 21:52:19 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 01 Mar 2013 13:52:19 -0800 Subject: RFR: JDK-8007297: [pack200] allow opcodes with InterfaceMethodRefs Message-ID: <51312313.2060109@oracle.com> Hello, I will be pushing these changes reviewed by jrose, please let me know if you have any comments. Bug: https://jbs.oracle.com/bugs/browse/JDK-8007297 Webrev: http://cr.openjdk.java.net/~ksrini/8007297/webrev.jdk.2/ Thanks Kumar From dan.xu at oracle.com Fri Mar 1 22:30:57 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Fri, 01 Mar 2013 22:30:57 +0000 Subject: hg: jdk8/tl/jdk: 8006645: TEST_BUG: java/nio/file/Files/CopyAndMove.java failing intermittently (sol) Message-ID: <20130301223119.D494B477C9@hg.openjdk.java.net> Changeset: 30e30ef6077e Author: dxu Date: 2013-03-01 14:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/30e30ef6077e 8006645: TEST_BUG: java/nio/file/Files/CopyAndMove.java failing intermittently (sol) Summary: Fix test failures and update java doc of Files.move Reviewed-by: alanb, chegar ! src/share/classes/java/nio/file/Files.java ! test/java/nio/file/Files/CopyAndMove.java From mandy.chung at oracle.com Fri Mar 1 22:48:51 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 01 Mar 2013 14:48:51 -0800 Subject: RFR: 8002070 Remove the stack search for a resource bundle for Logger to use In-Reply-To: <51311CC4.5000106@oracle.com> References: <51311CC4.5000106@oracle.com> Message-ID: <51313053.2080605@oracle.com> On 3/1/2013 1:25 PM, Jim Gish wrote: > Please review > http://cr.openjdk.java.net/~jgish/Bug8002070-RemoveResourceBundleStackSearch/ > > This removes the stack search from Logger.findResourceBundle() > It's good to see this stack walk search of resource bundle going away. In Logger.java, the existing implementation returns the previous cached resource bundle if it fails to find one matching the current locale but the name matches: 1608 if (name.equals(catalogName)) { 1609 // Return the previous cached value for that name. 1610 // This may be null. 1611 return catalog; 1612 } Your fix removes these lines which I think is fine. The Logger.getResourceBundle method specifies to return the resource bundle for this logger for the current default locale. I think it'd be rare to change the default locale during the execution of an application. I suggest to document this behavioral change as well in the bug report and CCC. Thanks Mandy From joe.darcy at oracle.com Sat Mar 2 02:06:15 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 01 Mar 2013 18:06:15 -0800 Subject: JDK 8 RFR: 8009267: Restore isAnnotationPresent methods in public AnnotatedElement implementations Message-ID: <51315E97.6010406@oracle.com> Hello, The changes pushed under 8007113: Upgrade AnnotatedElement.isAnnotionPresent to be a default method http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e04467fa13af combined with how javac currently models default methods under pre-JDK-8 source versions can result in some source compatibility impacts for those using JDK 8 to compile under older source versions if the recommended practice of setting the bootclasspath is not followed. [1] To mitigate these impacts, I'm proposing the changes in 8009267: Restore isAnnotationPresent methods in public AnnotatedElement implementations http://cr.openjdk.java.net/~darcy/8009267.1/ which have the effect of restoring a concrete isAnnotationPresent method to Class, Package, Field, Method, and Constructor. The implementation delegates to the default method on the AnnotatedElement interface. Thanks, -Joe [1] http://mail.openjdk.java.net/pipermail/compiler-dev/2013-February/005738.html From jeroen at sumatra.nl Sat Mar 2 08:46:21 2013 From: jeroen at sumatra.nl (Jeroen Frijters) Date: Sat, 2 Mar 2013 08:46:21 +0000 Subject: JEP 176: Mechanical Checking of Caller-Sensitive Methods In-Reply-To: <20130301175923.6475FCF8@eggemoggin.niobe.net> References: <20130301175923.6475FCF8@eggemoggin.niobe.net> Message-ID: Hi John, This is really great. I've been using an annotation for caller sensitive methods for many year in IKVM as a performance enhancement and I can say that my experiences with my simple mechanism are really great. I've got a class ikvm.internal.CallerID that looks something like this: public final class CallerID { @Internal (IKVM specific annotation meaning that it is only public in the module) public native Call getCallerClass(); @Internal public native ClassLoader getClassClassLoader(); @Internal public static native getCallerID(); } Any (trusted) method with an ikvm.internal.HasCallerID annotation can call the CallerID.getCallerID() intrinsic and from there on the CallerID object gets explicitly passed around to other methods when necessary. I modified sun.reflect.MethodAccessor.invoke() to have an additional CallerID parameter and MethodHandles.Lookup is also CallerID based. JNI methods automatically act as if they have a HasCalleriD annotation and store the caller on a stack inside the thread's JNIEnv. (I'm not suggesting HotSpot uses the same design, that probably doesn't make sense. Just that in the many years I've used this, I've found the explicit caller sensitive annotation and explicitly passing around a cookie that represents the caller to be an efficient and secure way to handle this.) Regards, Jeroen > -----Original Message----- > From: core-libs-dev-bounces at openjdk.java.net [mailto:core-libs-dev- > bounces at openjdk.java.net] On Behalf Of mark.reinhold at oracle.com > Sent: Friday, March 1, 2013 18:59 > To: john.r.rose at oracle.com > Cc: core-libs-dev at openjdk.java.net > Subject: JEP 176: Mechanical Checking of Caller-Sensitive Methods > > Posted: http://openjdk.java.net/jeps/176 > > - Mark From chris.hegarty at oracle.com Sat Mar 2 08:56:36 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sat, 02 Mar 2013 08:56:36 +0000 Subject: hg: jdk8/tl/jdk: 8008378: FJP.commonPool support parallelism 0, add awaitQuiescence Message-ID: <20130302085658.C3B57477DA@hg.openjdk.java.net> Changeset: f08ad5938709 Author: chegar Date: 2013-03-02 08:54 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f08ad5938709 8008378: FJP.commonPool support parallelism 0, add awaitQuiescence Reviewed-by: chegar Contributed-by: Doug Lea
, Chris Hegarty ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinTask.java + test/java/util/concurrent/forkjoin/ThreadLessCommon.java + test/java/util/concurrent/forkjoin/ThrowingRunnable.java From aph at redhat.com Sat Mar 2 09:11:38 2013 From: aph at redhat.com (Andrew Haley) Date: Sat, 02 Mar 2013 09:11:38 +0000 Subject: JEP 176: Mechanical Checking of Caller-Sensitive Methods In-Reply-To: <20130301175923.6475FCF8@eggemoggin.niobe.net> References: <20130301175923.6475FCF8@eggemoggin.niobe.net> Message-ID: <5131C24A.1040700@redhat.com> On 03/01/2013 05:59 PM, mark.reinhold at oracle.com wrote: > Posted: http://openjdk.java.net/jeps/176 Yes, please. This doesn't solve the whole problem, but it makes it much more tractable. There is still the risk of application code getting this wrong by using other methods to find their callers, but this makes it a whole lot easier to get things right. Andrew. From forax at univ-mlv.fr Sat Mar 2 11:06:16 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 02 Mar 2013 12:06:16 +0100 Subject: JEP 176: Mechanical Checking of Caller-Sensitive Methods In-Reply-To: References: <20130301175923.6475FCF8@eggemoggin.niobe.net> Message-ID: <5131DD28.9090902@univ-mlv.fr> On 03/02/2013 09:46 AM, Jeroen Frijters wrote: > Hi John, > > This is really great. I've been using an annotation for caller sensitive methods for many year in IKVM as a performance enhancement and I can say that my experiences with my simple mechanism are really great. > > I've got a class ikvm.internal.CallerID that looks something like this: > > public final class CallerID { > @Internal (IKVM specific annotation meaning that it is only public in the module) > public native Call getCallerClass(); > > @Internal > public native ClassLoader getClassClassLoader(); > > @Internal > public static native getCallerID(); > } > > Any (trusted) method with an ikvm.internal.HasCallerID annotation can call the CallerID.getCallerID() intrinsic and from there on the CallerID object gets explicitly passed around to other methods when necessary. I modified sun.reflect.MethodAccessor.invoke() to have an additional CallerID parameter and MethodHandles.Lookup is also CallerID based. > > JNI methods automatically act as if they have a HasCalleriD annotation and store the caller on a stack inside the thread's JNIEnv. > > (I'm not suggesting HotSpot uses the same design, that probably doesn't make sense. Just that in the many years I've used this, I've found the explicit caller sensitive annotation and explicitly passing around a cookie that represents the caller to be an efficient and secure way to handle this.) > > Regards, > Jeroen I've always found that getCallerClass() was done at the wrong side of the problem, i.e. asked inside the callee instead of being inserted at callsite. It's so easy to do that with invokedynamic that I think the best way to implement getCallerClass is to teach the compiler to emit an invokedynamic instead of an invokevirtual/static for method marked with the annotation saying they need the caller class (this bytecode replacement can also be done by the VM when re-writing bytecodes). From the security poin of view, the verifier has to verify that each method annotated can only be called using an invokedynamic with a bootstrap method which is well known. This is basically how I've implemented MethodHandles.lookup() in the backport. cheers, R?mi > >> -----Original Message----- >> From: core-libs-dev-bounces at openjdk.java.net [mailto:core-libs-dev- >> bounces at openjdk.java.net] On Behalf Of mark.reinhold at oracle.com >> Sent: Friday, March 1, 2013 18:59 >> To: john.r.rose at oracle.com >> Cc: core-libs-dev at openjdk.java.net >> Subject: JEP 176: Mechanical Checking of Caller-Sensitive Methods >> >> Posted: http://openjdk.java.net/jeps/176 >> >> - Mark From jeroen at sumatra.nl Sat Mar 2 11:27:54 2013 From: jeroen at sumatra.nl (Jeroen Frijters) Date: Sat, 2 Mar 2013 11:27:54 +0000 Subject: JEP 176: Mechanical Checking of Caller-Sensitive Methods In-Reply-To: <5131DD28.9090902@univ-mlv.fr> References: <20130301175923.6475FCF8@eggemoggin.niobe.net> <5131DD28.9090902@univ-mlv.fr> Message-ID: Remi Forax wrote: > I've always found that getCallerClass() was done at the wrong side of > the problem, i.e. asked inside the callee instead of being inserted at > callsite. Yes, I agree and in fact in the IKVM implementation a CallerID parameter is added to each method that has the HasCallerID annotation. The reason for the CallerID abstraction instead of simply passing a Class is performance. Constructing a Class is expensive on IKVM (and was even more expensive back when CallerID was introduced) and in many cases caller sensitive methods are only sometimes caller sensitive, so I want the class construction to be lazy. It's also possible to return the ClassLoader without actually constructing the class. >From the .NET side an IKVM HasCallerID method looks something like this: public class Class { [EditorBrowsable(Never)] // hide from .NET IDEs public static Class forName(String name, CallerID callerID) { ... } public static Class forName(String name) { return forName(name, CallerID.create(new StackFrame(1))); } } The Java compiler calls the method with the explicit CallerID parameter and .NET code can simply call the other method. Regards, Jeroen From nicole.haenni at gmail.com Sat Mar 2 11:34:44 2013 From: nicole.haenni at gmail.com (Nicole Haenni) Date: Sat, 2 Mar 2013 12:34:44 +0100 Subject: Survey for framework and library developers & users: "Information needs across software ecosystems" In-Reply-To: References: Message-ID: Hi, I?m Nicole Haenni and I'm doing research for my thesis at the University of Berne (scg.unibe.ch) with Mircea Lungu and Niko Schwarz. We are researching on monitoring the activity in software ecosystems. This is a study about information needs that arise in such software ecosystems. I need your help to fill out the survey below. It takes about 10 minutes to complete it. A software ecosystem can be a project repository like GitHub, an open source community (e.g. the Apache community) or a language-based community (e.g. Smalltalk has Squeaksource, Ruby has Rubyforge). We formulate our research question as follows: "What information needs arise when developers use code from other projects, or see their own code used elsewhere." Survey link: http://bit.ly/14Zc71N or original link: https://docs.google.com/spreadsheet/viewform?formkey=dFBJUmVodVU1V3BMMGRPRWxBdjdDbVE6MA Thank you for your support! Nicole Haenni ----------------------------------------- Software Composition Group Institut f?r Informatik Universit?t Bern Neubr?ckstrasse 10 CH-3012 Bern SWITZERLAND From tbuktu at hotmail.com Sat Mar 2 12:41:01 2013 From: tbuktu at hotmail.com (Tim Buktu) Date: Sat, 2 Mar 2013 13:41:01 +0100 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) Message-ID: It's been over a year since my original patch, and it's been over 3 years since Alan posted his patch. I think I'll stop holding my breath. Tim >/ From: Brian Burkhalter > />/ Subject: Re: core-libs-dev Digest, Vol 68, Issue 113 />/ Date: January 2, 2013 5:02:10 PM PST />/ To: core-libs-dev at openjdk.java.net />/ />/ Hello Tim, />/ />/ Thank you for the updates. We'll take a closer look at this as soon as practically feasible. I have only recently been transferred into the core-libs area and expect to be dealing with the learning curve for some time to come. />/ />/ Regards, />/ />/ Brian />/ />>/ Date: Sat, 29 Dec 2012 15:18:01 +0100 />>/ From: Tim Buktu > />>/ Subject: Review Request: BigInteger patch for efficient multiplication />>/ and division (#4837946) />>/ To: core-libs-dev at openjdk.java.net />>/ Message-ID: > />>/ Content-Type: text/plain; charset="ISO-8859-15" />>/ />>/ Hello, />>/ />>/ I updated my patch that speeds up multiplication and division of large />>/ BigIntegers. The changes vs. the older patch were trivial. />>/ />>/ BigInteger.java: https://gist.github.com/1576025 />>/ Diff against current BigInteger: https://gist.github.com/1576016 />>/ />>/ The patch to the unit test still applies. />>/ BigIntegerTest.java: https://gist.github.com/1586990 />>/ Diff against current BigIntegerTest.java: https://gist.github.com/1586984 />>/ />>/ See the original posts at />>/ http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-January/008860.html />>/ and />>/ http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-January/008875.html />>/ />>/ Comments and critique are appreciated. />>/ />>/ Thanks, />>/ Tim / From Alan.Bateman at oracle.com Sun Mar 3 14:15:49 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 03 Mar 2013 14:15:49 +0000 Subject: RFR: 8002070 Remove the stack search for a resource bundle for Logger to use In-Reply-To: <51311CC4.5000106@oracle.com> References: <51311CC4.5000106@oracle.com> Message-ID: <51335B15.9070809@oracle.com> On 01/03/2013 21:25, Jim Gish wrote: > Please review > http://cr.openjdk.java.net/~jgish/Bug8002070-RemoveResourceBundleStackSearch/ > > > > This removes the stack search from Logger.findResourceBundle() > > Note that because this is a change in the spec/functionality, a CCC > request will be filed. It's good to have this removed. The changes to the caching seem okay, at least I don't see anything obviously wrong. One suggestion is to change "SystemClassLoader" into system ClassLoader and link it to the ClassLoader.getSystemClassLoader. For the LoggerResourceBundleRace test then does it have to run in its own VM? -Alan. From fweimer at redhat.com Sun Mar 3 20:00:34 2013 From: fweimer at redhat.com (Florian Weimer) Date: Sun, 03 Mar 2013 21:00:34 +0100 Subject: Review Request for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly In-Reply-To: <512DF8CA.20109@oracle.com> References: <512D4F0B.8020903@oracle.com> <512D7009.70506@oracle.com> <512D74D7.2010902@oracle.com> <512DF6E9.4050100@gmail.com> <512DF8CA.20109@oracle.com> Message-ID: <5133ABE2.7080205@redhat.com> On 02/27/2013 01:15 PM, Alan Bateman wrote: > On 27/02/2013 12:07, Peter Levart wrote: >> >> What does a FileInputStream for example do when trying to open a File >> with embedded NUL chars on UNIX/Windows ? Does it try to open a >> "truncated" path? If so, then perhaps "normalize" could do that >> beforehand... > Yes, it's truncated. Dan's fix covers FileInputStream and friends too as > they go through the normalize code. You should throw an exception. Embedded NUL characters have been used to bypass security checks. The canonical example is an upload to a web server directory. You check that the file ends with ".jpg", so it won't be interpreted by the web server, but the full extension is actually ".php\000.jpg", so you end up writing a ".php" file, which is. Furthermore, dropping the NUL character is *extremely* dangerous because it could be used to bypass security checks which look for ".." to prevent directory traversal attacks. -- Florian Weimer / Red Hat Product Security Team From Alan.Bateman at oracle.com Sun Mar 3 21:01:04 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 03 Mar 2013 21:01:04 +0000 Subject: Review Request for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly In-Reply-To: <5133ABE2.7080205@redhat.com> References: <512D4F0B.8020903@oracle.com> <512D7009.70506@oracle.com> <512D74D7.2010902@oracle.com> <512DF6E9.4050100@gmail.com> <512DF8CA.20109@oracle.com> <5133ABE2.7080205@redhat.com> Message-ID: <5133BA10.8000103@oracle.com> On 03/03/2013 20:00, Florian Weimer wrote: > You check that the file ends with ".jpg", so it won't be interpreted > by the web server, but the full extension is actually ".php\000.jpg", > so you end up writing a ".php" file, which is. The application have have the path String ".php\000.jpg" but when you create the file (with FileOutputStream or other APIs) then it would be ".php.jpg". Another potential approach is to just fail when attempting to create the file but changing File's constructor to throw an exception would be an incompatible change. -Alan From fweimer at redhat.com Sun Mar 3 21:12:57 2013 From: fweimer at redhat.com (Florian Weimer) Date: Sun, 03 Mar 2013 22:12:57 +0100 Subject: Review Request for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly In-Reply-To: <5133BA10.8000103@oracle.com> References: <512D4F0B.8020903@oracle.com> <512D7009.70506@oracle.com> <512D74D7.2010902@oracle.com> <512DF6E9.4050100@gmail.com> <512DF8CA.20109@oracle.com> <5133ABE2.7080205@redhat.com> <5133BA10.8000103@oracle.com> Message-ID: <5133BCD9.6060400@redhat.com> On 03/03/2013 10:01 PM, Alan Bateman wrote: > On 03/03/2013 20:00, Florian Weimer wrote: >> You check that the file ends with ".jpg", so it won't be interpreted >> by the web server, but the full extension is actually ".php\000.jpg", >> so you end up writing a ".php" file, which is. > The application have have the path String ".php\000.jpg" but when you > create the file (with FileOutputStream or other APIs) then it would be > ".php.jpg". Yes, that's the behavior with dropping, and it does help in this case. (I was arguing against truncation.) But dropping is unsafe, too, as I described in the second paragraph of my message. > Another potential approach is to just fail when attempting > to create the file I think this is what's required. It's what Python has been doing for some time. > but changing File's constructor to throw an exception > would be an incompatible change. I completely agree. I think I've written code myself which relies on the File(String) constructor not looking at the contents of the string. 8-/ -- Florian Weimer / Red Hat Product Security Team From kumar.x.srinivasan at oracle.com Mon Mar 4 05:45:44 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Mon, 04 Mar 2013 05:45:44 +0000 Subject: hg: jdk8/tl/jdk: 8007297: [pack200] allow opcodes with InterfaceMethodRefs Message-ID: <20130304054606.8A143477FE@hg.openjdk.java.net> Changeset: df76ba760eec Author: ksrini Date: 2013-03-03 20:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/df76ba760eec 8007297: [pack200] allow opcodes with InterfaceMethodRefs Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/share/classes/com/sun/java/util/jar/pack/Instruction.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/native/com/sun/java/util/jar/pack/constants.h ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! test/tools/pack200/AttributeTests.java ! test/tools/pack200/InstructionTests.java ! test/tools/pack200/Utils.java From alexey.utkin at oracle.com Mon Mar 4 09:31:36 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Mon, 04 Mar 2013 13:31:36 +0400 Subject: Request for review: 7190897 (fs) Files.isWritable method returns false when the path is writable (win). - ver. 1 In-Reply-To: <5130C2F2.8070604@oracle.com> References: <512F4574.5090909@oracle.com> <512F6A4A.3080300@oracle.com> <512F7500.8010106@oracle.com> <512F7A9C.4030905@oracle.com> <513094F3.4000701@oracle.com> <5130C2F2.8070604@oracle.com> Message-ID: <513469F8.4060606@oracle.com> Alan, Do you agree with > /** > * Check the access right against the securityInfo in the current > thread. > */ > static boolean checkAccessMask(long securityInfo, int accessMask, > int genericRead, int genericWrite, int genericExecute, int > genericAll) > throws WindowsException > { > int privilegies = TOKEN_QUERY; > long hToken = OpenThreadToken(GetCurrentThread(), privilegies, > false); > if (hToken == 0L && processTokenWithDuplicateAccess != 0L) > hToken = DuplicateTokenEx(processTokenWithDuplicateAccess, > privilegies); > > boolean hasRight = false; > if (hToken != 0L) { > try { > hasRight = AccessCheck(hToken, securityInfo, accessMask, > genericRead, genericWrite, genericExecute, > genericAll); > } finally { > CloseHandle(hToken); > } > } > return hasRight; > } implementation approach? Regards, -uta On 01.03.2013 19:02, Alan Bateman wrote: > A minor point is that in checkAccessMask then you could call > OpenThreadToken before the try/finally. That way you wouldn't need to > check hToken. Otherwise I think this is good to go and it's nice to > finally fix this issue. > > -Alan From Alan.Bateman at oracle.com Mon Mar 4 10:28:59 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 04 Mar 2013 10:28:59 +0000 Subject: @Supported design issues In-Reply-To: <20130228113121.144747@eggemoggin.niobe.net> References: <51266B7C.3040804@oracle.com>, <20130222150427.1712@eggemoggin.niobe.net>, <51293038.7090503@oracle.com> <20130228113121.144747@eggemoggin.niobe.net> Message-ID: <5134776B.9080800@oracle.com> On 28/02/2013 19:31, mark.reinhold at oracle.com wrote: > : > > If we're going to define a new annotation with this much visibility then > we should at least take the time to inventory the JDK-specific APIs that > we have, and those we reasonably expect to have in the near future, to > understand how many distinct levels are useful. I didn't see any replies to this but I'm willing to do an inventory. We need this for our modularity work anyway and I think we already have a good handle on most of what is in the com.sun hierarchy. There are also a few APIs, com.apple for example, where I'm actually interesting in establishing their status as they came in without too much discussion. > > I did just notice that the annotation's source file is in the langtools > repo rather than the jdk repo. What's the rationale for that? I think > most JDK developers would expect to find it in the jdk repo. > This is just build related as there are "supported" APIs in the langtools repository. I see Joe has added the already added the proposed annotation to com.sun.source. -Alan. From fweimer at redhat.com Mon Mar 4 11:02:00 2013 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 04 Mar 2013 12:02:00 +0100 Subject: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so In-Reply-To: References: Message-ID: <51347F28.6050407@redhat.com> On 02/22/2013 11:03 PM, Martin Buchholz wrote: > I've finally figured out why fastdebug jdk occasionally gives InternalError > in the zip code. In the distant past, I also saw this with product builds. Triggering conditions involved a JNI DSO calling dlopen(RTLD_GLOBAL) on another DSO which eventually triggered loading the system zlib. This might still be relevant on stock OpenJDK 7. IcedTea avoids this by linking against system zlib. -- Florian Weimer / Red Hat Product Security Team From Alan.Bateman at oracle.com Mon Mar 4 11:51:49 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 04 Mar 2013 11:51:49 +0000 Subject: Request for review: 7190897 (fs) Files.isWritable method returns false when the path is writable (win). - ver. 1 In-Reply-To: <513469F8.4060606@oracle.com> References: <512F4574.5090909@oracle.com> <512F6A4A.3080300@oracle.com> <512F7500.8010106@oracle.com> <512F7A9C.4030905@oracle.com> <513094F3.4000701@oracle.com> <5130C2F2.8070604@oracle.com> <513469F8.4060606@oracle.com> Message-ID: <51348AD5.8080301@oracle.com> On 04/03/2013 09:31, Alexey Utkin wrote: > Alan, > Do you agree with >> /** >> * Check the access right against the securityInfo in the current >> thread. >> */ >> static boolean checkAccessMask(long securityInfo, int accessMask, >> int genericRead, int genericWrite, int genericExecute, int >> genericAll) >> throws WindowsException >> { >> int privilegies = TOKEN_QUERY; >> long hToken = OpenThreadToken(GetCurrentThread(), >> privilegies, false); >> if (hToken == 0L && processTokenWithDuplicateAccess != 0L) >> hToken = DuplicateTokenEx(processTokenWithDuplicateAccess, >> privilegies); >> >> boolean hasRight = false; >> if (hToken != 0L) { >> try { >> hasRight = AccessCheck(hToken, securityInfo, accessMask, >> genericRead, genericWrite, genericExecute, >> genericAll); >> } finally { >> CloseHandle(hToken); >> } >> } >> return hasRight; >> } > implementation approach? Can the handle to the token (hToken) be 0? In my comment I was suggesting: long hToken = OpenThreadToken(...); try { ... } finally { CloseHandle(hToken); } but that doesn't work if OpenThreadToken succeeds with a handle of 0. If 0 is not possible then there are a few other clean-ups that we could do at a later time. -Alan From Alan.Bateman at oracle.com Mon Mar 4 11:56:53 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 04 Mar 2013 11:56:53 +0000 Subject: Request for review: 7190897 (fs) Files.isWritable method returns false when the path is writable (win). - ver. 1 In-Reply-To: <51348AD5.8080301@oracle.com> References: <512F4574.5090909@oracle.com> <512F6A4A.3080300@oracle.com> <512F7500.8010106@oracle.com> <512F7A9C.4030905@oracle.com> <513094F3.4000701@oracle.com> <5130C2F2.8070604@oracle.com> <513469F8.4060606@oracle.com> <51348AD5.8080301@oracle.com> Message-ID: <51348C05.9040406@oracle.com> On 04/03/2013 11:51, Alan Bateman wrote: > > > but that doesn't work if OpenThreadToken succeeds with a handle of 0. > If 0 is not possible then there are a few other clean-ups that we > could do at a later time. Ah, I remember now, we handle ERROR_NO_TOKEN so this means that hToken can be 0. So this means that the CloseHandle does need to check for 0 in the finally block. -Alan. From alexey.utkin at oracle.com Mon Mar 4 12:23:04 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Mon, 04 Mar 2013 16:23:04 +0400 Subject: Request for review: 7190897 (fs) Files.isWritable method returns false when the path is writable (win). - ver. 1 In-Reply-To: <51348AD5.8080301@oracle.com> References: <512F4574.5090909@oracle.com> <512F6A4A.3080300@oracle.com> <512F7500.8010106@oracle.com> <512F7A9C.4030905@oracle.com> <513094F3.4000701@oracle.com> <5130C2F2.8070604@oracle.com> <513469F8.4060606@oracle.com> <51348AD5.8080301@oracle.com> Message-ID: <51349228.9080807@oracle.com> On 04.03.2013 15:51, Alan Bateman wrote: > On 04/03/2013 09:31, Alexey Utkin wrote: >> Alan, >> Do you agree with >>> /** >>> * Check the access right against the securityInfo in the >>> current thread. >>> */ >>> static boolean checkAccessMask(long securityInfo, int accessMask, >>> int genericRead, int genericWrite, int genericExecute, int >>> genericAll) >>> throws WindowsException >>> { >>> int privilegies = TOKEN_QUERY; >>> long hToken = OpenThreadToken(GetCurrentThread(), >>> privilegies, false); >>> if (hToken == 0L && processTokenWithDuplicateAccess != 0L) >>> hToken = DuplicateTokenEx(processTokenWithDuplicateAccess, >>> privilegies); >>> We can have the situation with: 1) OpenThreadToken return 0 without exception - that is ok for thread without impersonation. 2) processTokenWithDuplicateAccess is 0 for some reason (weak precess privileges) For that case we have no access to process token without exception (hToken :=: 0). >>> boolean hasRight = false; >>> if (hToken != 0L) { So, in upper line we need to check token for non-empty value. ! Do you concern about the [false] return value for that case? >>> try { >>> hasRight = AccessCheck(hToken, securityInfo, >>> accessMask, >>> genericRead, genericWrite, genericExecute, >>> genericAll); Here is the actual work, that can make an exception (for example it happens for invalid SID) >>> } finally { >>> CloseHandle(hToken); If token was open it have to be closed without excuses. >>> } >>> } >>> return hasRight; >>> } >> implementation approach? > Can the handle to the token (hToken) be 0? In my comment I was > suggesting: > > long hToken = OpenThreadToken(...); > try { > ... > } finally { > CloseHandle(hToken); > } > but that doesn't work if OpenThreadToken succeeds with a handle of 0. > If 0 is not possible then there are a few other clean-ups that we > could do at a later time. >> Ah, I remember now, we handle ERROR_NO_TOKEN so this means that >> hToken can be 0. So this means that the CloseHandle does need to >> check for 0 in the finally block. >> >> -Alan. > > -Alan > From joe.darcy at oracle.com Mon Mar 4 15:35:11 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 04 Mar 2013 07:35:11 -0800 Subject: @Supported design issues In-Reply-To: <5134776B.9080800@oracle.com> References: <51266B7C.3040804@oracle.com>, <20130222150427.1712@eggemoggin.niobe.net>, <51293038.7090503@oracle.com> <20130228113121.144747@eggemoggin.niobe.net> <5134776B.9080800@oracle.com> Message-ID: <5134BF2F.1020009@oracle.com> On 03/04/2013 02:28 AM, Alan Bateman wrote: > On 28/02/2013 19:31, mark.reinhold at oracle.com wrote: >> : >> [snip] > >> >> I did just notice that the annotation's source file is in the langtools >> repo rather than the jdk repo. What's the rationale for that? I think >> most JDK developers would expect to find it in the jdk repo. >> > This is just build related as there are "supported" APIs in the > langtools repository. I see Joe has added the already added the > proposed annotation to com.sun.source. > > Just on this point for now, the jdk repo would be the more natural home for the jdk.Supported annotation, but as Alan notes, we put jdk.Supported in langtools for bootstrapping purposes since we want to use Supported in langtools as well. -Joe From yiming.wang at oracle.com Mon Mar 4 16:13:23 2013 From: yiming.wang at oracle.com (Eric Wang) Date: Tue, 05 Mar 2013 00:13:23 +0800 Subject: [PATCH] Review request: 8009259 TEST_BUG: sun/misc/Cleaner/exitOnThrow.sh failing intermittently Message-ID: <5134C823.5090402@oracle.com> Hi, Please help to review the fix below for bug 8009259 TEST_BUG: sun/misc/Cleaner/exitOnThrow.sh failing intermittently. http://cr.openjdk.java.net/~ewang/8009259/webrev.00/ The test failed due to wrong assumption of thread scheduling, so fix it to make test passes if exception thrown or fails if jtreg execution timeout. Thanks, Eric From joe.darcy at oracle.com Mon Mar 4 16:15:59 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 04 Mar 2013 08:15:59 -0800 Subject: JDK 8 RFR: 8009267: Restore isAnnotationPresent methods in public AnnotatedElement implementations In-Reply-To: <016701ce1796$1bcfa790$536ef6b0$@apache.org> References: <51315E97.6010406@oracle.com> <016701ce1796$1bcfa790$536ef6b0$@apache.org> Message-ID: <5134C8BF.3020702@oracle.com> On 03/02/2013 02:34 PM, Uwe Schindler wrote: > Looks good to me! > Are this the only methods in the corelib that were removed in favour of a default implementation in the interface? I would not described the method as "removed," but to my knowledge AnnotatedElement.isAnnotationPresent was the only existing interface method in the core libraries replaced by a default method. The intended use case for default methods is adding new methods to interface and that change has certainly been done in other parts of the API. Cheers, -Joe > > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > Apache Lucene PMC Member / Committer > Bremen, Germany > http://lucene.apache.org/ > >> -----Original Message----- >> From: Joe Darcy [mailto:joe.darcy at oracle.com] >> Sent: Saturday, March 02, 2013 3:06 AM >> To: Core-Libs-Dev >> Cc: Jonathan Gibbons; Alexander Buckley; Maurizio Cimadamore; >> uschindler at apache.org >> Subject: JDK 8 RFR: 8009267: Restore isAnnotationPresent methods in public >> AnnotatedElement implementations >> >> Hello, >> >> The changes pushed under >> >> 8007113: Upgrade AnnotatedElement.isAnnotionPresent to be a default >> method >> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e04467fa13af >> >> combined with how javac currently models default methods under pre-JDK-8 >> source versions can result in some source compatibility impacts for those >> using JDK 8 to compile under older source versions if the recommended >> practice of setting the bootclasspath is not followed. [1] >> >> To mitigate these impacts, I'm proposing the changes in >> >> 8009267: Restore isAnnotationPresent methods in public >> AnnotatedElement implementations >> http://cr.openjdk.java.net/~darcy/8009267.1/ >> >> which have the effect of restoring a concrete isAnnotationPresent method >> to Class, Package, Field, Method, and Constructor. The implementation >> delegates to the default method on the AnnotatedElement interface. >> >> Thanks, >> >> -Joe >> >> [1] >> http://mail.openjdk.java.net/pipermail/compiler-dev/2013- >> February/005738.html From sundararajan.athijegannathan at oracle.com Mon Mar 4 16:49:44 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Mon, 04 Mar 2013 16:49:44 +0000 Subject: hg: jdk8/tl/nashorn: 9 new changesets Message-ID: <20130304164950.17A2147812@hg.openjdk.java.net> Changeset: 071e859b371e Author: attila Date: 2013-02-27 15:20 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/071e859b371e 8009143: Eliminate Dynalink dependency on java.beans Reviewed-by: jlaskey, lagergren, sundar ! src/jdk/internal/dynalink/beans/AbstractJavaLinker.java ! src/jdk/internal/dynalink/beans/BeansLinker.java Changeset: 928ea3d8faf0 Author: attila Date: 2013-02-27 15:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/928ea3d8faf0 8009146: Eliminate some dead code in preparation for immutable AST Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/ir/Assignment.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/VarNode.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java Changeset: 1da9e37697f6 Author: attila Date: 2013-02-27 16:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1da9e37697f6 8009150: Previous dead code elimination was incomplete Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/ir/BinaryNode.java Changeset: 1e03be240534 Author: sundar Date: 2013-02-28 20:31 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1e03be240534 8009229: ant makefile default target should be "test" Reviewed-by: lagergren, jlaskey ! make/build.xml Changeset: 037e1de7ab1a Author: hannesw Date: 2013-02-28 22:59 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/037e1de7ab1a 8009240: RegExpScanner code is inefficient and too complex Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/runtime/regexp/JoniRegExp.java ! src/jdk/nashorn/internal/runtime/regexp/RegExpFactory.java ! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java Changeset: 7e9fbe621d87 Author: sundar Date: 2013-03-01 15:58 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/7e9fbe621d87 8009263: Fix all javadoc errors in nashorn code Reviewed-by: hannesw, lagergren ! make/project.properties ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java ! src/jdk/nashorn/internal/objects/DateParser.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! src/jdk/nashorn/internal/runtime/regexp/joni/EncodingHelper.java Changeset: 3b222c90b7de Author: jlaskey Date: 2013-03-02 11:26 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/3b222c90b7de Merge Changeset: f90810d79b57 Author: hannesw Date: 2013-03-04 11:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f90810d79b57 8008370: coffee script compiler doesn't work with Nashorn Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java + test/script/basic/JDK-8008370.js + test/script/basic/JDK-8008370.js.EXPECTED Changeset: fe5211fc3114 Author: jlaskey Date: 2013-03-04 11:01 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fe5211fc3114 8009379: Remove $ from generated class names Reviewed-by: attila, lagergren Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/MapCreator.java ! src/jdk/nashorn/internal/codegen/ObjectCreator.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java - src/jdk/nashorn/internal/scripts/JO$.java + src/jdk/nashorn/internal/scripts/JO.java - src/jdk/nashorn/internal/scripts/JS$.java + src/jdk/nashorn/internal/scripts/JS.java From yiming.wang at oracle.com Mon Mar 4 17:32:40 2013 From: yiming.wang at oracle.com (Eric Wang) Date: Tue, 05 Mar 2013 01:32:40 +0800 Subject: [PATCH] Review Request for 8009258: TEST_BUG: java/io/pathNames/GeneralWin32.java fails intermittently Message-ID: <5134DAB8.1070003@oracle.com> Hi, Please help to review fix below for bug 8009258 , TEST_BUG:java/io/pathNames/GeneralWin32.java fails intermittently. http://cr.openjdk.java.net/~ewang/8009258/webrev.00/ The File.canRead() method should not be used to check read permission of a directory. Thanks, Eric From Alan.Bateman at oracle.com Mon Mar 4 17:39:57 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 04 Mar 2013 17:39:57 +0000 Subject: [PATCH] Review Request for 8009258: TEST_BUG: java/io/pathNames/GeneralWin32.java fails intermittently In-Reply-To: <5134DAB8.1070003@oracle.com> References: <5134DAB8.1070003@oracle.com> Message-ID: <5134DC6D.5010905@oracle.com> On 04/03/2013 17:32, Eric Wang wrote: > Hi, > > Please help to review fix below for bug 8009258 > , > TEST_BUG:java/io/pathNames/GeneralWin32.java fails intermittently. > http://cr.openjdk.java.net/~ewang/8009258/webrev.00/ > > The File.canRead() method should not be used to check read permission > of a directory. > > Thanks, > Eric I wonder if it would be better to change this test so that it doesn't even attempt to poke around in these directories. I suggest this because there may be other activity going on at the same time. See also 8004096 where the test is running in agentvm mode and is straying into the directory used by another agent VM. -Alan From chris.hegarty at oracle.com Mon Mar 4 17:55:21 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 04 Mar 2013 17:55:21 +0000 Subject: [PATCH] Review request: 8009259 TEST_BUG: sun/misc/Cleaner/exitOnThrow.sh failing intermittently In-Reply-To: <5134C823.5090402@oracle.com> References: <5134C823.5090402@oracle.com> Message-ID: <5134E009.9010004@oracle.com> Eric, The change looks fine to me, although I have to admit I never seen this test fail before ( though I do see the small race window ). Let me know if you need a sponsor for this. -Chris. On 03/04/2013 04:13 PM, Eric Wang wrote: > Hi, > > Please help to review the fix below for bug 8009259 > TEST_BUG: > sun/misc/Cleaner/exitOnThrow.sh failing intermittently. > http://cr.openjdk.java.net/~ewang/8009259/webrev.00/ > > The test failed due to wrong assumption of thread scheduling, so fix it > to make test passes if exception thrown or fails if jtreg execution timeout. > > Thanks, > Eric From brian.burkhalter at oracle.com Mon Mar 4 18:04:30 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 4 Mar 2013 10:04:30 -0800 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: References: Message-ID: Probably a good idea. But seriously this patch is #5 in my queue. We do intend to get to it this spring. Brian On Mar 2, 2013, at 4:41 AM, Tim Buktu wrote: > It's been over a year since my original patch, and it's been over 3 years since Alan posted his patch. I think I'll stop holding my breath. From yiming.wang at oracle.com Mon Mar 4 18:13:11 2013 From: yiming.wang at oracle.com (Eric Wang) Date: Tue, 05 Mar 2013 02:13:11 +0800 Subject: [PATCH] Review request: 8009259 TEST_BUG: sun/misc/Cleaner/exitOnThrow.sh failing intermittently In-Reply-To: <5134E009.9010004@oracle.com> References: <5134C823.5090402@oracle.com> <5134E009.9010004@oracle.com> Message-ID: <5134E437.9090502@oracle.com> Hi Chris, Thank you if you can be the sponsor. Yes, it is very small probability as we executed the test on a local machine for 200 times on a local machine, but failed only 2 times. Regards, Eric On 2013/3/5 1:55, Chris Hegarty wrote: > Eric, > > The change looks fine to me, although I have to admit I never seen > this test fail before ( though I do see the small race window ). > > Let me know if you need a sponsor for this. > > -Chris. > > On 03/04/2013 04:13 PM, Eric Wang wrote: >> Hi, >> >> Please help to review the fix below for bug 8009259 >> TEST_BUG: >> sun/misc/Cleaner/exitOnThrow.sh failing intermittently. >> http://cr.openjdk.java.net/~ewang/8009259/webrev.00/ >> >> The test failed due to wrong assumption of thread scheduling, so fix it >> to make test passes if exception thrown or fails if jtreg execution >> timeout. >> >> Thanks, >> Eric From Alan.Bateman at oracle.com Mon Mar 4 18:25:06 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 04 Mar 2013 18:25:06 +0000 Subject: [PATCH] Review request: 8009259 TEST_BUG: sun/misc/Cleaner/exitOnThrow.sh failing intermittently In-Reply-To: <5134C823.5090402@oracle.com> References: <5134C823.5090402@oracle.com> Message-ID: <5134E702.6070006@oracle.com> On 04/03/2013 16:13, Eric Wang wrote: > Hi, > > Please help to review the fix below for bug 8009259 > TEST_BUG: > sun/misc/Cleaner/exitOnThrow.sh failing intermittently. > http://cr.openjdk.java.net/~ewang/8009259/webrev.00/ > > The test failed due to wrong assumption of thread scheduling, so fix > it to make test passes if exception thrown or fails if jtreg execution > timeout. I don't I've seen it fail either but I assume the Cleaner's System.exit terminates the VM before the the main thread gets to its System.exit(0). The change look good to me. One suggestion is to add 8009259 to the shell script that runs it. -Alan From staffan.larsen at oracle.com Mon Mar 4 18:56:21 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 4 Mar 2013 19:56:21 +0100 Subject: RFR(S): 8009397 test/com/sun/jdi/PrivateTransportTest.sh: ERROR: transport library missing onLoad entry: private_dt_socket Message-ID: <2A1F6D24-22FC-4CB4-84FD-05E8ECDDC9BF@oracle.com> I accidentally stepped on this bug the other day. There is a problem in linker_md.c : dll_build_name() where an internal pointer can be moved to point outside the string. The code looks like: 57 static void dll_build_name(char* buffer, size_t buflen, 58 const char* pname, const char* fname) { 59 // Based on os_solaris.cpp 60 61 char *path_sep = PATH_SEPARATOR; 62 char *pathname = (char *)pname; 63 while (strlen(pathname) > 0) { 64 char *p = strchr(pathname, *path_sep); 65 if (p == NULL) { 66 p = pathname + strlen(pathname); 67 } 68 /* check for NULL path */ 69 if (p == pathname) { 70 continue; 71 } 72 (void)snprintf(buffer, buflen, "%.*s/lib%s." LIB_SUFFIX, (p - pathname), 73 pathname, fname); 74 75 if (access(buffer, F_OK) == 0) { 76 break; 77 } 78 pathname = p + 1; 79 *buffer = '\0'; 80 } If the supplied pname is a buffer with a simple path without any path separators in it, p will be set to the terminating nul on line 66. Then on line 78 it will be moved outside the buffer. Fixing this also necessitates fixes to the callers to check for an empty return string (in buffer). The same code show up in both the solaris code and the windows code as well as hprof. bug: http://bugs.sun.com/view_bug.do?bug_id=8009397 webrev: http://cr.openjdk.java.net/~sla/8009397/webrev.00/ Thanks, /Staffan From joe.darcy at oracle.com Mon Mar 4 18:58:31 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 04 Mar 2013 10:58:31 -0800 Subject: @Supported design issues In-Reply-To: <20130228113121.144747@eggemoggin.niobe.net> References: <51266B7C.3040804@oracle.com>, <20130222150427.1712@eggemoggin.niobe.net>, <51293038.7090503@oracle.com> <20130228113121.144747@eggemoggin.niobe.net> Message-ID: <5134EED7.3040900@oracle.com> On 02/28/2013 11:31 AM, mark.reinhold at oracle.com wrote: > 2013/2/23 5:10 -0800, joe.darcy at oracle.com: >> On 2/22/2013 3:04 PM, mark.reinhold at oracle.com wrote: >>> ... >>> >>> - The annotation isn't a simple marker annotation, which is what I >>> expected at first glance; it takes a boolean parameter. Does this >>> mean that we have to go add "@Supported(false)" to everything that's >>> not supported? I'd have thought that anything not marked >>> "@Supported(true)" would by implication, well, not be supported. >>> Does it mean that if I mark a package "@Supported(true)" I can use >>> "@Supported(false)" on some of its member types? >> Having Supported take a boolean value both allows the explicit statement >> that an item is not supported as well as providing a possible transition >> path from Supported(true) to Supported(false) to removed. > Okay. In that scenario what's the role of the existing @Deprecated > annotation? @Deprecated generally applies to all clients of an API. I don't think people tend to associate potential removal of an API with deprecation because we haven't (yet) removed any deprecated Java SE APIs from the platform since to date we have placed a higher value on preserving binary compatibility. The deprecated-in-JDK-7 and JDK-specific apt API was removed in JDK 8, but that is the only removal of a deprecated API from the JDK I'm aware of offhand. The jdk.Supported annotation is mostly a statement to users outside of the JDK itself. >> We already have types in the JDK whose comments explicitly say "this is >> not part of any supported API" (much of javac). >> If there is no explicit opt-in to mark supportedness as well as >> non-supportedness in my estimation that means the status of all the >> unadorned APIs is uncertain: "Perhaps this interesting API was just >> overlooked in being marked supported, I'll go ahead and us it anyway..." > Okay, so that will give us a three-valued system: > > - @Supported(true) -- supported > - @Supported(false) -- not supported > - No @Supported annotation -- unknown (but probably not supported) > > I'm still wondering whether marking a package "@Supported(true)" means > that I can use "@Supported(false)" on some of its member types. That > would be convenient for cases such as the JMX OSMBeanFactory class that > Alan mentioned. If a package has a mixture of supported and non-supported types, I would say it should either *not* have a @jdk.Supported annotation itself, or if the types in the package were predominately one value or another, then the package annotation should match the prevailing value of the types. Since types have a more concrete existence then packages, I regard the jdk.Supported information on package-info files to have a higher mixture of informative versus normative sentiment compared to the annotation on types. [snip] > >>> - I agree with Martin that "supportedness", in the abstract, isn't a >>> binary thing. If we're going to define an annotation for broad use >>> then we should at least consider a metric with more than two values. >>> ... >> The status quo today and for the last 15 years has been often sloppy >> management of the types in com.sun.* Some of them are >> supported/stable/official/whatever others are not. Which are which is >> not clear. The closest mechanism to documenting this, aside what >> whatever comments might be in the code and the few subsets with >> published javadoc, are whether or not the types ends up in ct.sym >> proto-module system and if it does, whether or not a warning is issued >> when using the type. >> >> The ct.sym file is constructed by passing information from the docs make >> target to a program living in the langtools repo. So today the mechanism >> we have is a very an obscure system that does a poor job of conveying >> this kind of information and is easy to circumvent. > What we have today is certainly a maintenance headache for JDK > developers, who have to understand the obscure makefiles involved in > the construction of ct.sym. > > Between compile-time warnings and controlling javadoc output, however, > I'd say that it does an okay job of conveying the "supportedness" of > JDK-specific APIs to the rest of the world, though it could be better. > > What I don't understand is how doing all this with an annotation would > be any harder to circumvent than what we have today. Are you proposing > to do something stronger than issue a compiler warning when people try > to use an unsupported API? The ct.sym mechanism we have today is compile-time only and the mechanism and all its warnings can be circumvented by adding a single option to javac; the option is described on stackoverflow, amongst other places. Therefore, it is fairly easy for someone to claim "but I didn't know" in regards to the status of a JDK-specific API. Since any jdk.Supported annotations applied to types are more localized and more specific ("*this* type is or is not supported / stable / etc.") it is both easier for JDK developers to made incremental changes to the JDK code base and is it also easier for users of those types to see what is going on since any inspection of the types can reveal the annotation value. > >> If we go from that obscure system to an explicit boolean-valued >> annotation, that is in my estimation a vast improvement both in clarity >> and usability. > I agree that it's an improvement, in that it makes it easier for tools > beyond javac to determine the "supportedness" of an API. I can well > imagine IDEs leveraging this annotation to give advice to developers > ahead of compile time. > > Do you plan to change the makefiles for ct.sym, and the non-SE javadoc, > so that it's based on the new annotation rather than today's obscure > {,NON_}CORE_PKGS.gmk files? Otherwise the maintenance headache will > just get worse. My main concern for @Supported was actually accurately capturing the classification work Alan and others have already done as part of the pre-modularization effort. However, I agree it would be preferable to change how ct.sym was generated. > >>> These are, more or less, the Solaris "Stable", "Evolving", >>> "Unstable", and "Internal" levels, which suggests a single >>> "@Stability" annotation and an enum parameter with the values >>> STABLE, EVOLVING, UNSTABLE, and INTERNAL. >> As I indicated earlier in this thread, I agree there are more subtle >> distinctions that can be of interest, but at times the better is the >> enemy of the good and the first approximation of is this type or package >> supported or not is a huge improvement of what we have today even if it >> doesn't cover all the possible gradations. > The better can be the enemy of the good, yet the expedient can be the > enemy of the future. > > If we're going to define a new annotation with this much visibility then > we should at least take the time to inventory the JDK-specific APIs that > we have, and those we reasonably expect to have in the near future, to > understand how many distinct levels are useful. Agreed, and as indicated above, capturing the inventory that has already been done was the impetus for adding jdk.Supported at this time (I've thought about adding such a type to the JDK for several years). > > Would it make sense, e.g., for the streams SPI in Lambda to be marked > "unstable" rather than "not supported", so that javadoc for it is > generated yet no commitment is made to its current form? No; I think it is preferable to keep the streams types as a JDK implementation artifact to allow full de facto flexibility in designing the future SPI in that area. > > Even if we think we only need two explicit levels today, a design that > admits expansion is preferable to one that forever limits us to just two > values. An annotation that takes an enum, to which we can add values > over time, would be more future-proof. Technically, it would be possible to evolve a boolean-valued annotation to one that included a non-boolean value as well by adding a new method that had a default to the annotation type. For example // Version 1 @interfaced Supported { boolean value() default true; } // Version 2 @interface Supported { boolean value() default true; Stability stability() default STABLE; } However, if what we eventually want to capture is "stability level" rather than supported-ness than having a single stability value from the start would of course be preferable. That said, it terms of the exercise of going over the inventory of existing types, I think it can be helpful to at first be constrained to making a binary supported / not-supported determination to avoid the temptation to overuse a middle-of-the-road value like EVOLVING. Types that don't fit well into supported / not-supported classification can help drive what other distinctions are useful to make. > >>> - The retention policy of the annotation is RUNTIME. Is that really >>> what we want? I'd have expected CLASS. >> CLASS is not very helpful (and certainly not a helpful default). A >> CLASS-retention annotation can be reliably used at the compile-time of >> other code. For the use case of Supported, I think it is more helpful to >> allow runtime querying of the property. > What run-time use cases do you have in mind? Allowing class loaders and other run-time tools to query the annotation value and take some action, like log a warning or potentially refuse to link. > >>> - The annotation is in the top-level "jdk" package. What's the >>> rationale for this? I'd have expected it to be defined in >>> "jdk.annotations", so that if and when other JDK-specific >>> annotations arise we have one convenient place to find them, >>> and only them. >> There are 81 subtypes of java.lang.annotation.Annotation listed in JDK 8 b77 >> >> ... >> >> That gives a total of 42 annotation types defined in packages ending >> with "annotation" or about half of them. However, I would discount >> java.lang.annotation and javax.xml.bind.annotation as outliers, in which >> case most JDK annotations are *not* in a dedicated package. >> >> I think it is usually not helpful to segregate annotation types into >> dedicated packages, after all we don't have "enums", "interfaces", and >> "classes" packages and there are nearly as many annotations defined >> directly in java.lang (SuppressWarnings, Deprecated, Override, >> SafeVarargs, etc.) as in java.lang.annotation. ... > Fair enough. What struck me as odd about "jdk.Supported" is that it's > a type in a top-level package, which is not something we've ever had > before. It's a bit jarring, though not illogical, so I suppose I can > get used to it. As an aside, going forward I think we should make greater use of the "jdk.*" namespace for JDK-specific types. The JDK codebase has outlasted Sun Microsystems (R.I.P.) and therefore the natural lifetime of "com.sun.*." APIs. The JDK has also outlasted both of Sun Microsystems' ticker symbols (SUNW, and JAVA); as I understand their conventions, ticker symbols are a preferred component of Solaris package names. The "jdk" name will be appropriate as long as the JDK is around. > > I did just notice that the annotation's source file is in the langtools > repo rather than the jdk repo. What's the rationale for that? I think > most JDK developers would expect to find it in the jdk repo. As covered in other responses, while the jdk repo is the natural home, langtools was for bootstrapping reasons. Cheers, -Joe From yiming.wang at oracle.com Mon Mar 4 19:19:36 2013 From: yiming.wang at oracle.com (Eric Wang) Date: Tue, 05 Mar 2013 03:19:36 +0800 Subject: [PATCH] Review request: 8009259 TEST_BUG: sun/misc/Cleaner/exitOnThrow.sh failing intermittently In-Reply-To: <5134E702.6070006@oracle.com> References: <5134C823.5090402@oracle.com> <5134E702.6070006@oracle.com> Message-ID: <5134F3C8.3090607@oracle.com> On 2013/3/5 2:25, Alan Bateman wrote: > On 04/03/2013 16:13, Eric Wang wrote: >> Hi, >> >> Please help to review the fix below for bug 8009259 >> TEST_BUG: >> sun/misc/Cleaner/exitOnThrow.sh failing intermittently. >> http://cr.openjdk.java.net/~ewang/8009259/webrev.00/ >> >> The test failed due to wrong assumption of thread scheduling, so fix >> it to make test passes if exception thrown or fails if jtreg >> execution timeout. > I don't I've seen it fail either but I assume the Cleaner's > System.exit terminates the VM before the the main thread gets to its > System.exit(0). The change look good to me. One suggestion is to add > 8009259 to the shell script that runs it. > > -Alan Have updated, please review, Thanks! http://cr.openjdk.java.net/~ewang/8009259/webrev.01/ Eric From Alan.Bateman at oracle.com Mon Mar 4 19:20:31 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 04 Mar 2013 19:20:31 +0000 Subject: [PATCH] Review request: 8009259 TEST_BUG: sun/misc/Cleaner/exitOnThrow.sh failing intermittently In-Reply-To: <5134F3C8.3090607@oracle.com> References: <5134C823.5090402@oracle.com> <5134E702.6070006@oracle.com> <5134F3C8.3090607@oracle.com> Message-ID: <5134F3FF.4040600@oracle.com> On 04/03/2013 19:19, Eric Wang wrote: > > Have updated, please review, Thanks! > http://cr.openjdk.java.net/~ewang/8009259/webrev.01/ Looks good to me. -Alan From Alan.Bateman at oracle.com Mon Mar 4 20:07:26 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 04 Mar 2013 20:07:26 +0000 Subject: Request for review: 7190897 (fs) Files.isWritable method returns false when the path is writable (win). - ver. 1 In-Reply-To: <51349228.9080807@oracle.com> References: <512F4574.5090909@oracle.com> <512F6A4A.3080300@oracle.com> <512F7500.8010106@oracle.com> <512F7A9C.4030905@oracle.com> <513094F3.4000701@oracle.com> <5130C2F2.8070604@oracle.com> <513469F8.4060606@oracle.com> <51348AD5.8080301@oracle.com> <51349228.9080807@oracle.com> Message-ID: <5134FEFE.90208@oracle.com> On 04/03/2013 12:23, Alexey Utkin wrote: > : >>>> > > We can have the situation with: > 1) OpenThreadToken return 0 without exception - that is ok for thread > without impersonation. > 2) processTokenWithDuplicateAccess is 0 for some reason (weak precess > privileges) > For that case we have no access to process token without exception > (hToken :=: 0). >>>> boolean hasRight = false; >>>> if (hToken != 0L) { > So, in upper line we need to check token for non-empty value. > ! Do you concern about the [false] return value for that case? >>>> try { >>>> hasRight = AccessCheck(hToken, securityInfo, >>>> accessMask, >>>> genericRead, genericWrite, genericExecute, >>>> genericAll); > Here is the actual work, that can make an exception (for example it > happens for invalid SID) >>>> } finally { >>>> CloseHandle(hToken); > If token was open it have to be closed without excuses. >>>> } >>>> } >>>> return hasRight; >>>> } >>> implementation approach? >> Can the handle to the token (hToken) be 0? In my comment I was >> suggesting: >> >> long hToken = OpenThreadToken(...); >> try { >> ... >> } finally { >> CloseHandle(hToken); >> } This mail is hard to read but I think the implementation is good. -Alan. From mike.duigou at oracle.com Mon Mar 4 20:21:08 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 4 Mar 2013 12:21:08 -0800 Subject: RFR: 8006593: Performance and compatibility improvements to hash based Map implementations Message-ID: <79A5A703-12DA-4C66-94F7-34534761D217@oracle.com> Hello all; The alternative hashing implementation introduced in 7u6 added an unfortunate bottleneck to the initialization of HashMap and Hashtable instances. This patch avoids the performance bottleneck of using a shared Random instance by using a ThreadLocalRandom instead. Along with this change are some additional performance improvements to further reduce the overhead of the alternative hashing feature and generally improve the performance of Hashtable or HashMap. http://cr.openjdk.java.net/~mduigou/JDK-8006593/3/webrev/ Once review is completed here this patch will be proposed to JDK7u-dev for integration into the next 7u performance/feature release. Mike From mike.duigou at oracle.com Mon Mar 4 20:29:41 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 4 Mar 2013 12:29:41 -0800 Subject: RFR : JDK-8001642 : Add Optional, OptionalDouble, OptionalInt, OptionalLong Message-ID: Hello All; This patch introduces Optional container objects to be used by the lambda streams libraries for returning results. The reference Optional type, as defined, intentionally does not allow null values. null may be used with the Optional.orElse() method. All of the Optional types define hashCode() and equals implementations. Use of Optional types in collections should be generally discouraged but having useful equals() and hashCode() is ever so convenient. http://cr.openjdk.java.net/~mduigou/JDK-8001642/0/webrev/ Mike From eliasen at mindspring.com Mon Mar 4 21:44:48 2013 From: eliasen at mindspring.com (Alan Eliasen) Date: Mon, 04 Mar 2013 14:44:48 -0700 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: References: Message-ID: <513515D0.9070600@mindspring.com> On 03/04/2013 11:04 AM, Brian Burkhalter wrote: > Probably a good idea. > > But seriously this patch is #5 in my queue. We do intend to get to it > this spring. > > Brian > > On Mar 2, 2013, at 4:41 AM, Tim Buktu wrote: > >> It's been over a year since my original patch, and it's been over 3 >> years since Alan posted his patch. I think I'll stop holding my >> breath. That's good to hear. By the way, in case you didn't know the history of this bugfix, the leading researcher in the world in Toom-Cook and other techniques for high-performance multiplication, Marco Bodrato, and his colleagues, reviewed my parts of the patch (Karatsuba and Toom-Cook multiplication, Karatsuba and Toom-Cook squaring) and said they were "very clean." I also ran hundreds of gigabytes of test cases through it (repeatedly,) taking many days, and cross-checked my multiplication routines against several other packages including GMP and previous versions of BigInteger. -- Alan Eliasen eliasen at mindspring.com http://futureboy.us/ From peter.levart at gmail.com Mon Mar 4 22:14:41 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 04 Mar 2013 23:14:41 +0100 Subject: RFR: 8006593: Performance and compatibility improvements to hash based Map implementations In-Reply-To: <79A5A703-12DA-4C66-94F7-34534761D217@oracle.com> References: <79A5A703-12DA-4C66-94F7-34534761D217@oracle.com> Message-ID: <51351CD1.2030804@gmail.com> Hi mike, I doubt (haven't tried it really with your code) that hashSeed will be seen by code to be anything else but 0, since it is initialized to a constant value. For example, this code: public class ModifyingFinalTest { static final Unsafe unsafe; static final long valueOffset; static { try { Field f = Unsafe.class.getDeclaredField("theUnsafe"); f.setAccessible(true); unsafe = (Unsafe)f.get(null); valueOffset = unsafe.objectFieldOffset(ModifyingFinalTest.class.getDeclaredField("value")); } catch (IllegalAccessException | NoSuchFieldException e) { throw new Error(e); } } final int value = 0; void test() { unsafe.putIntVolatile(this, valueOffset, 1); printValue(); unsafe.putIntVolatile(this, valueOffset, 2); printValue(); unsafe.putIntVolatile(this, valueOffset, 3); printValue(); } void printValue() { System.out.println(value); } public static void main(String[] args) { new ModifyingFinalTest().test(); } } Prints: 0 0 0 It's a different thing, if the initialization is changed to: final int value = "".length(); But I don't know if each access in source is actually guaranteed to translate to a real read of field in this case either. Is Unsafe.putIntVolatile() making this happen somehow magically? Regards, Peter On 03/04/2013 09:21 PM, Mike Duigou wrote: > Hello all; > > The alternative hashing implementation introduced in 7u6 added an unfortunate bottleneck to the initialization of HashMap and Hashtable instances. This patch avoids the performance bottleneck of using a shared Random instance by using a ThreadLocalRandom instead. > > Along with this change are some additional performance improvements to further reduce the overhead of the alternative hashing feature and generally improve the performance of Hashtable or HashMap. > > http://cr.openjdk.java.net/~mduigou/JDK-8006593/3/webrev/ > > Once review is completed here this patch will be proposed to JDK7u-dev for integration into the next 7u performance/feature release. > > Mike > From peter.levart at gmail.com Mon Mar 4 22:25:36 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 04 Mar 2013 23:25:36 +0100 Subject: RFR: 8006593: Performance and compatibility improvements to hash based Map implementations In-Reply-To: <51351CD1.2030804@gmail.com> References: <79A5A703-12DA-4C66-94F7-34534761D217@oracle.com> <51351CD1.2030804@gmail.com> Message-ID: <51351F60.30502@gmail.com> On 03/04/2013 11:14 PM, Peter Levart wrote: > Hi mike, > > I doubt (haven't tried it really with your code) that hashSeed will be > seen by code to be anything else but 0, since it is initialized to a > constant value. For example, this code: > > public class ModifyingFinalTest { > static final Unsafe unsafe; > static final long valueOffset; > > static { > try { > Field f = Unsafe.class.getDeclaredField("theUnsafe"); > f.setAccessible(true); > unsafe = (Unsafe)f.get(null); > valueOffset = > unsafe.objectFieldOffset(ModifyingFinalTest.class.getDeclaredField("value")); > } > catch (IllegalAccessException | NoSuchFieldException e) { > throw new Error(e); > } > } > > final int value = 0; > > void test() { > unsafe.putIntVolatile(this, valueOffset, 1); > printValue(); > unsafe.putIntVolatile(this, valueOffset, 2); > printValue(); > unsafe.putIntVolatile(this, valueOffset, 3); > printValue(); > } > > void printValue() { > System.out.println(value); > } > > public static void main(String[] args) { > new ModifyingFinalTest().test(); > } > } > > > Prints: > > 0 > 0 > 0 > > > It's a different thing, if the initialization is changed to: > > final int value = "".length(); > > But I don't know if each access in source is actually guaranteed to > translate to a real read of field in this case either. Is > Unsafe.putIntVolatile() making this happen somehow magically? Well, that's not what I wanted to ask. I wanted to ask if the first access in source that happens after Unsafe.putIntVolatile() in same thread is guaranteed to read the field and not re-use a cached value ready in some register for example. Is Unsafe.putIntVolatile() making this happen somehow magically? > > Regards, Peter > > > On 03/04/2013 09:21 PM, Mike Duigou wrote: >> Hello all; >> >> The alternative hashing implementation introduced in 7u6 added an unfortunate bottleneck to the initialization of HashMap and Hashtable instances. This patch avoids the performance bottleneck of using a shared Random instance by using a ThreadLocalRandom instead. >> >> Along with this change are some additional performance improvements to further reduce the overhead of the alternative hashing feature and generally improve the performance of Hashtable or HashMap. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8006593/3/webrev/ >> >> Once review is completed here this patch will be proposed to JDK7u-dev for integration into the next 7u performance/feature release. >> >> Mike >> > From brian.burkhalter at oracle.com Mon Mar 4 22:28:12 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 4 Mar 2013 14:28:12 -0800 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: <513515D0.9070600@mindspring.com> References: <513515D0.9070600@mindspring.com> Message-ID: <028D2560-E5FA-41F3-941A-009D5CD6486E@oracle.com> Hi Alan, Thanks for the history: I was not myself aware of all that and it is good to know. Brian On Mar 4, 2013, at 1:44 PM, Alan Eliasen wrote: > That's good to hear. By the way, in case you didn't know the history > of this bugfix, the leading researcher in the world in Toom-Cook and > other techniques for high-performance multiplication, Marco Bodrato, and > his colleagues, reviewed my parts of the patch (Karatsuba and Toom-Cook > multiplication, Karatsuba and Toom-Cook squaring) and said they were > "very clean." I also ran hundreds of gigabytes of test cases through it > (repeatedly,) taking many days, and cross-checked my multiplication > routines against several other packages including GMP and previous > versions of BigInteger. From martinrb at google.com Mon Mar 4 22:36:56 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 4 Mar 2013 14:36:56 -0800 Subject: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so In-Reply-To: <51347F28.6050407@redhat.com> References: <51347F28.6050407@redhat.com> Message-ID: On Mon, Mar 4, 2013 at 3:02 AM, Florian Weimer wrote: > On 02/22/2013 11:03 PM, Martin Buchholz wrote: > > I've finally figured out why fastdebug jdk occasionally gives >> InternalError >> in the zip code. >> > > In the distant past, I also saw this with product builds. Triggering > conditions involved a JNI DSO calling dlopen(RTLD_GLOBAL) on another DSO > which eventually triggered loading the system zlib. This might still be > relevant on stock OpenJDK 7. > > IcedTea avoids this by linking against system zlib. It's certainly risky to have two separate system libraries in the same process using the same symbols. You are then very dependent on carefully using the linker (or utilties like objcopy) to produce "symbol jails" where one set of symbols cannot affect the other. Which is not consistent with traditional linker culture where there is a single global symbol namespace. From heinz at javaspecialists.eu Mon Mar 4 22:37:28 2013 From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz) Date: Tue, 5 Mar 2013 00:37:28 +0200 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: <028D2560-E5FA-41F3-941A-009D5CD6486E@oracle.com> References: <513515D0.9070600@mindspring.com> <028D2560-E5FA-41F3-941A-009D5CD6486E@oracle.com> Message-ID: Whilst we're at it, could we also add an option, perhaps via environment variable, to parallelize Karatsuba and other calculations? Here's an article I wrote about the inefficiencies of BigInteger and working out large numbers: http://www.javaspecialists.eu/archive/Issue201.html Heinz On 05/03/2013, Brian Burkhalter wrote: > Hi Alan, > > Thanks for the history: I was not myself aware of all that and it is good to > know. > > Brian > > On Mar 4, 2013, at 1:44 PM, Alan Eliasen wrote: > >> That's good to hear. By the way, in case you didn't know the history >> of this bugfix, the leading researcher in the world in Toom-Cook and >> other techniques for high-performance multiplication, Marco Bodrato, and >> his colleagues, reviewed my parts of the patch (Karatsuba and Toom-Cook >> multiplication, Karatsuba and Toom-Cook squaring) and said they were >> "very clean." I also ran hundreds of gigabytes of test cases through it >> (repeatedly,) taking many days, and cross-checked my multiplication >> routines against several other packages including GMP and previous >> versions of BigInteger. > > -- Dr Heinz M. Kabutz (PhD CompSci) Author of "The Java(tm) Specialists' Newsletter" Sun Java Champion IEEE Certified Software Development Professional http://www.javaspecialists.eu Tel: +30 69 75 595 262 Skype: kabutz From tbuktu at hotmail.com Mon Mar 4 22:53:37 2013 From: tbuktu at hotmail.com (Tim Buktu) Date: Mon, 4 Mar 2013 23:53:37 +0100 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) Message-ID: Good to hear! Tim On 03/04/2013 11:04 AM, Brian Burkhalter wrote: > Probably a good idea. > > But seriously this patch is #5 in my queue. We do intend to get to it > this spring. > > Brian From eliasen at mindspring.com Mon Mar 4 23:24:16 2013 From: eliasen at mindspring.com (Alan Eliasen) Date: Mon, 04 Mar 2013 16:24:16 -0700 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: References: <513515D0.9070600@mindspring.com> <028D2560-E5FA-41F3-941A-009D5CD6486E@oracle.com> Message-ID: <51352D20.7050503@mindspring.com> On 03/04/2013 03:37 PM, Dr Heinz M. Kabutz wrote: > Whilst we're at it, could we also add an option, perhaps via > environment variable, to parallelize Karatsuba and other calculations? > > Here's an article I wrote about the inefficiencies of BigInteger and > working out large numbers: > > http://www.javaspecialists.eu/archive/Issue201.html That's an interesting article, thanks. When I first made the patches for faster multiplication, I was asked to generate small, simple patches so that they would be reviewed more rapidly. I didn't make any attempt to use multiple threads, although these recursive divide-and-conquer algorithms would seem to be good candidates for such algorithms Brian, as you may also not know, I have further patches to drastically improve the toString behavior of BigInteger using Schoenhage-Strassen recursive decomposition. This makes toString orders of magnitude faster for large numbers and will likely improve the performance of some of the stuff you're doing in BigDecimal as well. I will polish those up and submit them when you've reviewed the multiplication and pow fixes. -- Alan Eliasen eliasen at mindspring.com http://futureboy.us/ From brian.burkhalter at oracle.com Tue Mar 5 00:09:18 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 4 Mar 2013 16:09:18 -0800 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: <51352D20.7050503@mindspring.com> References: <513515D0.9070600@mindspring.com> <028D2560-E5FA-41F3-941A-009D5CD6486E@oracle.com> <51352D20.7050503@mindspring.com> Message-ID: Heinz and Alan, Thanks for the additional information and suggestions. While not based on anything substantive about the various additional changes you suggest, my initial reaction is first to try to review and integrate the patches already in the queue and then deal with these other improvements afterwards, preferably using patches against the current repository tip. These other ideas should have issues filed for them as well. Thanks, Brian On Mar 4, 2013, at 3:24 PM, Alan Eliasen wrote: > On 03/04/2013 03:37 PM, Dr Heinz M. Kabutz wrote: >> Whilst we're at it, could we also add an option, perhaps via >> environment variable, to parallelize Karatsuba and other calculations? >> >> Here's an article I wrote about the inefficiencies of BigInteger and >> working out large numbers: >> >> http://www.javaspecialists.eu/archive/Issue201.html > > That's an interesting article, thanks. > > When I first made the patches for faster multiplication, I was asked > to generate small, simple patches so that they would be reviewed more > rapidly. I didn't make any attempt to use multiple threads, although > these recursive divide-and-conquer algorithms would seem to be good > candidates for such algorithms > > Brian, as you may also not know, I have further patches to > drastically improve the toString behavior of BigInteger using > Schoenhage-Strassen recursive decomposition. This makes toString orders > of magnitude faster for large numbers and will likely improve the > performance of some of the stuff you're doing in BigDecimal as well. I > will polish those up and submit them when you've reviewed the > multiplication and pow fixes. From mike.duigou at oracle.com Tue Mar 5 00:20:26 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 4 Mar 2013 16:20:26 -0800 Subject: RFR: 8006593: Performance and compatibility improvements to hash based Map implementations In-Reply-To: <51351CD1.2030804@gmail.com> References: <79A5A703-12DA-4C66-94F7-34534761D217@oracle.com> <51351CD1.2030804@gmail.com> Message-ID: <31FCDFD3-CC4C-4B0E-A7F5-9F69553B3F35@oracle.com> You are correct that there is a problem here but not because of the unsafe.putIntVolatile. The problem is that hashSeed = 0; is a compile time constant and field accesses are elided in the compiled methods. The idiom of setting a final field via unsafe.putIntVolatile is adapted from the deserialization code of ConcurrentHashMap. I've assumed that the memory model is correct. Objects being deserialized usually aren't visible to other threads (and the implementation of HashMap doesn't allow itself to be made visible to other threads during deserialization). I am less certain about the unsafe.putIntVolatile in initHashSeedAsNeeded and may just make hashSeed non-final. I will correct the patch so that hashSeed isn't a compile time constant. :-( Mike On Mar 4 2013, at 14:14 , Peter Levart wrote: > Hi mike, > > I doubt (haven't tried it really with your code) that hashSeed will be seen by code to be anything else but 0, since it is initialized to a constant value. For example, this code: > > public class ModifyingFinalTest { > static final Unsafe unsafe; > static final long valueOffset; > > static { > try { > Field f = Unsafe.class.getDeclaredField("theUnsafe"); > f.setAccessible(true); > unsafe = (Unsafe)f.get(null); > valueOffset = unsafe.objectFieldOffset(ModifyingFinalTest.class.getDeclaredField("value")); > } > catch (IllegalAccessException | NoSuchFieldException e) { > throw new Error(e); > } > } > > final int value = 0; > > void test() { > unsafe.putIntVolatile(this, valueOffset, 1); > printValue(); > unsafe.putIntVolatile(this, valueOffset, 2); > printValue(); > unsafe.putIntVolatile(this, valueOffset, 3); > printValue(); > } > > void printValue() { > System.out.println(value); > } > > public static void main(String[] args) { > new ModifyingFinalTest().test(); > } > } > > > Prints: > > 0 > 0 > 0 > > > It's a different thing, if the initialization is changed to: > > final int value = "".length(); > > But I don't know if each access in source is actually guaranteed to translate to a real read of field in this case either. Is Unsafe.putIntVolatile() making this happen somehow magically? > > Regards, Peter > > > On 03/04/2013 09:21 PM, Mike Duigou wrote: >> Hello all; >> >> The alternative hashing implementation introduced in 7u6 added an unfortunate bottleneck to the initialization of HashMap and Hashtable instances. This patch avoids the performance bottleneck of using a shared Random instance by using a ThreadLocalRandom instead. >> >> Along with this change are some additional performance improvements to further reduce the overhead of the alternative hashing feature and generally improve the performance of Hashtable or HashMap. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8006593/3/webrev/ >> >> Once review is completed here this patch will be proposed to JDK7u-dev for integration into the next 7u performance/feature release. >> >> Mike >> > From joe.darcy at oracle.com Tue Mar 5 03:43:26 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 05 Mar 2013 03:43:26 +0000 Subject: hg: jdk8/tl/jdk: 8009267: Restore isAnnotationPresent methods in public AnnotatedElement implementations Message-ID: <20130305034349.4068A4782F@hg.openjdk.java.net> Changeset: 83e847f59fd6 Author: darcy Date: 2013-03-04 19:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/83e847f59fd6 8009267: Restore isAnnotationPresent methods in public AnnotatedElement implementations Reviewed-by: jjg ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/reflect/AccessibleObject.java + test/java/lang/reflect/OldenCompilingWithDefaults.java From naoto.sato at oracle.com Tue Mar 5 04:48:47 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 05 Mar 2013 04:48:47 +0000 Subject: hg: jdk8/tl/jdk: 8004240: Return value from getAdapterPrefence() can be modified Message-ID: <20130305044903.5A26C47830@hg.openjdk.java.net> Changeset: 1a2e59d19d3e Author: naoto Date: 2013-03-04 20:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1a2e59d19d3e 8004240: Return value from getAdapterPrefence() can be modified Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java + test/java/util/Locale/Bug8004240.java From mike.duigou at oracle.com Tue Mar 5 06:08:38 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 4 Mar 2013 22:08:38 -0800 Subject: RFR: 8006593: Performance and compatibility improvements to hash based Map implementations In-Reply-To: <51351F60.30502@gmail.com> References: <79A5A703-12DA-4C66-94F7-34534761D217@oracle.com> <51351CD1.2030804@gmail.com> <51351F60.30502@gmail.com> Message-ID: <8CE8CB62-1F4F-430F-B770-DB78CA530531@oracle.com> After looking more closely at the single read reference to hashSeed I decided to simplify things and make hashSeed non-final in both Hashtable and HashMap. I've posted a refreshed webrev. http://cr.openjdk.java.net/~mduigou/JDK-8006593/4/webrev/ Mike On Mar 4 2013, at 14:25 , Peter Levart wrote: > > On 03/04/2013 11:14 PM, Peter Levart wrote: >> Hi mike, >> >> I doubt (haven't tried it really with your code) that hashSeed will be seen by code to be anything else but 0, since it is initialized to a constant value. For example, this code: >> >> public class ModifyingFinalTest { >> static final Unsafe unsafe; >> static final long valueOffset; >> >> static { >> try { >> Field f = Unsafe.class.getDeclaredField("theUnsafe"); >> f.setAccessible(true); >> unsafe = (Unsafe)f.get(null); >> valueOffset = unsafe.objectFieldOffset(ModifyingFinalTest.class.getDeclaredField("value")); >> } >> catch (IllegalAccessException | NoSuchFieldException e) { >> throw new Error(e); >> } >> } >> >> final int value = 0; >> >> void test() { >> unsafe.putIntVolatile(this, valueOffset, 1); >> printValue(); >> unsafe.putIntVolatile(this, valueOffset, 2); >> printValue(); >> unsafe.putIntVolatile(this, valueOffset, 3); >> printValue(); >> } >> >> void printValue() { >> System.out.println(value); >> } >> >> public static void main(String[] args) { >> new ModifyingFinalTest().test(); >> } >> } >> >> >> Prints: >> >> 0 >> 0 >> 0 >> >> >> It's a different thing, if the initialization is changed to: >> >> final int value = "".length(); >> >> But I don't know if each access in source is actually guaranteed to translate to a real read of field in this case either. Is Unsafe.putIntVolatile() making this happen somehow magically? > > Well, that's not what I wanted to ask. I wanted to ask if the first access in source that happens after Unsafe.putIntVolatile() in same thread is guaranteed to read the field and not re-use a cached value ready in some register for example. Is Unsafe.putIntVolatile() making this happen somehow magically? > >> >> Regards, Peter >> >> >> On 03/04/2013 09:21 PM, Mike Duigou wrote: >>> Hello all; >>> >>> The alternative hashing implementation introduced in 7u6 added an unfortunate bottleneck to the initialization of HashMap and Hashtable instances. This patch avoids the performance bottleneck of using a shared Random instance by using a ThreadLocalRandom instead. >>> >>> Along with this change are some additional performance improvements to further reduce the overhead of the alternative hashing feature and generally improve the performance of Hashtable or HashMap. >>> >>> c >>> >>> Once review is completed here this patch will be proposed to JDK7u-dev for integration into the next 7u performance/feature release. >>> >>> Mike >>> >> > From peter.levart at gmail.com Tue Mar 5 07:37:15 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 05 Mar 2013 08:37:15 +0100 Subject: RFR: 8006593: Performance and compatibility improvements to hash based Map implementations In-Reply-To: <31FCDFD3-CC4C-4B0E-A7F5-9F69553B3F35@oracle.com> References: <79A5A703-12DA-4C66-94F7-34534761D217@oracle.com> <51351CD1.2030804@gmail.com> <31FCDFD3-CC4C-4B0E-A7F5-9F69553B3F35@oracle.com> Message-ID: <5135A0AB.20908@gmail.com> Yes, there are two thing here, as I noted. The 1st is compile-time constant replacement, the second is modifying the final field, which might be ok in the constructor of the object or at the deserialization time (as in readObject()), but you also had it assigned during re-hashing - at that time, I think, there could be code transformations that used cached value instead of re-reading the field... It's better this way with normal field. I doubt there is any performance penalty... Regards, Peter On 03/05/2013 01:20 AM, Mike Duigou wrote: > You are correct that there is a problem here but not because of the > unsafe.putIntVolatile. The problem is that hashSeed = 0; is a compile > time constant and field accesses are elided in the compiled methods. > > The idiom of setting a final field via unsafe.putIntVolatile is > adapted from the deserialization code of ConcurrentHashMap. I've > assumed that the memory model is correct. Objects being deserialized > usually aren't visible to other threads (and the implementation of > HashMap doesn't allow itself to be made visible to other threads > during deserialization). I am less certain about the > unsafe.putIntVolatile in initHashSeedAsNeeded and may just make > hashSeed non-final. > > I will correct the patch so that hashSeed isn't a compile time constant. > > :-( > > Mike > > On Mar 4 2013, at 14:14 , Peter Levart wrote: > >> Hi mike, >> >> I doubt (haven't tried it really with your code) that hashSeed will >> be seen by code to be anything else but 0, since it is initialized to >> a constant value. For example, this code: >> >> public class ModifyingFinalTest { >> static final Unsafe unsafe; >> static final long valueOffset; >> >> static { >> try { >> Field f = Unsafe.class.getDeclaredField("theUnsafe"); >> f.setAccessible(true); >> unsafe = (Unsafe)f.get(null); >> valueOffset = >> unsafe.objectFieldOffset(ModifyingFinalTest.class.getDeclaredField("value")); >> } >> catch (IllegalAccessException | NoSuchFieldException e) { >> throw new Error(e); >> } >> } >> >> final int value = 0; >> >> void test() { >> unsafe.putIntVolatile(this, valueOffset, 1); >> printValue(); >> unsafe.putIntVolatile(this, valueOffset, 2); >> printValue(); >> unsafe.putIntVolatile(this, valueOffset, 3); >> printValue(); >> } >> >> void printValue() { >> System.out.println(value); >> } >> >> public static void main(String[] args) { >> new ModifyingFinalTest().test(); >> } >> } >> >> >> Prints: >> >> 0 >> 0 >> 0 >> >> >> It's a different thing, if the initialization is changed to: >> >> final int value = "".length(); >> >> But I don't know if each access in source is actually guaranteed to >> translate to a real read of field in this case either. Is >> Unsafe.putIntVolatile() making this happen somehow magically? >> >> Regards, Peter >> >> >> On 03/04/2013 09:21 PM, Mike Duigou wrote: >>> Hello all; >>> >>> The alternative hashing implementation introduced in 7u6 added an unfortunate bottleneck to the initialization of HashMap and Hashtable instances. This patch avoids the performance bottleneck of using a shared Random instance by using a ThreadLocalRandom instead. >>> >>> Along with this change are some additional performance improvements to further reduce the overhead of the alternative hashing feature and generally improve the performance of Hashtable or HashMap. >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-8006593/3/webrev/ >>> >>> Once review is completed here this patch will be proposed to JDK7u-dev for integration into the next 7u performance/feature release. >>> >>> Mike >>> >> > From eliasen at mindspring.com Tue Mar 5 07:40:53 2013 From: eliasen at mindspring.com (Alan Eliasen) Date: Tue, 05 Mar 2013 00:40:53 -0700 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: References: <513515D0.9070600@mindspring.com> <028D2560-E5FA-41F3-941A-009D5CD6486E@oracle.com> <51352D20.7050503@mindspring.com> Message-ID: <5135A185.2000200@mindspring.com> Alan Eliasen wrote: >> Brian, as you may also not know, I have further patches to >> drastically improve the toString behavior of BigInteger using >> Schoenhage-Strassen recursive decomposition. This makes toString >> orders of magnitude faster for large numbers and will likely >> improve the performance of some of the stuff you're doing in >> BigDecimal as well. I will polish those up and submit them when >> you've reviewed the multiplication and pow fixes. On 03/04/2013 05:09 PM, Brian Burkhalter wrote: > Thanks for the additional information and suggestions. While not > based on anything substantive about the various additional changes > you suggest, my initial reaction is first to try to review and > integrate the patches already in the queue and then deal with these > other improvements afterwards, preferably using patches against the > current repository tip. These other ideas should have issues filed > for them as well. There are issues filed about the inefficient algorithms used in toString and pow: 4641897: BigInteger.toString() algorithm slow for large numbers http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4641897 4646474: BigInteger.pow() algorithm slow in 1.4.0 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4646474 Unfortunately, because of the destruction of all the user-submitted fixes in bug reports (when are those coming back?) you can't see the further comments about these. You have my much faster pow() routines in Tim Buktu's combined patch for BigInteger, I believe, and you should be able to close the latter bug if you merge that entire patch. My way faster toString patch is not included in that combined patch. -- Alan Eliasen eliasen at mindspring.com http://futureboy.us/ From peter.levart at gmail.com Tue Mar 5 08:43:37 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 05 Mar 2013 09:43:37 +0100 Subject: RFR: 8006593: Performance and compatibility improvements to hash based Map implementations In-Reply-To: <8CE8CB62-1F4F-430F-B770-DB78CA530531@oracle.com> References: <79A5A703-12DA-4C66-94F7-34534761D217@oracle.com> <51351CD1.2030804@gmail.com> <51351F60.30502@gmail.com> <8CE8CB62-1F4F-430F-B770-DB78CA530531@oracle.com> Message-ID: <5135B039.7000604@gmail.com> Hi Mike, You could also get rid of boolean useAltHashing field in both HashMap and Hashtable. It saves 8 bytes in both HM and HT objects in 32bit addressing modes (64bit addressing modes are not affected due to different alignment). Like the following (a patch against your webrev): Index: jdk/src/share/classes/java/util/Hashtable.java =================================================================== --- jdk/src/share/classes/java/util/Hashtable.java (date 1362469665000) +++ jdk/src/share/classes/java/util/Hashtable.java (revision ) @@ -213,12 +213,6 @@ } /** - * If {@code true} then perform alternative hashing of String keys to reduce - * the incidence of collisions due to weak hash code calculation. - */ - transient boolean useAltHashing = false; - - /** * A randomizing value associated with this instance that is applied to * hash code of keys to make hash collisions harder to find. */ @@ -228,8 +222,8 @@ * Initialize the hashing mask value. */ final boolean initHashSeedAsNeeded(int capacity) { - boolean currentAltHashing = useAltHashing; - useAltHashing = sun.misc.VM.isBooted() && + boolean currentAltHashing = hashSeed != 0; + boolean useAltHashing = sun.misc.VM.isBooted() && (capacity >= Holder.ALTERNATIVE_HASHING_THRESHOLD); boolean switching = currentAltHashing ^ useAltHashing; if (switching) { Index: jdk/src/share/classes/java/util/HashMap.java =================================================================== --- jdk/src/share/classes/java/util/HashMap.java (date 1362472425000) +++ jdk/src/share/classes/java/util/HashMap.java (revision ) @@ -224,17 +224,11 @@ } /** - * If {@code true} then perform alternative hashing of String keys to reduce - * the incidence of collisions due to weak hash code calculation. - */ - transient boolean useAltHashing = false; - - /** * A randomizing value associated with this instance that is applied to - * hash code of keys to make hash collisions harder to find. Initialized via - * sun.misc.Unsafe when needed. + * hash code of keys to make hash collisions harder to find. + * Also used (when != 0) to indicate use of alternative String hashing. */ - transient int hashSeed = 0; + transient int hashSeed; /** * Constructs an empty HashMap with the specified initial @@ -319,8 +313,8 @@ * really need it. */ final boolean initHashSeedAsNeeded(int capacity) { - boolean currentAltHashing = useAltHashing; - useAltHashing = sun.misc.VM.isBooted() && + boolean currentAltHashing = hashSeed != 0; + boolean useAltHashing = sun.misc.VM.isBooted() && (capacity >= Holder.ALTERNATIVE_HASHING_THRESHOLD); boolean switching = currentAltHashing ^ useAltHashing; if (switching) { @@ -339,12 +333,9 @@ * in lower bits. Note: Null keys always map to hash 0, thus index 0. */ final int hash(Object k) { - int h = 0; - if (useAltHashing) { - if (k instanceof String) { + int h = hashSeed; + if (h != 0 && k instanceof String) { - return sun.misc.Hashing.stringHash32((String) k); + return sun.misc.Hashing.stringHash32((String) k); - } - h = hashSeed; } h ^= k.hashCode(); Regards, Peter On 03/05/2013 07:08 AM, Mike Duigou wrote: > After looking more closely at the single read reference to hashSeed I > decided to simplify things and make hashSeed non-final in both > Hashtable and HashMap. > > I've posted a refreshed webrev. > > http://cr.openjdk.java.net/~mduigou/JDK-8006593/4/webrev/ > > > Mike > > On Mar 4 2013, at 14:25 , Peter Levart wrote: > >> >> On 03/04/2013 11:14 PM, Peter Levart wrote: >>> Hi mike, >>> >>> I doubt (haven't tried it really with your code) that hashSeed will >>> be seen by code to be anything else but 0, since it is initialized >>> to a constant value. For example, this code: >>> >>> public class ModifyingFinalTest { >>> static final Unsafe unsafe; >>> static final long valueOffset; >>> >>> static { >>> try { >>> Field f = Unsafe.class.getDeclaredField("theUnsafe"); >>> f.setAccessible(true); >>> unsafe = (Unsafe)f.get(null); >>> valueOffset = >>> unsafe.objectFieldOffset(ModifyingFinalTest.class.getDeclaredField("value")); >>> } >>> catch (IllegalAccessException | NoSuchFieldException e) { >>> throw new Error(e); >>> } >>> } >>> >>> final int value = 0; >>> >>> void test() { >>> unsafe.putIntVolatile(this, valueOffset, 1); >>> printValue(); >>> unsafe.putIntVolatile(this, valueOffset, 2); >>> printValue(); >>> unsafe.putIntVolatile(this, valueOffset, 3); >>> printValue(); >>> } >>> >>> void printValue() { >>> System.out.println(value); >>> } >>> >>> public static void main(String[] args) { >>> new ModifyingFinalTest().test(); >>> } >>> } >>> >>> >>> Prints: >>> >>> 0 >>> 0 >>> 0 >>> >>> >>> It's a different thing, if the initialization is changed to: >>> >>> final int value = "".length(); >>> >>> But I don't know if each access in source is actually guaranteed to >>> translate to a real read of field in this case either. Is >>> Unsafe.putIntVolatile() making this happen somehow magically? >> >> Well, that's not what I wanted to ask. I wanted to ask if the first >> access in source that happens after Unsafe.putIntVolatile() in same >> thread is guaranteed to read the field and not re-use a cached value >> ready in some register for example. Is Unsafe.putIntVolatile() making >> this happen somehow magically? >> >>> >>> Regards, Peter >>> >>> >>> On 03/04/2013 09:21 PM, Mike Duigou wrote: >>>> Hello all; >>>> >>>> The alternative hashing implementation introduced in 7u6 added an unfortunate bottleneck to the initialization of HashMap and Hashtable instances. This patch avoids the performance bottleneck of using a shared Random instance by using a ThreadLocalRandom instead. >>>> >>>> Along with this change are some additional performance improvements to further reduce the overhead of the alternative hashing feature and generally improve the performance of Hashtable or HashMap. >>>> >>>> c >>>> >>>> Once review is completed here this patch will be proposed to JDK7u-dev for integration into the next 7u performance/feature release. >>>> >>>> Mike >>>> >>> >> > From chris.hegarty at oracle.com Tue Mar 5 10:12:52 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 05 Mar 2013 10:12:52 +0000 Subject: hg: jdk8/tl/jdk: 8009259: TEST_BUG: sun/misc/Cleaner/exitOnThrow.sh failing intermittently Message-ID: <20130305101319.BD3DC47839@hg.openjdk.java.net> Changeset: 62639ca66ab9 Author: ewang Date: 2013-03-05 10:10 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/62639ca66ab9 8009259: TEST_BUG: sun/misc/Cleaner/exitOnThrow.sh failing intermittently Reviewed-by: chegar, alanb ! test/sun/misc/Cleaner/ExitOnThrow.java ! test/sun/misc/Cleaner/exitOnThrow.sh From Alan.Bateman at oracle.com Tue Mar 5 14:19:38 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 05 Mar 2013 14:19:38 +0000 Subject: RFR(S): 8009397 test/com/sun/jdi/PrivateTransportTest.sh: ERROR: transport library missing onLoad entry: private_dt_socket In-Reply-To: <2A1F6D24-22FC-4CB4-84FD-05E8ECDDC9BF@oracle.com> References: <2A1F6D24-22FC-4CB4-84FD-05E8ECDDC9BF@oracle.com> Message-ID: <5135FEFA.5070002@oracle.com> On 04/03/2013 18:56, Staffan Larsen wrote: > I accidentally stepped on this bug the other day. There is a problem in linker_md.c : dll_build_name() where an internal pointer can be moved to point outside the string. The code looks like: > > : > > bug: http://bugs.sun.com/view_bug.do?bug_id=8009397 > webrev: http://cr.openjdk.java.net/~sla/8009397/webrev.00/ > This is a good find and the changes looks good to me. -Alan. From chris.hegarty at oracle.com Tue Mar 5 14:31:19 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 05 Mar 2013 14:31:19 +0000 Subject: hg: jdk8/tl/jdk: 8008804: file descriptor leak in src/windows/native/java/net/DualStackPlainSocketImpl.c Message-ID: <20130305143143.6BA2947841@hg.openjdk.java.net> Changeset: b5bef1f71de6 Author: jzavgren Date: 2013-03-05 14:30 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b5bef1f71de6 8008804: file descriptor leak in src/windows/native/java/net/DualStackPlainSocketImpl.c Reviewed-by: alanb, chegar, dsamersoff ! src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c From Thomas.Salter at unisys.com Tue Mar 5 14:53:55 2013 From: Thomas.Salter at unisys.com (Salter, Thomas A) Date: Tue, 5 Mar 2013 08:53:55 -0600 Subject: RFR: 8006593: Performance and compatibility improvements to hash based Map implementations In-Reply-To: References: Message-ID: <63D5DCACD1E9E34C89C8203C64F521C301366C43126F@USEA-EXCH7.na.uis.unisys.com> Will this change do anything to fix: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8002283? -------------------- Date: Mon, 4 Mar 2013 12:21:08 -0800 From: Mike Duigou Subject: RFR: 8006593: Performance and compatibility improvements to hash based Map implementations To: "core-libs-dev at openjdk.java.net Libs" Message-ID: <79A5A703-12DA-4C66-94F7-34534761D217 at oracle.com> Content-Type: text/plain; charset=us-ascii Hello all; The alternative hashing implementation introduced in 7u6 added an unfortunate bottleneck to the initialization of HashMap and Hashtable instances. This patch avoids the performance bottleneck of using a shared Random instance by using a ThreadLocalRandom instead. Along with this change are some additional performance improvements to further reduce the overhead of the alternative hashing feature and generally improve the performance of Hashtable or HashMap. http://cr.openjdk.java.net/~mduigou/JDK-8006593/3/webrev/ Once review is completed here this patch will be proposed to JDK7u-dev for integration into the next 7u performance/feature release. Mike From chris.hegarty at oracle.com Tue Mar 5 15:06:02 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 05 Mar 2013 15:06:02 +0000 Subject: hg: jdk8/tl/jdk: 4880778: URL final class has protected methods Message-ID: <20130305150624.D2EB747845@hg.openjdk.java.net> Changeset: be79440b8026 Author: jzavgren Date: 2013-03-05 09:50 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/be79440b8026 4880778: URL final class has protected methods Summary: The two set() methods have been defined to be package private. Reviewed-by: alanb, chegar, khazra ! src/share/classes/java/net/URL.java ! src/share/classes/java/net/URLStreamHandler.java From Alan.Bateman at oracle.com Tue Mar 5 15:12:31 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 05 Mar 2013 15:12:31 +0000 Subject: RFR : JDK-8001642 : Add Optional, OptionalDouble, OptionalInt, OptionalLong In-Reply-To: References: Message-ID: <51360B5F.8080904@oracle.com> On 04/03/2013 20:29, Mike Duigou wrote: > Hello All; > > This patch introduces Optional container objects to be used by the lambda streams libraries for returning results. > > The reference Optional type, as defined, intentionally does not allow null values. null may be used with the Optional.orElse() method. > > All of the Optional types define hashCode() and equals implementations. Use of Optional types in collections should be generally discouraged but having useful equals() and hashCode() is ever so convenient. > > http://cr.openjdk.java.net/~mduigou/JDK-8001642/0/webrev/ > > Mike Just a couple of small things. Will the docs build complain about the unknown taglets? (@apiNote, @implNote ...) Optional.of(T) has two @param tags. In orElseGet currently reads "Supplier who's result is returned ..." but I assume you want the possessive, hence "whose". Are you planning to include a test? I realize this will get a good workout once the streams work come in. -Alan. From pbenedict at apache.org Tue Mar 5 15:15:42 2013 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 5 Mar 2013 09:15:42 -0600 Subject: Proposal: Put @Native and @GenerateNativeHeader in same package Message-ID: Compare the two javadocs: @java.lang.annotation.Native: "Indicates that a field defining a constant value may be referenced from native code. The annotation may be used as a hint by tools that generate native header files to determine whether a header file is required, and if so, what declarations it should contain." @javax.tools.annotation.GenerateNativeHeader: "An annotation used to indicate that a native header file should be generated for this class. Normally, the presence of native methods is a sufficient indication of the need for a native header file. However, in some cases, a class may contain constants of interest to native code, without containing any native methods." Both are hints for tools. Both discuss header files. So why divide them up? I think they should be in one package together. Personally, I think both are better suited to the javax.tools.annotation package. I just wanted to point out the division doesn't make all that sense. Paul From Alan.Bateman at oracle.com Tue Mar 5 15:28:37 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 05 Mar 2013 15:28:37 +0000 Subject: Proposal: Put @Native and @GenerateNativeHeader in same package In-Reply-To: References: Message-ID: <51360F25.5030409@oracle.com> On 05/03/2013 15:15, Paul Benedict wrote: > : > > Both are hints for tools. Both discuss header files. So why divide them up? > I think they should be in one package together. Personally, I think both > are better suited to the javax.tools.annotation package. I just wanted to > point out the division doesn't make all that sense. > The reason that @Native was moved from javax.tools to j.l.annotation is because it was problematic for future modularization - ie: it would result in a compilation time dependency on the tools module and would also prevent its use in the base/core module. -Alan. From pbenedict at apache.org Tue Mar 5 15:38:22 2013 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 5 Mar 2013 09:38:22 -0600 Subject: Proposal: Put @Native and @GenerateNativeHeader in same package In-Reply-To: <51360F25.5030409@oracle.com> References: <51360F25.5030409@oracle.com> Message-ID: Okay, but then I think @GenerateNativeHeader should move into lang as well. Both support tools, both are clear hints (nothing more), and both are tangentially related to native code. @GenerateNativeHeader has no strict dependency on anything else in tools package, btw. On Tue, Mar 5, 2013 at 9:28 AM, Alan Bateman wrote: > On 05/03/2013 15:15, Paul Benedict wrote: > >> : >> >> >> Both are hints for tools. Both discuss header files. So why divide them >> up? >> I think they should be in one package together. Personally, I think both >> are better suited to the javax.tools.annotation package. I just wanted to >> point out the division doesn't make all that sense. >> >> The reason that @Native was moved from javax.tools to j.l.annotation is > because it was problematic for future modularization - ie: it would result > in a compilation time dependency on the tools module and would also prevent > its use in the base/core module. > > -Alan. > From Alan.Bateman at oracle.com Tue Mar 5 15:49:04 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 05 Mar 2013 15:49:04 +0000 Subject: Proposal: Put @Native and @GenerateNativeHeader in same package In-Reply-To: References: <51360F25.5030409@oracle.com> Message-ID: <513613F0.4070302@oracle.com> On 05/03/2013 15:38, Paul Benedict wrote: > Okay, but then I think @GenerateNativeHeader should move into lang as > well. Both support tools, both are clear hints (nothing more), and > both are tangentially related to native code. @GenerateNativeHeader > has no strict dependency on anything else in tools package, btw. Sorry, I should have been cleaner. The move/rename is "in progress" and requires a number of steps to complete. I think Jon is waiting for the libraries to be change to use @Native before deleting @GenerateNativeHeader. -Alan. From maurizio.cimadamore at oracle.com Tue Mar 5 15:55:55 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 05 Mar 2013 15:55:55 +0000 Subject: hg: jdk8/tl/langtools: 4 new changesets Message-ID: <20130305155606.5F88C47847@hg.openjdk.java.net> Changeset: 69cd2bfd4a31 Author: mcimadamore Date: 2013-03-05 14:04 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/69cd2bfd4a31 8004962: Code generation crash with lambda and local classes Summary: Translation info should be propagated from LambdaToMethod to Lower Reviewed-by: jjg, rfield ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/lambda/LambdaCapture07.java Changeset: d2a98dde7ecc Author: mcimadamore Date: 2013-03-05 14:12 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d2a98dde7ecc 8009227: Certain diagnostics should not be deferred Summary: Add new diagnostic flag to mark non deferrable diagnostics Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/Log.java + test/tools/javac/lambda/abort/CompletionFailure.java Changeset: a708c5f1da06 Author: mcimadamore Date: 2013-03-05 14:16 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a708c5f1da06 8009154: Missing cast in method reference bridge leads to NoSuchMethodError Summary: Missing cast in generated method reference bridge Reviewed-by: rfield, jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/MethodReference65.java Changeset: 12202e6ab78a Author: mcimadamore Date: 2013-03-05 14:19 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/12202e6ab78a 8009129: Illegal access error when calling method reference Summary: Javac generates method handle referencing non public type Reviewed-by: jjg, rfield ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java + test/tools/javac/diags/examples/NotDefPublicCantAccessFragment/NotDefPublicCantAccessFragment.java + test/tools/javac/diags/examples/NotDefPublicCantAccessFragment/p/C.java + test/tools/javac/lambda/inaccessibleMref01/InaccessibleMref01.java + test/tools/javac/lambda/inaccessibleMref01/InaccessibleMref01.out + test/tools/javac/lambda/inaccessibleMref01/p1/C.java + test/tools/javac/lambda/inaccessibleMref02/InaccessibleMref02.java + test/tools/javac/lambda/inaccessibleMref02/p1/C.java From pbenedict at apache.org Tue Mar 5 16:06:39 2013 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 5 Mar 2013 10:06:39 -0600 Subject: Proposal: Put @Native and @GenerateNativeHeader in same package In-Reply-To: <513613F0.4070302@oracle.com> References: <51360F25.5030409@oracle.com> <513613F0.4070302@oracle.com> Message-ID: Alan, Ah, that makes lots more sense! Glad to know the latter is getting deleted. I don't know the particulars of Jon's plans, but if you want to achieve the same functionality of both annotations, I suggest allowing @Native to @Target(PACKAGE). Paul On Tue, Mar 5, 2013 at 9:49 AM, Alan Bateman wrote: > Sorry, I should have been cleaner. The move/rename is "in progress" and > requires a number of steps to complete. I think Jon is waiting for the > libraries to be change to use @Native before deleting @GenerateNativeHeader. > From jonathan.gibbons at oracle.com Tue Mar 5 16:14:25 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 05 Mar 2013 08:14:25 -0800 Subject: Proposal: Put @Native and @GenerateNativeHeader in same package In-Reply-To: References: <51360F25.5030409@oracle.com> <513613F0.4070302@oracle.com> Message-ID: <513619E1.9010007@oracle.com> Paul, The goal is to annotate the necessary constants with @Native. -- Jon On 03/05/2013 08:06 AM, Paul Benedict wrote: > Alan, > > Ah, that makes lots more sense! Glad to know the latter is getting > deleted. I don't know the particulars of Jon's plans, but if you want > to achieve the same functionality of both annotations, I suggest > allowing @Native to @Target(PACKAGE). > > Paul > > On Tue, Mar 5, 2013 at 9:49 AM, Alan Bateman wrote: > > Sorry, I should have been cleaner. The move/rename is "in > progress" and requires a number of steps to complete. I think Jon > is waiting for the libraries to be change to use @Native before > deleting @GenerateNativeHeader. > > From Alan.Bateman at oracle.com Tue Mar 5 16:18:10 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 05 Mar 2013 16:18:10 +0000 Subject: Proposal: Put @Native and @GenerateNativeHeader in same package In-Reply-To: References: <51360F25.5030409@oracle.com> <513613F0.4070302@oracle.com> Message-ID: <51361AC2.8060108@oracle.com> On 05/03/2013 16:06, Paul Benedict wrote: > Alan, > > Ah, that makes lots more sense! Glad to know the latter is getting > deleted. I don't know the particulars of Jon's plans, but if you want > to achieve the same functionality of both annotations, I suggest > allowing @Native to @Target(PACKAGE). The annotation is for indicating that a constant will be referenced from native code so it needs to go onto the specific fields. -Alan. From brian.burkhalter at oracle.com Tue Mar 5 16:18:44 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 5 Mar 2013 08:18:44 -0800 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: <5135A185.2000200@mindspring.com> References: <513515D0.9070600@mindspring.com> <028D2560-E5FA-41F3-941A-009D5CD6486E@oracle.com> <51352D20.7050503@mindspring.com> <5135A185.2000200@mindspring.com> Message-ID: Hi Alan, On Mar 4, 2013, at 11:40 PM, Alan Eliasen wrote: > There are issues filed about the inefficient algorithms used in > toString and pow: > > 4641897: BigInteger.toString() algorithm slow for large numbers > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4641897 > > 4646474: BigInteger.pow() algorithm slow in 1.4.0 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4646474 I am aware of these and as of now they are actually on my list to look into after the major Karatsuba patch. > Unfortunately, because of the destruction of all the user-submitted > fixes in bug reports (when are those coming back?) you can't see the > further comments about these. There are a couple of comments from you in these two reports. Unfortunately there are not any comprehensive patches in the reports. As to things gone missing, I am not entirely aware of the transition trajectory from the old system, but I would imagine some things will become visible again once the newer bug system is made public. > You have my much faster pow() routines in > Tim Buktu's combined patch for BigInteger, I believe, and you should be > able to close the latter bug if you merge that entire patch. OK - good. > My way > faster toString patch is not included in that combined patch. For this then an issue should be filed. If the patch cannot be attached to the issue, it could be posted to this mailing list once the issue number is known. Thanks, Brian From aleksey.shipilev at oracle.com Tue Mar 5 16:34:03 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 05 Mar 2013 20:34:03 +0400 Subject: RFR: 8006593: Performance and compatibility improvements to hash based Map implementations In-Reply-To: <8CE8CB62-1F4F-430F-B770-DB78CA530531@oracle.com> References: <79A5A703-12DA-4C66-94F7-34534761D217@oracle.com> <51351CD1.2030804@gmail.com> <51351F60.30502@gmail.com> <8CE8CB62-1F4F-430F-B770-DB78CA530531@oracle.com> Message-ID: <51361E7B.2020704@oracle.com> On 03/05/2013 10:08 AM, Mike Duigou wrote: > http://cr.openjdk.java.net/~mduigou/JDK-8006593/4/webrev/ Looks good. (Not a reviewer by OpenJDK Census) Peter has a nice suggestion about useAltHashing. -Aleksey. From jim.gish at oracle.com Tue Mar 5 17:16:41 2013 From: jim.gish at oracle.com (Jim Gish) Date: Tue, 05 Mar 2013 12:16:41 -0500 Subject: RFR: 8002070 Remove the stack search for a resource bundle for Logger to use In-Reply-To: <51313053.2080605@oracle.com> References: <51311CC4.5000106@oracle.com> <51313053.2080605@oracle.com> Message-ID: <51362879.5010004@oracle.com> On 03/01/2013 05:48 PM, Mandy Chung wrote: > On 3/1/2013 1:25 PM, Jim Gish wrote: >> Please review >> http://cr.openjdk.java.net/~jgish/Bug8002070-RemoveResourceBundleStackSearch/ >> >> This removes the stack search from Logger.findResourceBundle() >> > > It's good to see this stack walk search of resource bundle going away. > > In Logger.java, the existing implementation returns the previous > cached resource bundle if it fails to find one matching the current > locale but the name matches: > > 1608 if (name.equals(catalogName)) { > 1609 // Return the previous cached value for that name. > 1610 // This may be null. > 1611 return catalog; > 1612 } > > > Your fix removes these lines which I think is fine. The > Logger.getResourceBundle method specifies to return the resource > bundle for this logger for the current default locale. I think it'd > be rare to change the default locale during the execution of an > application. The old behavior upon reaching this point in the code was as follows: To get here, the sought after bundle was not found and (from the checks on line 1559,1560), either (1) the previously cached catalog was null, meaning nothing was yet cached and so null was returned, or (2) the current locale had changed and no bundle for that locale was found, in which case the cached bundle (for the old/wrong locale) was returned, or (3) the name was the same but the location of the objects used to compare the cached name with that passed in was different, so the previously cached bundle was returned (this is frankly an odd case, because it also means that re-searching for a previously found bundle is now failing, which only seems possible if the bundle is/was (a) not available via the system classloader, (b) the context classloader, or (c), the classloaders up the call chain. The new behavior /does /still allow for a change in the default locale. For example, if you first call findResourceBundleName("foo") and the default locale is US, it will search for the foo_US bundle and set catalogLocale=US, and catalogName=foo and return the foo_US bundle. If you then search for "foo" and have changed the default locale to DE (if that is indeed a valid locale), it will then search for foo_DE and if found set catalogLocale=DE and cache and return the foo_DE bundle. The /only /change in behavior that I see here, is that if you change the locale and the bundle is not found, null will be returned instead of the previously cached bundle (if one exists), for a /different/ locale. So, the old behavior in effect had a notion of a default catalog, but only if you happened to find a bundle on a previous lookup and cache it. However, you wouldn't be guaranteed of acquiring this same bundle on a subsequent search if a search for a different name had intervened. Thus, the new behavior is that if you search for a name/locale and it's not found, you will get null (every time). This seems better to me because it's consistent, explainable and simple. I'd appreciate you verifying this. Thanks, Jim > > I suggest to document this behavioral change as well in the bug report > and CCC. > > Thanks > Mandy -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From mike.duigou at oracle.com Tue Mar 5 17:24:40 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 5 Mar 2013 09:24:40 -0800 Subject: RFR: 8006593: Performance and compatibility improvements to hash based Map implementations In-Reply-To: <63D5DCACD1E9E34C89C8203C64F521C301366C43126F@USEA-EXCH7.na.uis.unisys.com> References: <63D5DCACD1E9E34C89C8203C64F521C301366C43126F@USEA-EXCH7.na.uis.unisys.com> Message-ID: Unfortunately, this change doesn't fix 8006593. We do have a fix planned for 8006593 in Java 8 but there's a difficulty in the current implementation that means we can't detect if the SecurityManager is initialized. The VM.isBooted() check is insufficient. Mike On Mar 5 2013, at 06:53 , Salter, Thomas A wrote: > Will this change do anything to fix: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8002283? > > -------------------- > Date: Mon, 4 Mar 2013 12:21:08 -0800 > From: Mike Duigou > Subject: RFR: 8006593: Performance and compatibility improvements to > hash based Map implementations > To: "core-libs-dev at openjdk.java.net Libs" > > Message-ID: <79A5A703-12DA-4C66-94F7-34534761D217 at oracle.com> > Content-Type: text/plain; charset=us-ascii > > Hello all; > > The alternative hashing implementation introduced in 7u6 added an unfortunate bottleneck to the initialization of HashMap and Hashtable instances. This patch avoids the performance bottleneck of using a shared Random instance by using a ThreadLocalRandom instead. > > Along with this change are some additional performance improvements to further reduce the overhead of the alternative hashing feature and generally improve the performance of Hashtable or HashMap. > > http://cr.openjdk.java.net/~mduigou/JDK-8006593/3/webrev/ > > Once review is completed here this patch will be proposed to JDK7u-dev for integration into the next 7u performance/feature release. > > Mike > From staffan.larsen at oracle.com Tue Mar 5 18:19:48 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 5 Mar 2013 19:19:48 +0100 Subject: RFR(S): 8009397 test/com/sun/jdi/PrivateTransportTest.sh: ERROR: transport library missing onLoad entry: private_dt_socket In-Reply-To: <5135FEFA.5070002@oracle.com> References: <2A1F6D24-22FC-4CB4-84FD-05E8ECDDC9BF@oracle.com> <5135FEFA.5070002@oracle.com> Message-ID: <6C61000D-683C-4ECC-A5DA-34703C66C9E1@oracle.com> Thanks Alan! On 5 mar 2013, at 15:19, Alan Bateman wrote: > On 04/03/2013 18:56, Staffan Larsen wrote: >> I accidentally stepped on this bug the other day. There is a problem in linker_md.c : dll_build_name() where an internal pointer can be moved to point outside the string. The code looks like: >> >> : >> >> bug: http://bugs.sun.com/view_bug.do?bug_id=8009397 >> webrev: http://cr.openjdk.java.net/~sla/8009397/webrev.00/ >> > This is a good find and the changes looks good to me. > > -Alan. From dan.xu at oracle.com Tue Mar 5 18:39:09 2013 From: dan.xu at oracle.com (Dan Xu) Date: Tue, 05 Mar 2013 10:39:09 -0800 Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code In-Reply-To: <510C32D2.2080508@oracle.com> References: <50FE3EE5.20600@oracle.com> <5100065A.9080801@oracle.com> <51029C56.9020302@oracle.com> <5106CB48.3010102@oracle.com> <5107B89A.3050400@oracle.com> <510ACEFC.2060607@oracle.com> <510B900B.1030406@oracle.com> <510C008A.2000107@oracle.com> <510C32D2.2080508@oracle.com> Message-ID: <51363BCD.7070700@oracle.com> Hi All, Thanks for your good suggestions. I have updated this fix and put the new webrev at http://cr.openjdk.java.net/~dxu/8001334/webrev.01/. Please help review it. Thanks! -Dan On 02/01/2013 01:25 PM, Alan Bateman wrote: > On 01/02/2013 18:12, Martin Buchholz wrote: >> : >> >> My comments are all very high level. >> >> The history of generic C-level infrastructure in the JDK is >> unsuccessful. The JVM_ functions were apparently a failure, but who >> is willing to own the problem of a suitable replacement? Leaving the >> problem up to individual component teams is a recipe for each >> component having different interesting bugs using the same >> functionality. >> >> The obvious examples are: all internal file operations in the JDK >> should be using LARGEFILE variants on 32-bit platforms. And all file >> descriptor creations should be using O_CLOEXEC by default (much less >> important). Does anyone own this problem? >> > The JVM/HPI was useful and important (particularly to I/O and > networking areas) when we had different threading models. We've > required native threading support for a long time now so the need to > go through the VM has mostly gone away. Also in recent years we are > making using of highly platform specific I/O facilities that aren't > intended for porting to other platforms. > > We don't have a replacement and it's a good discussion point. A > porting interface for the libraries would help in some areas, although > not all because of the broad set of services and interfaces that are > used. Without such an interface then it does mean a little bit of > duplication and potential for inconsistencies. Common operations like > we are discussing here could be easily supported as utility functions > in libjava or elsewhere, we just haven't had any discussion here about > this topic. > > Anyway, on the specifics then we should be using open64 or open with > the LARGEFILE flag everywhere. You pointed out issue a few days ago > with the launcher parsing the JAR manifest. You should push the patch > for that. Also shout/propose patches if you find others. > > I think the close-on-exec issue does need a bit of thought. We have > several places that open files or sockets and they aren't using it so > we are dependent on the exec code to close the file descriptors in the > child. I haven't come across any bug reports so it's possible that > there aren't too many people doing fork/equivalent in native code. I > do agree we should look at it, although it less important as you point > you. > > -Alan > > From jim.gish at oracle.com Tue Mar 5 19:12:11 2013 From: jim.gish at oracle.com (Jim Gish) Date: Tue, 05 Mar 2013 14:12:11 -0500 Subject: RFR: 8002070 Remove the stack search for a resource bundle for Logger to use In-Reply-To: <51335B15.9070809@oracle.com> References: <51311CC4.5000106@oracle.com> <51335B15.9070809@oracle.com> Message-ID: <5136438B.9070205@oracle.com> On 03/03/2013 09:15 AM, Alan Bateman wrote: > On 01/03/2013 21:25, Jim Gish wrote: >> Please review >> http://cr.openjdk.java.net/~jgish/Bug8002070-RemoveResourceBundleStackSearch/ >> >> >> >> This removes the stack search from Logger.findResourceBundle() >> >> Note that because this is a change in the spec/functionality, a CCC >> request will be filed. > It's good to have this removed. The changes to the caching seem okay, > at least I don't see anything obviously wrong. > > One suggestion is to change "SystemClassLoader" into system > ClassLoader and link it to the ClassLoader.getSystemClassLoader. done > > For the LoggerResourceBundleRace test then does it have to run in its > own VM? Because we no longer search up the stack for the bundles, this test fails unless run in its own vm. However, to avoid this, I'll try to change the test to set the context classloader. > > -Alan. -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From serguei.spitsyn at oracle.com Tue Mar 5 19:26:49 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 05 Mar 2013 11:26:49 -0800 Subject: RFR(S): 8009397 test/com/sun/jdi/PrivateTransportTest.sh: ERROR: transport library missing onLoad entry: private_dt_socket In-Reply-To: <2A1F6D24-22FC-4CB4-84FD-05E8ECDDC9BF@oracle.com> References: <2A1F6D24-22FC-4CB4-84FD-05E8ECDDC9BF@oracle.com> Message-ID: <513646F9.3060601@oracle.com> Hi Staffan, Thank you for this discovery! It looks good, but I have a couple of comments. It seems, there is one more problem in this code: 68 /* check for NULL path */ 69 if (p == pathname) { 70 continue;<== Endless loop if we hit this line 71 } Do we need to do 'pathname++' before continuing at the line #70? It is going to be endless loop in cases there is a PATH_SEPARATOR at the beginning of paths or two PATH_SEPARATOR's in a row. These would be incorrect path lists but the code above is targeting exactly such cases. Also, the argument name "pathname" in the original code is confusing. Should we rename it to "pathnames"? Thanks, Serguei On 3/4/13 10:56 AM, Staffan Larsen wrote: > I accidentally stepped on this bug the other day. There is a problem in linker_md.c : dll_build_name() where an internal pointer can be moved to point outside the string. The code looks like: > > 57 static void dll_build_name(char* buffer, size_t buflen, > 58 const char* pname, const char* fname) { > 59 // Based on os_solaris.cpp > 60 > 61 char *path_sep = PATH_SEPARATOR; > 62 char *pathname = (char *)pname; > 63 while (strlen(pathname) > 0) { > 64 char *p = strchr(pathname, *path_sep); > 65 if (p == NULL) { > 66 p = pathname + strlen(pathname); > 67 } > 68 /* check for NULL path */ > 69 if (p == pathname) { > 70 continue; > 71 } > 72 (void)snprintf(buffer, buflen, "%.*s/lib%s." LIB_SUFFIX, (p - pathname), > 73 pathname, fname); > 74 > 75 if (access(buffer, F_OK) == 0) { > 76 break; > 77 } > 78 pathname = p + 1; > 79 *buffer = '\0'; > 80 } > > If the supplied pname is a buffer with a simple path without any path separators in it, p will be set to the terminating nul on line 66. Then on line 78 it will be moved outside the buffer. Fixing this also necessitates fixes to the callers to check for an empty return string (in buffer). > > The same code show up in both the solaris code and the windows code as well as hprof. > > bug: http://bugs.sun.com/view_bug.do?bug_id=8009397 > webrev: http://cr.openjdk.java.net/~sla/8009397/webrev.00/ > > Thanks, > /Staffan From henry.jen at oracle.com Tue Mar 5 19:46:08 2013 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 05 Mar 2013 11:46:08 -0800 Subject: CFR - updated 8001667: Comparator combinators and extension methods Message-ID: <51364B80.6030801@oracle.com> Hi, Another update to reflect functional interface renames involved in the API, and a bug fix for a regression found earlier. CCC had been approved. Can we get it reviewed and pushed? [1] http://cr.openjdk.java.net/~henryjen/ccc/8001667.4/webrev Cheers, Henry From martinrb at google.com Tue Mar 5 21:18:11 2013 From: martinrb at google.com (martinrb at google.com) Date: Tue, 05 Mar 2013 21:18:11 +0000 Subject: hg: jdk8/tl: 8006988: build-infra: Configure fails if 'cl' is in path on linux Message-ID: <20130305211811.50DEA47860@hg.openjdk.java.net> Changeset: a9c8a32d09f9 Author: martin Date: 2013-03-05 13:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/a9c8a32d09f9 8006988: build-infra: Configure fails if 'cl' is in path on linux Summary: Respect user CC and CXX environment variables; use cl iff on windows Reviewed-by: erikj ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 From jim.gish at oracle.com Tue Mar 5 22:29:41 2013 From: jim.gish at oracle.com (Jim Gish) Date: Tue, 05 Mar 2013 17:29:41 -0500 Subject: RFR: 8002070 Remove the stack search for a resource bundle for Logger to use In-Reply-To: <5136438B.9070205@oracle.com> References: <51311CC4.5000106@oracle.com> <51335B15.9070809@oracle.com> <5136438B.9070205@oracle.com> Message-ID: <513671D5.6010107@oracle.com> The webrev has been updated as requested: http://cr.openjdk.java.net/~jgish/Bug8002070-RemoveResourceBundleStackSearch/ A CCC request has been filed. Thanks, Jim On 03/05/2013 02:12 PM, Jim Gish wrote: > > On 03/03/2013 09:15 AM, Alan Bateman wrote: >> On 01/03/2013 21:25, Jim Gish wrote: >>> Please review >>> http://cr.openjdk.java.net/~jgish/Bug8002070-RemoveResourceBundleStackSearch/ >>> >>> >>> >>> This removes the stack search from Logger.findResourceBundle() >>> >>> Note that because this is a change in the spec/functionality, a CCC >>> request will be filed. >> It's good to have this removed. The changes to the caching seem okay, >> at least I don't see anything obviously wrong. >> >> One suggestion is to change "SystemClassLoader" into system >> ClassLoader and link it to the ClassLoader.getSystemClassLoader. > done >> >> For the LoggerResourceBundleRace test then does it have to run in its >> own VM? > Because we no longer search up the stack for the bundles, this test > fails unless run in its own vm. However, to avoid this, I'll try to > change the test to set the context classloader. >> >> -Alan. > -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From mike.duigou at oracle.com Tue Mar 5 22:46:48 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 5 Mar 2013 14:46:48 -0800 Subject: RFR: 8006593: Performance and compatibility improvements to hash based Map implementations In-Reply-To: <5135B039.7000604@gmail.com> References: <79A5A703-12DA-4C66-94F7-34534761D217@oracle.com> <51351CD1.2030804@gmail.com> <51351F60.30502@gmail.com> <8CE8CB62-1F4F-430F-B770-DB78CA530531@oracle.com> <5135B039.7000604@gmail.com> Message-ID: I have updated the webrev to remove the useAltHashing boolean. http://cr.openjdk.java.net/~mduigou/JDK-8006593/5/webrev/ Mike On Mar 5 2013, at 00:43 , Peter Levart wrote: > Hi Mike, > > You could also get rid of boolean useAltHashing field in both HashMap and Hashtable. It saves 8 bytes in both HM and HT objects in 32bit addressing modes (64bit addressing modes are not affected due to different alignment). Like the following (a patch against your webrev): > > Index: jdk/src/share/classes/java/util/Hashtable.java > =================================================================== > --- jdk/src/share/classes/java/util/Hashtable.java (date 1362469665000) > +++ jdk/src/share/classes/java/util/Hashtable.java (revision ) > @@ -213,12 +213,6 @@ > } > > /** > - * If {@code true} then perform alternative hashing of String keys to reduce > - * the incidence of collisions due to weak hash code calculation. > - */ > - transient boolean useAltHashing = false; > - > - /** > * A randomizing value associated with this instance that is applied to > * hash code of keys to make hash collisions harder to find. > */ > @@ -228,8 +222,8 @@ > * Initialize the hashing mask value. > */ > final boolean initHashSeedAsNeeded(int capacity) { > - boolean currentAltHashing = useAltHashing; > - useAltHashing = sun.misc.VM.isBooted() && > + boolean currentAltHashing = hashSeed != 0; > + boolean useAltHashing = sun.misc.VM.isBooted() && > (capacity >= Holder.ALTERNATIVE_HASHING_THRESHOLD); > boolean switching = currentAltHashing ^ useAltHashing; > if (switching) { > Index: jdk/src/share/classes/java/util/HashMap.java > =================================================================== > --- jdk/src/share/classes/java/util/HashMap.java (date 1362472425000) > +++ jdk/src/share/classes/java/util/HashMap.java (revision ) > @@ -224,17 +224,11 @@ > } > > /** > - * If {@code true} then perform alternative hashing of String keys to reduce > - * the incidence of collisions due to weak hash code calculation. > - */ > - transient boolean useAltHashing = false; > - > - /** > * A randomizing value associated with this instance that is applied to > - * hash code of keys to make hash collisions harder to find. Initialized via > - * sun.misc.Unsafe when needed. > + * hash code of keys to make hash collisions harder to find. > + * Also used (when != 0) to indicate use of alternative String hashing. > */ > - transient int hashSeed = 0; > + transient int hashSeed; > > /** > * Constructs an empty HashMap with the specified initial > @@ -319,8 +313,8 @@ > * really need it. > */ > final boolean initHashSeedAsNeeded(int capacity) { > - boolean currentAltHashing = useAltHashing; > - useAltHashing = sun.misc.VM.isBooted() && > + boolean currentAltHashing = hashSeed != 0; > + boolean useAltHashing = sun.misc.VM.isBooted() && > (capacity >= Holder.ALTERNATIVE_HASHING_THRESHOLD); > boolean switching = currentAltHashing ^ useAltHashing; > if (switching) { > @@ -339,12 +333,9 @@ > * in lower bits. Note: Null keys always map to hash 0, thus index 0. > */ > final int hash(Object k) { > - int h = 0; > - if (useAltHashing) { > - if (k instanceof String) { > + int h = hashSeed; > + if (h != 0 && k instanceof String) { > - return sun.misc.Hashing.stringHash32((String) k); > + return sun.misc.Hashing.stringHash32((String) k); > - } > - h = hashSeed; > } > > h ^= k.hashCode(); > > > Regards, Peter > > On 03/05/2013 07:08 AM, Mike Duigou wrote: >> After looking more closely at the single read reference to hashSeed I decided to simplify things and make hashSeed non-final in both Hashtable and HashMap. >> >> I've posted a refreshed webrev. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8006593/4/webrev/ >> >> Mike >> >> On Mar 4 2013, at 14:25 , Peter Levart wrote: >> >>> >>> On 03/04/2013 11:14 PM, Peter Levart wrote: >>>> Hi mike, >>>> >>>> I doubt (haven't tried it really with your code) that hashSeed will be seen by code to be anything else but 0, since it is initialized to a constant value. For example, this code: >>>> >>>> public class ModifyingFinalTest { >>>> static final Unsafe unsafe; >>>> static final long valueOffset; >>>> >>>> static { >>>> try { >>>> Field f = Unsafe.class.getDeclaredField("theUnsafe"); >>>> f.setAccessible(true); >>>> unsafe = (Unsafe)f.get(null); >>>> valueOffset = unsafe.objectFieldOffset(ModifyingFinalTest.class.getDeclaredField("value")); >>>> } >>>> catch (IllegalAccessException | NoSuchFieldException e) { >>>> throw new Error(e); >>>> } >>>> } >>>> >>>> final int value = 0; >>>> >>>> void test() { >>>> unsafe.putIntVolatile(this, valueOffset, 1); >>>> printValue(); >>>> unsafe.putIntVolatile(this, valueOffset, 2); >>>> printValue(); >>>> unsafe.putIntVolatile(this, valueOffset, 3); >>>> printValue(); >>>> } >>>> >>>> void printValue() { >>>> System.out.println(value); >>>> } >>>> >>>> public static void main(String[] args) { >>>> new ModifyingFinalTest().test(); >>>> } >>>> } >>>> >>>> >>>> Prints: >>>> >>>> 0 >>>> 0 >>>> 0 >>>> >>>> >>>> It's a different thing, if the initialization is changed to: >>>> >>>> final int value = "".length(); >>>> >>>> But I don't know if each access in source is actually guaranteed to translate to a real read of field in this case either. Is Unsafe.putIntVolatile() making this happen somehow magically? >>> >>> Well, that's not what I wanted to ask. I wanted to ask if the first access in source that happens after Unsafe.putIntVolatile() in same thread is guaranteed to read the field and not re-use a cached value ready in some register for example. Is Unsafe.putIntVolatile() making this happen somehow magically? >>> >>>> >>>> Regards, Peter >>>> >>>> >>>> On 03/04/2013 09:21 PM, Mike Duigou wrote: >>>>> Hello all; >>>>> >>>>> The alternative hashing implementation introduced in 7u6 added an unfortunate bottleneck to the initialization of HashMap and Hashtable instances. This patch avoids the performance bottleneck of using a shared Random instance by using a ThreadLocalRandom instead. >>>>> >>>>> Along with this change are some additional performance improvements to further reduce the overhead of the alternative hashing feature and generally improve the performance of Hashtable or HashMap. >>>>> >>>>> c >>>>> >>>>> Once review is completed here this patch will be proposed to JDK7u-dev for integration into the next 7u performance/feature release. >>>>> >>>>> Mike >>>>> >>>> >>> >> > From bill.pittore at oracle.com Tue Mar 5 23:05:39 2013 From: bill.pittore at oracle.com (bill.pittore at oracle.com) Date: Tue, 05 Mar 2013 18:05:39 -0500 Subject: Request for review- RFE 8005716 Message-ID: <51367A43.1060606@oracle.com> This request is tied to bugid 8005716 that deals with adding support for statically linked JNI libraries. The JEP is here: http://openjdk.java.net/jeps/178 The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716 The webrevs are here: http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.00/ http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ The main piece of functionality is to check for the presence of JNI_OnLoad_libname to determine if the library specified by 'libname' has been statically linked into the VM. If the symbol is found, it is assumed that the library is linked in and will not be dynamically loaded. thanks, bill From lana.steuck at oracle.com Wed Mar 6 00:01:22 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 06 Mar 2013 00:01:22 +0000 Subject: hg: jdk8/tl: 8 new changesets Message-ID: <20130306000123.11A4547868@hg.openjdk.java.net> Changeset: 91d35211e744 Author: katleman Date: 2013-02-21 11:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/91d35211e744 Added tag jdk8-b78 for changeset fd1a5574cf68 ! .hgtags Changeset: 85b5b4cc388c Author: katleman Date: 2013-02-28 10:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/85b5b4cc388c Added tag jdk8-b79 for changeset 91d35211e744 ! .hgtags Changeset: ab82853d3365 Author: erikj Date: 2013-02-21 14:16 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ab82853d3365 8008451: Make mac builds on 10.8 work on 10.7 Reviewed-by: ohair, ddehaven ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: d3e3d5b06f45 Author: ohair Date: 2013-02-23 10:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/d3e3d5b06f45 8004712: build-infra: Move user guide from web pages to repository Summary: Just the initial work, will need more changes. Reviewed-by: tbell ! README ! README-builds.html Changeset: 2778e6576e21 Author: katleman Date: 2013-02-26 13:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2778e6576e21 Merge Changeset: 0adf9c626bb1 Author: katleman Date: 2013-02-28 20:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/0adf9c626bb1 Merge Changeset: c022bc48b7ed Author: lana Date: 2013-03-05 11:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c022bc48b7ed Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in Changeset: c4901c0e0579 Author: lana Date: 2013-03-05 15:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c4901c0e0579 Merge ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 From lana.steuck at oracle.com Wed Mar 6 00:01:21 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 06 Mar 2013 00:01:21 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20130306000131.A9C324786A@hg.openjdk.java.net> Changeset: 70d8658d2a30 Author: katleman Date: 2013-02-21 11:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/70d8658d2a30 Added tag jdk8-b78 for changeset 391de4c992d1 ! .hgtags Changeset: b0224010e2f0 Author: katleman Date: 2013-02-28 10:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/b0224010e2f0 Added tag jdk8-b79 for changeset 70d8658d2a30 ! .hgtags From lana.steuck at oracle.com Wed Mar 6 00:01:23 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 06 Mar 2013 00:01:23 +0000 Subject: hg: jdk8/tl/jaxp: 2 new changesets Message-ID: <20130306000136.6CE1B4786B@hg.openjdk.java.net> Changeset: 58fa065dd5d6 Author: katleman Date: 2013-02-21 11:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/58fa065dd5d6 Added tag jdk8-b78 for changeset 00958c5a7070 ! .hgtags Changeset: 4873a0499bc3 Author: katleman Date: 2013-02-28 10:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/4873a0499bc3 Added tag jdk8-b79 for changeset 58fa065dd5d6 ! .hgtags From lana.steuck at oracle.com Wed Mar 6 00:01:21 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 06 Mar 2013 00:01:21 +0000 Subject: hg: jdk8/tl/corba: 3 new changesets Message-ID: <20130306000126.4D88F47869@hg.openjdk.java.net> Changeset: e41fb1aa0329 Author: katleman Date: 2013-02-21 11:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/e41fb1aa0329 Added tag jdk8-b78 for changeset 27d6368ae8ba ! .hgtags Changeset: 5f3d4a6bdd02 Author: katleman Date: 2013-02-28 10:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/5f3d4a6bdd02 Added tag jdk8-b79 for changeset e41fb1aa0329 ! .hgtags Changeset: 67ef27b4e16c Author: lana Date: 2013-03-05 11:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/67ef27b4e16c Merge From lana.steuck at oracle.com Wed Mar 6 00:01:26 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 06 Mar 2013 00:01:26 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20130306000154.C13E14786C@hg.openjdk.java.net> Changeset: 56dfafbb9e1a Author: katleman Date: 2013-02-21 11:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/56dfafbb9e1a Added tag jdk8-b78 for changeset af8417e590f4 ! .hgtags Changeset: a8227c617684 Author: katleman Date: 2013-02-28 10:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a8227c617684 Added tag jdk8-b79 for changeset 56dfafbb9e1a ! .hgtags Changeset: 188a07a0a7a0 Author: lana Date: 2013-03-05 11:51 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/188a07a0a7a0 Merge From lana.steuck at oracle.com Wed Mar 6 00:01:39 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 06 Mar 2013 00:01:39 +0000 Subject: hg: jdk8/tl/hotspot: 40 new changesets Message-ID: <20130306000357.EF8EF4786D@hg.openjdk.java.net> Changeset: db3359133cdd Author: katleman Date: 2013-02-21 11:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/db3359133cdd Added tag jdk8-b78 for changeset d5e12e7d2f71 ! .hgtags Changeset: 57b81d6c3641 Author: amurillo Date: 2013-02-15 13:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/57b81d6c3641 8008286: new hotspot build - hs25-b20 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 7adae9244bc8 Author: mgronlun Date: 2013-02-13 11:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7adae9244bc8 8007312: null check signal semaphore in os::signal_notify windows Reviewed-by: dholmes, sla ! src/os/windows/vm/os_windows.cpp Changeset: 2394a89e89f4 Author: rbackman Date: 2013-02-13 09:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2394a89e89f4 8008088: SA can hang the VM Reviewed-by: mgronlun, sla, dholmes ! agent/src/os/bsd/libproc_impl.c ! agent/src/os/bsd/libproc_impl.h ! agent/src/os/bsd/ps_proc.c ! agent/src/os/linux/libproc_impl.c ! agent/src/os/linux/libproc_impl.h ! agent/src/os/linux/ps_proc.c Changeset: 49618582fc5b Author: sla Date: 2013-02-14 13:08 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/49618582fc5b 8004840: Jstack seems to output unnecessary information in 7u9 Reviewed-by: dholmes, coleenp, sspitsyn, rbackman ! agent/src/share/classes/sun/jvm/hotspot/memory/CMSCollector.java ! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MethodData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java Changeset: 3a531d40ad93 Author: acorn Date: 2013-02-14 14:33 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3a531d40ad93 8007736: VerifyError for static method in interface Reviewed-by: dholmes, acorn Contributed-by: bharadwaj.yadavalli at oracle.com ! src/share/vm/classfile/verifier.cpp + test/runtime/8007736/TestStaticIF.java Changeset: e7e9e08147fc Author: mikael Date: 2013-02-14 12:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e7e9e08147fc 8007639: Workaround for ccache in vm.make is incorrect Summary: Fixed makefile logic to correctly special case JRE_RELEASE_VERSION and vm_version.o Reviewed-by: dholmes, erikj ! make/bsd/makefiles/vm.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make Changeset: 5d5c577296fd Author: sla Date: 2013-02-15 08:54 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5d5c577296fd 8008102: SA on OS X does not stop the attached process Reviewed-by: dholmes, rbackman ! agent/src/os/bsd/MacosxDebuggerLocal.m Changeset: f35f1fbab3e1 Author: sla Date: 2013-02-15 10:08 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f35f1fbab3e1 Merge Changeset: dc1de5e78a85 Author: dsamersoff Date: 2013-02-15 10:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dc1de5e78a85 Merge Changeset: f82bcc429e8c Author: sla Date: 2013-02-18 10:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f82bcc429e8c 8007901: SA: Don't read flag values as constants Reviewed-by: dholmes, mikael ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/share/vm/runtime/vmStructs.cpp Changeset: b5e3ec9c69fa Author: sla Date: 2013-02-18 12:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b5e3ec9c69fa 8007779: os::die() on solaris should generate core file Reviewed-by: dholmes, rbackman ! src/os/solaris/vm/os_solaris.cpp Changeset: 5cd2fac2ae70 Author: hseigel Date: 2013-02-19 08:51 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5cd2fac2ae70 6749267: Signal handler should save/restore errno Summary: Save errno before processing signal, then restore it. Reviewed-by: acorn, sspitsyn ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp Changeset: 56c364daccc3 Author: emc Date: 2013-02-19 11:36 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/56c364daccc3 8007153: Ensure that MethodParameters API works properly with RedefineClasses Summary: Adds code to HotSpot to properly update MethodParameter attributes' constant pool indexes when redefineClasses is called Reviewed-by: coleenp, sspitsyn ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 1048edb5434a Author: coleenp Date: 2013-02-19 13:33 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1048edb5434a Merge Changeset: 20fff74158eb Author: sspitsyn Date: 2013-02-20 08:51 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/20fff74158eb Merge Changeset: bbc7936779f9 Author: brutisso Date: 2013-02-14 09:11 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bbc7936779f9 8006398: Add regression tests for deprectated GCs Reviewed-by: ehelin, jwilhelm, jmasa ! test/TEST.ROOT + test/gc/startup_warnings/TestCMS.java + test/gc/startup_warnings/TestCMSIncrementalMode.java + test/gc/startup_warnings/TestCMSNoIncrementalMode.java + test/gc/startup_warnings/TestDefNewCMS.java + test/gc/startup_warnings/TestG1.java + test/gc/startup_warnings/TestIncGC.java + test/gc/startup_warnings/TestParNewCMS.java + test/gc/startup_warnings/TestParNewSerialOld.java + test/gc/startup_warnings/TestParallelGC.java + test/gc/startup_warnings/TestParallelScavengeSerialOld.java + test/gc/startup_warnings/TestSerialGC.java Changeset: fd7b3770c77e Author: tamao Date: 2013-02-14 14:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fd7b3770c77e 8007764: Wrong initialized value of max_gc_pause_sec for an instance of class AdaptiveSizePolicy Summary: This is a fix of an initialization mistake for class AdaptiveSizePolicy. Reviewed-by: jmasa Contributed-by: Tao Mao ! src/share/vm/memory/collectorPolicy.cpp Changeset: ccc57295818b Author: johnc Date: 2013-02-19 16:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ccc57295818b 8006628: NEED_TEST for JDK-8002870 Summary: Regression test for 8000311. Verifies that PLABStats works with zero parallel GC threads. Reviewed-by: jmasa, johnc Contributed-by: Filipp Zhinkin + test/gc/8000311/Test8000311.java Changeset: b9c5e46bf915 Author: johnc Date: 2013-02-20 12:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b9c5e46bf915 8008188: Add regression test for 8005875 Summary: Add regression test for crash seen in 8005875. Test is run with G1 and PGCT=0 and issues "jcmd Thread.print" against itself. Without the fix for 8005875 the test will crash. Reviewed-by: brutisso + test/gc/TestG1ZeroPGCTJcmdThreadPrint.java Changeset: 5741d3fc502d Author: brutisso Date: 2013-02-21 13:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5741d3fc502d Merge Changeset: c59b7900a2bd Author: roland Date: 2013-02-18 09:06 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c59b7900a2bd 8007959: Use expensive node logic for more math nodes Summary: use expensive node logic for other more math nodes. Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/subnode.hpp Changeset: 514efad5e81a Author: drchase Date: 2013-02-18 14:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/514efad5e81a 8008180: Several tests in compiler/5091921 need more time to run Summary: Added an explicit timeouts. Reviewed-by: kvn, twisti ! test/compiler/5091921/Test6850611.java ! test/compiler/5091921/Test6890943.java ! test/compiler/5091921/Test6905845.java ! test/compiler/5091921/Test6992759.java Changeset: a2bc322ca273 Author: drchase Date: 2013-02-18 15:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a2bc322ca273 7102300: performance warnings cause results diff failure in Test6890943 Summary: Strip lines matching the performance warning from the output before diff. Reviewed-by: kvn ! test/compiler/5091921/Test6890943.sh Changeset: ad736b4683b4 Author: kvn Date: 2013-02-18 16:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ad736b4683b4 8004867: VM crashing with assert "share/vm/opto/node.hpp:357 - assert(i < _max) failed: oob" Summary: Added few checks and early bailout from Superword optimization to avoid such cases in a future. Reviewed-by: roland, twisti ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp + test/compiler/8004867/TestIntAtomicCAS.java + test/compiler/8004867/TestIntAtomicOrdered.java + test/compiler/8004867/TestIntAtomicVolatile.java + test/compiler/8004867/TestIntUnsafeCAS.java + test/compiler/8004867/TestIntUnsafeOrdered.java + test/compiler/8004867/TestIntUnsafeVolatile.java Changeset: 2e4b16122164 Author: vlivanov Date: 2013-02-21 06:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2e4b16122164 Merge Changeset: 579f6adb7f51 Author: jprovino Date: 2013-02-05 13:32 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/579f6adb7f51 8003539: Minimal VM don't react to -Dcom.sun.management and -XX:+ManagementServer Summary: A warning message should be displayed if these options are used with the Minimal VM. Reviewed-by: dholmes, dsamersoff ! src/share/vm/runtime/arguments.cpp Changeset: 9e2da96f9976 Author: bpittore Date: 2013-02-08 16:08 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9e2da96f9976 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 6c2da81297c5 Author: kvn Date: 2013-02-12 09:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6c2da81297c5 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 84a926fe53d0 Author: bpittore Date: 2013-01-24 13:27 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/84a926fe53d0 8005722: Assert in c1_LIR.hpp incorrect wrt to number of register operands Summary: In LIR_OpVisitState::visit() the receiver operand is processed twice Reviewed-by: roland, vladidan ! src/share/vm/c1/c1_LIR.cpp Changeset: cf9a2071eeac Author: jprovino Date: 2013-02-14 11:07 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cf9a2071eeac 8006878: Some non-existent GC source files are in the minimalVM exclude list. Summary: cmsPermGen.cpp, psPermGen.cpp have been removed. yieldWorkingGroup.cpp typo is fixed. immutableSpace.cpp was in the list twice. Reviewed-by: dholmes, jmasa ! make/excludeSrc.make ! src/share/vm/utilities/yieldingWorkgroup.cpp Changeset: 1605eef8e11e Author: jprovino Date: 2013-02-14 11:08 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1605eef8e11e 8003581: UseG1GC is not properly accounted for by INCLUDE_ALTERNATE_GCS Summary: Fix warning messages when selected garbage collectors are excluded from the minimal jvm. Reviewed-by: dholmes, cjplummer ! src/share/vm/runtime/arguments.cpp Changeset: 9c7d0948523f Author: jprovino Date: 2013-02-15 14:42 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9c7d0948523f Merge Changeset: 1ba18258caa4 Author: bpittore Date: 2013-02-15 21:53 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1ba18258caa4 Merge ! src/share/vm/runtime/arguments.cpp Changeset: abf488c22e09 Author: bpittore Date: 2013-02-20 23:29 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/abf488c22e09 Merge Changeset: 2af22eb04623 Author: vladidan Date: 2013-02-21 09:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2af22eb04623 Merge Changeset: ed96c6015470 Author: vladidan Date: 2013-02-21 11:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ed96c6015470 Merge Changeset: 555ec35a2507 Author: amurillo Date: 2013-02-22 10:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/555ec35a2507 Merge Changeset: 6691814929b6 Author: amurillo Date: 2013-02-22 10:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6691814929b6 Added tag hs25-b20 for changeset 555ec35a2507 ! .hgtags Changeset: 5d395eb2626f Author: katleman Date: 2013-02-28 10:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5d395eb2626f Added tag jdk8-b79 for changeset 6691814929b6 ! .hgtags From lana.steuck at oracle.com Wed Mar 6 00:01:53 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 06 Mar 2013 00:01:53 +0000 Subject: hg: jdk8/tl/jdk: 12 new changesets Message-ID: <20130306000514.3EE0B4786E@hg.openjdk.java.net> Changeset: bb97c93e4fd7 Author: katleman Date: 2013-02-21 11:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb97c93e4fd7 Added tag jdk8-b78 for changeset 00b7535d743f ! .hgtags Changeset: 5245b2f1c53d Author: ngthomas Date: 2013-02-21 17:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5245b2f1c53d 8008691: Build failure (NEWBUILD=false) on Mac Reviewed-by: art, anthony ! make/sun/lwawt/FILES_export_macosx.gmk Changeset: c933505d75c2 Author: dcherepanov Date: 2013-02-26 12:54 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c933505d75c2 Merge Changeset: d967dd39a5ca Author: katleman Date: 2013-02-28 10:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d967dd39a5ca Added tag jdk8-b79 for changeset c933505d75c2 ! .hgtags Changeset: 5a1ea5bbe10a Author: erikj Date: 2013-02-21 14:14 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5a1ea5bbe10a 8007387: "sed: RE error: illegal byte sequence" when building images on Mac Reviewed-by: tbell ! makefiles/Images.gmk Changeset: a287f6a0d46d Author: erikj Date: 2013-02-21 14:16 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a287f6a0d46d 8008451: Make mac builds on 10.8 work on 10.7 Reviewed-by: ohair, ddehaven ! make/common/Defs-macosx.gmk Changeset: 5d27f8702118 Author: erikj Date: 2013-02-21 14:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5d27f8702118 8007903: 8005583's changes to make/install-rules.gmk need to made to jdk/make/closed/InstallWrapper.gmk Reviewed-by: tbell, ohair ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Defs-utils.gmk Changeset: f0b5b57014b3 Author: katleman Date: 2013-02-26 13:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f0b5b57014b3 Merge Changeset: 8d3dbb724859 Author: katleman Date: 2013-02-27 13:10 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8d3dbb724859 Merge Changeset: b760d5d4b8d3 Author: katleman Date: 2013-02-28 19:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b760d5d4b8d3 8009196: install doesn't define $(AR) as /usr/ccs/bin/ar, results in ar: Command not found Reviewed-by: tbell ! make/common/shared/Defs-utils.gmk Changeset: dfb40f066c6c Author: katleman Date: 2013-02-28 20:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dfb40f066c6c Merge Changeset: f960a34f05ce Author: lana Date: 2013-03-05 11:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f960a34f05ce Merge ! makefiles/Images.gmk From martinrb at google.com Wed Mar 6 01:45:20 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 5 Mar 2013 17:45:20 -0800 Subject: Define JNIEXPORT as visibility default with GCC? In-Reply-To: References: <511CAE4C.2000002@redhat.com> <4974FD20-B6DD-40F5-A7E9-B78F09E9C2A1@oracle.com> <511D5A8F.7050403@redhat.com> <511E0BD7.4040603@oracle.com> <511E667D.2000700@redhat.com> <51215FE5.1080405@oracle.com> <5121F60C.5040004@redhat.com> <51241726.2040102@oracle.com> Message-ID: Another rev of this change. I added the condition check for gcc > 4.2 (I don't much care either way) I just ran "clang" for the first time, and was surprised that clang has values of __GNUC__ == 4 and __GNUC_MINOR__ == 2 I think we should keep the __has_attribute check, because it seems clearly correct and recommended by http://clang.llvm.org/docs/LanguageExtensions.html#feature-checking-macros and with luck, __has_attribute will become a minor industry standard from the innovators in llvm-land. I really like the design of their extension mechanisms. On Wed, Feb 27, 2013 at 3:07 PM, Martin Buchholz wrote: > Here's the latest version of the proposed patch: > > http://cr.openjdk.java.net/~martin/webrevs/openjdk8/JNIEXPORT/ > > that has been tested, but only with gcc 4.6, > but is also written to work with llvm. > From david.holmes at oracle.com Wed Mar 6 03:39:39 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 Mar 2013 13:39:39 +1000 Subject: Request for review: 8009529: Fix for 8006988 missed closed configure changes Message-ID: <5136BA7B.3000709@oracle.com> We need to regenerate the open and closed configure scripts in the tl forest. The open change is trivial as it just updates the timestamp: > hg diff diff -r c4901c0e0579 common/autoconf/generated-configure.sh --- a/common/autoconf/generated-configure.sh +++ b/common/autoconf/generated-configure.sh @@ -3725,7 +3725,7 @@ #CUSTOM_AUTOCONF_INCLUDE # Do not change or remove the following line, it is needed for consistency checks: -DATE_WHEN_GENERATED=1362517596 +DATE_WHEN_GENERATED=1362540061 ############################################################################### # I need a nocturnal Reviewer please :) Thanks, David From mark.reinhold at oracle.com Wed Mar 6 03:42:50 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 05 Mar 2013 19:42:50 -0800 Subject: Request for review: 8009529: Fix for 8006988 missed closed configure changes In-Reply-To: <5136BA7B.3000709@oracle.com> References: <5136BA7B.3000709@oracle.com> Message-ID: <20130305194250.443822@eggemoggin.niobe.net> 2013/3/5 11:39 -0800, david.holmes at oracle.com: > We need to regenerate the open and closed configure scripts in the tl > forest. > > The open change is trivial as it just updates the timestamp: > >> hg diff > diff -r c4901c0e0579 common/autoconf/generated-configure.sh > --- a/common/autoconf/generated-configure.sh > +++ b/common/autoconf/generated-configure.sh > @@ -3725,7 +3725,7 @@ > #CUSTOM_AUTOCONF_INCLUDE > > # Do not change or remove the following line, it is needed for > consistency checks: > -DATE_WHEN_GENERATED=1362517596 > +DATE_WHEN_GENERATED=1362540061 > > > ############################################################################### > # > > I need a nocturnal Reviewer please :) Looks good to me. (Sigh, we really need to fix this very brittle system ...) - Mark From bill.pittore at oracle.com Wed Mar 6 04:13:31 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Tue, 05 Mar 2013 23:13:31 -0500 Subject: Request for review- RFE 8005716 In-Reply-To: <51368F88.8000309@oracle.com> References: <51367A43.1060606@oracle.com> <51368F88.8000309@oracle.com> Message-ID: <5136C26B.7000805@oracle.com> On 3/5/2013 7:36 PM, Dean Long wrote: > If JNI_ONLOAD_SYMBOLS contains something like "_JNI_OnLoad at 8" on > Windows, you can't just > turn that into "_JNI_OnLoad at 8_" + . I think it needs to be > "_JNI_OnLoad_" + + "@8" I'll look into that. When I built for windows and ran our test, the JNI_OnLoad_TestStaticLib was exported without the decoration just based on the JNIEXPORT JNICALL specifiers on the function. I didn't do anything special to export it. But I recall this problem from another project. 1 0 00001014 JNI_OnLoad_TestStaticLib = @ILT+15(?JNI_OnLoad_TestStaticLib@@YGHPAUJavaVM_@@PAX at Z) > > Looks like onLoadSymbols[] is unused in > Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib(). I'll remove that. I redid the call to findBuiltinJniFunction but forgot to remove that. > > Instead of adding getProcessHandle(), why not add > JVM_FindBuiltinLibraryEntry() instead? > This would make it easier to support table-lookup when runtime symbol > information is missing or not > supported by the platform. Not sure I'm following you on this. Make JVM_FindBuiltinLibraryEntry() an exported function in the VM? How does it find JNI_OnLoad_L? Via a table setup by the developer/build system when the library is linked in? bill > > dl > > On 3/5/2013 3:05 PM, bill.pittore at oracle.com wrote: >> This request is tied to bugid 8005716 that deals with adding support >> for statically linked JNI libraries. >> >> The JEP is here: http://openjdk.java.net/jeps/178 >> >> The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716 >> >> The webrevs are here: >> >> http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.00/ >> http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ >> >> The main piece of functionality is to check for the presence of >> JNI_OnLoad_libname to determine if the library specified by 'libname' >> has been statically linked into the VM. If the symbol is found, it is >> assumed that the library is linked in and will not be dynamically >> loaded. >> >> thanks, >> bill > From martinrb at google.com Wed Mar 6 04:28:49 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 5 Mar 2013 20:28:49 -0800 Subject: Define JNIEXPORT as visibility default with GCC? In-Reply-To: References: <511CAE4C.2000002@redhat.com> <4974FD20-B6DD-40F5-A7E9-B78F09E9C2A1@oracle.com> <511D5A8F.7050403@redhat.com> <511E0BD7.4040603@oracle.com> <511E667D.2000700@redhat.com> <51215FE5.1080405@oracle.com> <5121F60C.5040004@redhat.com> <51241726.2040102@oracle.com> Message-ID: More changes. I discovered that with JNIEXPORT defined to use the attribute, typedefs that included JNIEXPORT would generate a gcc -Wattribute warning warning: visibility attribute ignored. These new warnings are annoying, but arguably, the use of JNIEXPORT in a typedef was a bug all along - JNIEXPORT should be all about actual symbols, not types. (But I couldn't find any actual spec for JNIEXPORT; could somebody please fix that?). So I removed all occurences of JNIEXPORT inside a typedef that caused a -Wattribute warning. http://cr.openjdk.java.net/~martin/webrevs/openjdk8/JNIEXPORT/ Martin On Tue, Mar 5, 2013 at 5:45 PM, Martin Buchholz wrote: > Another rev of this change. > I added the condition check for gcc > 4.2 > (I don't much care either way) > > I just ran "clang" for the first time, and was surprised that clang has > values of __GNUC__ == 4 and __GNUC_MINOR__ == 2 > > I think we should keep the __has_attribute check, because it seems clearly > correct and recommended by > http://clang.llvm.org/docs/LanguageExtensions.html#feature-checking-macros > and with luck, __has_attribute will become a minor industry standard from > the innovators in llvm-land. > I really like the design of their extension mechanisms. > > > > On Wed, Feb 27, 2013 at 3:07 PM, Martin Buchholz wrote: > >> Here's the latest version of the proposed patch: >> >> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/JNIEXPORT/ >> >> that has been tested, but only with gcc 4.6, >> but is also written to work with llvm. >> > > From david.holmes at oracle.com Wed Mar 6 07:36:22 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Wed, 06 Mar 2013 07:36:22 +0000 Subject: hg: jdk8/tl: 8009529: Fix for 8006988 missed closed configure changes Message-ID: <20130306073622.B6BFE47882@hg.openjdk.java.net> Changeset: 929e2461818b Author: dholmes Date: 2013-03-05 22:45 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/929e2461818b 8009529: Fix for 8006988 missed closed configure changes Reviewed-by: mr ! common/autoconf/generated-configure.sh From paul.sandoz at oracle.com Wed Mar 6 09:51:36 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 6 Mar 2013 10:51:36 +0100 Subject: CFR - updated 8001667: Comparator combinators and extension methods In-Reply-To: <51364B80.6030801@oracle.com> References: <51364B80.6030801@oracle.com> Message-ID: <925A00C1-7700-49EB-BBE0-6BFEBC19C25A@oracle.com> Hi Henry, Minor thing. In Comparator: 194 * @param other the other comparator used when equals on this. 195 * @throws NullPointerException if the argument is null. 196 * @since 1.8 197 */ 198 default Comparator thenComparing(Comparator other) { 199 return Comparators.compose(this, other); 200 } Perhaps: @param other the other comparator to be used when this comparator compares two objects that are equal @throws NullPointerException if the argument is null. @since 1.8 @return A lexicographic order comparator composed of this and then the other comparator In Comparators: 241 * @param the element type to be compared 242 * @param first the first comparator 243 * @param second the secondary comparator used when equals on the first 244 */ 245 public static Comparator compose(Comparator first, Comparator second) { 246 Objects.requireNonNull(first); 247 Objects.requireNonNull(second); 248 return (Comparator & Serializable) (c1, c2) -> { 249 int res = first.compare(c1, c2); 250 return (res != 0) ? res : second.compare(c1, c2); 251 }; 252 } @param second the second comparator to be used when the first comparator compares two objects that are equal @return A lexicographic order comparator composed of the first and then the second comparator Paul. On Mar 5, 2013, at 8:46 PM, Henry Jen wrote: > Hi, > > Another update to reflect functional interface renames involved in the > API, and a bug fix for a regression found earlier. > > CCC had been approved. Can we get it reviewed and pushed? > > [1] http://cr.openjdk.java.net/~henryjen/ccc/8001667.4/webrev > > Cheers, > Henry From forax at univ-mlv.fr Wed Mar 6 09:47:56 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 06 Mar 2013 10:47:56 +0100 Subject: RFR : JDK-8001642 : Add Optional, OptionalDouble, OptionalInt, OptionalLong In-Reply-To: References: Message-ID: <513710CC.3010903@univ-mlv.fr> Ok, let be nuclear on this, There is no good reason to introduce Optional in java.util. It doen't work like Google's Guava Optional despite having the same name, it doesn't work like Scala's Option despite having a similar name, moreover the lambda pipeline face a similar issue with the design of collectors (see stream.collect()) but solve that similar problem with a different design, so the design of Optional is not even consistent with the rest of the stream API. So why do we want something like Optional, we want it to be able to represent the fact that as Mike states a returning result can have no value by example Colections.emptyList().stream().findFirst() should 'return' no value. As Stephen Colebourne said, Optional is a bad name because Scala uses Option [1] which can used in the same context, as result of a filter/map etc. but Option in Scala is a way to mask null. Given the name proximity, people will start to use Optional like Option in Scala and we will see methods returning things like Optional>>. Google's Guava, which is a popular library, defines a class named Optional, but allow to store null unlike the current proposed implementation, this will generate a lot of confusions and frustrations. In fact, we don't need Optional at all, because we don't need to return a value that can represent a value or no value, the idea is that methods like findFirst should take a lambda as parameter letting the user to decide what value should be returned by findFirst if there is a value and if there is no value. So instead of stream.findFirst().orElse(null) you will write stream.findFirst(orNull) with orNull() defined as like that public static Optionalizer orNull() { return (isPresent, element) -> isPresent? element: null; } The whole design is explained here [2] and is similar to the way Collectors are defined [3], it's basically the lambda way of thinking, instead of creating an object representing the different states resulting of a call to findFirst, findFirst takes a lambda as parameter which is fed with the states of a call. cheers, R?mi [1] http://www.scala-lang.org/api/current/index.html#scala.Option [2] http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2013-February/001470.html [3] http://hg.openjdk.java.net/lambda/lambda/jdk/file/tip/src/share/classes/java/util/stream/Collectors.java On 03/04/2013 09:29 PM, Mike Duigou wrote: > Hello All; > > This patch introduces Optional container objects to be used by the lambda streams libraries for returning results. > > The reference Optional type, as defined, intentionally does not allow null values. null may be used with the Optional.orElse() method. > > All of the Optional types define hashCode() and equals implementations. Use of Optional types in collections should be generally discouraged but having useful equals() and hashCode() is ever so convenient. > > http://cr.openjdk.java.net/~mduigou/JDK-8001642/0/webrev/ > > Mike > From staffan.larsen at oracle.com Wed Mar 6 10:08:39 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Wed, 06 Mar 2013 10:08:39 +0000 Subject: hg: jdk8/tl/jdk: 8009397: test/com/sun/jdi/PrivateTransportTest.sh: ERROR: transport library missing onLoad entry: private_dt_socket Message-ID: <20130306100905.09CEC4788F@hg.openjdk.java.net> Changeset: 34372bb9115d Author: sla Date: 2013-03-05 19:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/34372bb9115d 8009397: test/com/sun/jdi/PrivateTransportTest.sh: ERROR: transport library missing onLoad entry: private_dt_socket Reviewed-by: alanb ! src/share/back/transport.c ! src/share/demo/jvmti/hprof/hprof_init.c ! src/solaris/back/linker_md.c ! src/solaris/demo/jvmti/hprof/hprof_md.c ! src/windows/back/linker_md.c ! src/windows/demo/jvmti/hprof/hprof_md.c From forax at univ-mlv.fr Wed Mar 6 11:58:43 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 06 Mar 2013 12:58:43 +0100 Subject: RFR : JDK-8001642 : Add Optional, OptionalDouble, OptionalInt, OptionalLong In-Reply-To: References: <513710CC.3010903@univ-mlv.fr> Message-ID: <51372F73.70004@univ-mlv.fr> On 03/06/2013 11:54 AM, Jed Wesley-Smith wrote: > Really, this is a lot of fuss over nothing. > > There is actually no fundamental difference between Scala's Option, Guava's Optional, Fugue's Option, Java's Optional and Haskell's Maybe ? they are modelling the same thing, the possibility of a value not being present. > > The fact that there may be minor differences in api or semantics around whether null is a legal value are minor in the scheme of things (and yes, null is a pretty stupid legal value of a Some IMHO). > > Stephen's example is ludicrous, why have a list of optional values? You'd flatten down into just a list ? and an optional list only makes sense if the enclosed list is guaranteed to be non-empty, otherwise you just return an empty list! People like shooting their own feet. http://cs.calstatela.edu/wiki/index.php/Courses/CS_460/Fall_2012/Week_8/gamePlay.combat.BattleAnalysis > > If we are going to use potential straw-men as arguments we can stall all progress. Please concentrate on the important matters, let's disavow null as a valid value and save us all a billion dollars Also Scala Option is not the only way to solve the null problem. The JSR308 annotation @Nullable/@NonNull are recognized by Eclipse and IntelliJ at least. > . > > cheers, > jed. cheers, R?mi > > On 06/03/2013, at 8:47 PM, Remi Forax wrote: > >> Ok, let be nuclear on this, >> There is no good reason to introduce Optional in java.util. >> >> It doen't work like Google's Guava Optional despite having the same >> name, it doesn't work like Scala's Option despite having a similar name, >> moreover the lambda pipeline face a similar issue with the design of >> collectors (see stream.collect()) but solve that similar problem with a >> different design, so the design of Optional is not even consistent with >> the rest of the stream API. >> >> So why do we want something like Optional, we want it to be able to >> represent the fact that as Mike states a returning result can have no >> value by example Colections.emptyList().stream().findFirst() should >> 'return' no value. >> >> As Stephen Colebourne said, Optional is a bad name because Scala uses >> Option [1] which can used in the same context, as result of a filter/map >> etc. but Option in Scala is a way to mask null. Given the name >> proximity, people will start to use Optional like Option in Scala and we >> will see methods returning things like Optional>>. >> >> Google's Guava, which is a popular library, defines a class named >> Optional, but allow to store null unlike the current proposed >> implementation, this will generate a lot of confusions and frustrations. >> >> In fact, we don't need Optional at all, because we don't need to return >> a value that can represent a value or no value, >> the idea is that methods like findFirst should take a lambda as >> parameter letting the user to decide what value should be returned by >> findFirst if there is a value and if there is no value. >> So instead of >> stream.findFirst().orElse(null) >> you will write >> stream.findFirst(orNull) >> with orNull() defined as like that >> public static Optionalizer orNull() { >> return (isPresent, element) -> isPresent? element: null; >> } >> >> The whole design is explained here [2] and is similar to the way >> Collectors are defined [3], >> it's basically the lambda way of thinking, instead of creating an object >> representing the different states resulting of a call to findFirst, >> findFirst takes a lambda as parameter which is fed with the states of a >> call. >> >> cheers, >> R?mi >> >> [1] http://www.scala-lang.org/api/current/index.html#scala.Option >> [2] >> http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2013-February/001470.html >> [3] >> http://hg.openjdk.java.net/lambda/lambda/jdk/file/tip/src/share/classes/java/util/stream/Collectors.java >> >> >> On 03/04/2013 09:29 PM, Mike Duigou wrote: >>> Hello All; >>> >>> This patch introduces Optional container objects to be used by the lambda streams libraries for returning results. >>> >>> The reference Optional type, as defined, intentionally does not allow null values. null may be used with the Optional.orElse() method. >>> >>> All of the Optional types define hashCode() and equals implementations. Use of Optional types in collections should be generally discouraged but having useful equals() and hashCode() is ever so convenient. >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-8001642/0/webrev/ >>> >>> Mike >>> >> From Alan.Bateman at oracle.com Wed Mar 6 13:14:19 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 06 Mar 2013 13:14:19 +0000 Subject: Request for review- RFE 8005716 In-Reply-To: <5136C26B.7000805@oracle.com> References: <51367A43.1060606@oracle.com> <51368F88.8000309@oracle.com> <5136C26B.7000805@oracle.com> Message-ID: <5137412B.5080703@oracle.com> On 06/03/2013 04:13, BILL PITTORE wrote: > On 3/5/2013 7:36 PM, Dean Long wrote: >> If JNI_ONLOAD_SYMBOLS contains something like "_JNI_OnLoad at 8" on >> Windows, you can't just >> turn that into "_JNI_OnLoad at 8_" + . I think it needs to be >> "_JNI_OnLoad_" + + "@8" > I'll look into that. When I built for windows and ran our test, the > JNI_OnLoad_TestStaticLib was exported without the decoration just > based on the JNIEXPORT JNICALL specifiers on the function. I didn't do > anything special to export it. But I recall this problem from another > project. > 1 0 00001014 JNI_OnLoad_TestStaticLib = > @ILT+15(?JNI_OnLoad_TestStaticLib@@YGHPAUJavaVM_@@PAX at Z) Dean makes a good point, the @8 need be at the end to match the decoration scheme. Also I think it's 32-bit only although it should just not be found on 64-bit so it will skip on JNI_OnLoad_L. -Alan. From Alan.Bateman at oracle.com Wed Mar 6 13:47:00 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 06 Mar 2013 13:47:00 +0000 Subject: Request for review- RFE 8005716 In-Reply-To: <51367A43.1060606@oracle.com> References: <51367A43.1060606@oracle.com> Message-ID: <513748D4.3080803@oracle.com> On 05/03/2013 23:05, bill.pittore at oracle.com wrote: > This request is tied to bugid 8005716 that deals with adding support > for statically linked JNI libraries. > > The JEP is here: http://openjdk.java.net/jeps/178 > > The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716 > > The webrevs are here: > > http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.00/ > http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ > > The main piece of functionality is to check for the presence of > JNI_OnLoad_libname to determine if the library specified by 'libname' > has been statically linked into the VM. If the symbol is found, it is > assumed that the library is linked in and will not be dynamically loaded. Overall I think this is quite good and follows the proposal in the JEP. I don't see anything obvious wrong with the logic and everything should just work for shared libraries as it does today. I assume you'll run all the appropriate tests. I see Dean's suggestion to add a JVM function to allow for a lookup table when the symbol information is available, If you do that then you'll need to get the hotspot changes in first. Alternatively, change what you have later once the hotspot changes are in.Just on the As findBuiltJniFunction can locate a built-in or a JNI_OnLoad/OnUnload in a library then the function name is probably not quite right (shouldn't have "Builtin" in the name). A minor nit in _findBuiltinLib is that if the OOME path should call JNU_ReleaseStringPlatformChars before returning. There are a few commented out statements in jni_util_md.c that I assume will be removed. Also you might want to check the indentation in both getProcessHandle implementations as they look like 2-spaces whereas the libs uses 4 (although this may be mute if you use a JVM function). Otherwise I think this is good and I can sponsor the jdk part to this and help get it into jdk8/tl. -Alan From joel.franck at oracle.com Wed Mar 6 14:37:13 2013 From: joel.franck at oracle.com (=?ISO-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Wed, 06 Mar 2013 15:37:13 +0100 Subject: RFR: 8007808: Missing method: Executable.getAnnotatedReturnType() Message-ID: <51375499.2070500@oracle.com> Hi, Can I get a review of this small fix for issue 8007808: Missing method: Executable.getAnnotatedReturnType() http://cr.openjdk.java.net/~jfranck/8007808/webrev.00/ When we added Core Reflection support for type annotations this method got left out on Executable, but were included on Method and Constructor. For Oracle reviewers, CCC is approved. cheers /Joel From maurizio.cimadamore at oracle.com Wed Mar 6 15:34:30 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 06 Mar 2013 15:34:30 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20130306153443.7FD8C4789E@hg.openjdk.java.net> Changeset: d0178bd8125c Author: mcimadamore Date: 2013-03-06 15:29 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d0178bd8125c 8009299: Javac crashes when compiling method reference to static interface method Summary: Assertion in Check.checMethod is too strict Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java + test/tools/javac/lambda/MethodReference66.java Changeset: 8a78243291ef Author: mcimadamore Date: 2013-03-06 15:33 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8a78243291ef 8009459: Wrong behavior of diamond finder with source level 7 Summary: Diamond finder doesn't take into account different inference behaviors Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/generics/diamond/6939780/T6939780.java + test/tools/javac/generics/diamond/6939780/T6939780_7.out + test/tools/javac/generics/diamond/6939780/T6939780_8.out - test/tools/javac/generics/diamond/T6939780.java - test/tools/javac/generics/diamond/T6939780.out Changeset: c98b3e96c726 Author: mcimadamore Date: 2013-03-06 15:33 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c98b3e96c726 8009391: Synthetic name of serializable lambda methods should not contain negative numbers Summary: Use hex representation of method signature hashcode to avoid negative numbers Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java From joe.darcy at oracle.com Wed Mar 6 15:35:14 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 06 Mar 2013 07:35:14 -0800 Subject: RFR: 8007808: Missing method: Executable.getAnnotatedReturnType() In-Reply-To: <51375499.2070500@oracle.com> References: <51375499.2070500@oracle.com> Message-ID: <51376232.4050904@oracle.com> Hi Joel, Look good; approved. -Joe On 3/6/2013 6:37 AM, Joel Borggr?n-Franck wrote: > Hi, > > Can I get a review of this small fix for issue 8007808: Missing > method: Executable.getAnnotatedReturnType() > > http://cr.openjdk.java.net/~jfranck/8007808/webrev.00/ > > When we added Core Reflection support for type annotations this method > got left out on Executable, but were included on Method and Constructor. > > For Oracle reviewers, CCC is approved. > > cheers > /Joel From zhong.j.yu at gmail.com Wed Mar 6 16:14:46 2013 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Wed, 6 Mar 2013 10:14:46 -0600 Subject: RFR : JDK-8001642 : Add Optional, OptionalDouble, OptionalInt, OptionalLong In-Reply-To: <513710CC.3010903@univ-mlv.fr> References: <513710CC.3010903@univ-mlv.fr> Message-ID: Just another idea: findFirst() throws NoSuchElementException if the stream is empty. Add an intermediary operation that maps an empty stream to a non-empty one Stream ifEmpty(T item); so we can say stream.ifEmpty(null).findFirst(); stream.ifEmpty(0).reduce(sum); stream.ifEmpty(-1).min(); Zhong Yu On Wed, Mar 6, 2013 at 3:47 AM, Remi Forax wrote: > Ok, let be nuclear on this, > There is no good reason to introduce Optional in java.util. > > It doen't work like Google's Guava Optional despite having the same > name, it doesn't work like Scala's Option despite having a similar name, > moreover the lambda pipeline face a similar issue with the design of > collectors (see stream.collect()) but solve that similar problem with a > different design, so the design of Optional is not even consistent with > the rest of the stream API. > > So why do we want something like Optional, we want it to be able to > represent the fact that as Mike states a returning result can have no > value by example Colections.emptyList().stream().findFirst() should > 'return' no value. > > As Stephen Colebourne said, Optional is a bad name because Scala uses > Option [1] which can used in the same context, as result of a filter/map > etc. but Option in Scala is a way to mask null. Given the name > proximity, people will start to use Optional like Option in Scala and we > will see methods returning things like Optional>>. > > Google's Guava, which is a popular library, defines a class named > Optional, but allow to store null unlike the current proposed > implementation, this will generate a lot of confusions and frustrations. > > In fact, we don't need Optional at all, because we don't need to return > a value that can represent a value or no value, > the idea is that methods like findFirst should take a lambda as > parameter letting the user to decide what value should be returned by > findFirst if there is a value and if there is no value. > So instead of > stream.findFirst().orElse(null) > you will write > stream.findFirst(orNull) > with orNull() defined as like that > public static Optionalizer orNull() { > return (isPresent, element) -> isPresent? element: null; > } > > The whole design is explained here [2] and is similar to the way > Collectors are defined [3], > it's basically the lambda way of thinking, instead of creating an object > representing the different states resulting of a call to findFirst, > findFirst takes a lambda as parameter which is fed with the states of a > call. > > cheers, > R?mi > > [1] http://www.scala-lang.org/api/current/index.html#scala.Option > [2] > http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2013-February/001470.html > [3] > http://hg.openjdk.java.net/lambda/lambda/jdk/file/tip/src/share/classes/java/util/stream/Collectors.java > > > On 03/04/2013 09:29 PM, Mike Duigou wrote: >> Hello All; >> >> This patch introduces Optional container objects to be used by the lambda streams libraries for returning results. >> >> The reference Optional type, as defined, intentionally does not allow null values. null may be used with the Optional.orElse() method. >> >> All of the Optional types define hashCode() and equals implementations. Use of Optional types in collections should be generally discouraged but having useful equals() and hashCode() is ever so convenient. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8001642/0/webrev/ >> >> Mike >> > > From forax at univ-mlv.fr Wed Mar 6 16:15:27 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 06 Mar 2013 17:15:27 +0100 Subject: RFR: 8007808: Missing method: Executable.getAnnotatedReturnType() In-Reply-To: <51376232.4050904@oracle.com> References: <51375499.2070500@oracle.com> <51376232.4050904@oracle.com> Message-ID: <51376B9F.6080800@univ-mlv.fr> Hi Joel, looks good for me too :) R?mi On 03/06/2013 04:35 PM, Joe Darcy wrote: > Hi Joel, > > Look good; approved. > > -Joe > > On 3/6/2013 6:37 AM, Joel Borggr?n-Franck wrote: >> Hi, >> >> Can I get a review of this small fix for issue 8007808: Missing >> method: Executable.getAnnotatedReturnType() >> >> http://cr.openjdk.java.net/~jfranck/8007808/webrev.00/ >> >> When we added Core Reflection support for type annotations this >> method got left out on Executable, but were included on Method and >> Constructor. >> >> For Oracle reviewers, CCC is approved. >> >> cheers >> /Joel > From bob.vandette at oracle.com Wed Mar 6 16:21:40 2013 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 6 Mar 2013 11:21:40 -0500 Subject: Request for review- RFE 8005716 In-Reply-To: <51368F88.8000309@oracle.com> References: <51367A43.1060606@oracle.com> <51368F88.8000309@oracle.com> Message-ID: <03D91B6F-800F-4DA0-852C-6FC2D5AF06F1@oracle.com> On Mar 5, 2013, at 7:36 PM, Dean Long wrote: > If JNI_ONLOAD_SYMBOLS contains something like "_JNI_OnLoad at 8" on Windows, you can't just > turn that into "_JNI_OnLoad at 8_" + . I think it needs to be > "_JNI_OnLoad_" + + "@8" > Good catch Dean. > Looks like onLoadSymbols[] is unused in Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib(). > > Instead of adding getProcessHandle(), why not add JVM_FindBuiltinLibraryEntry() instead? > This would make it easier to support table-lookup when runtime symbol information is missing or not > supported by the platform. Bill has already factored out the implementation of getProcessHandle. Although your approach is cleaner, I'm concerned about creating a VM version dependency. For a traditional JRE that doesn't even require static library support, we'd have to make sure to run on a VM that support JNI_VERSION_1_8. It looks like the JDK maintains their own copy of jni.h. If they didn't do that, we would have already gone down that path. The jdk sources already contain several instances of dlopen, dlysym and the Windows equivalents so I don't see a need to add a new VM function. Bob. > > dl > > On 3/5/2013 3:05 PM, bill.pittore at oracle.com wrote: >> This request is tied to bugid 8005716 that deals with adding support for statically linked JNI libraries. >> >> The JEP is here: http://openjdk.java.net/jeps/178 >> >> The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716 >> >> The webrevs are here: >> >> http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.00/ >> http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ >> >> The main piece of functionality is to check for the presence of JNI_OnLoad_libname to determine if the library specified by 'libname' has been statically linked into the VM. If the symbol is found, it is assumed that the library is linked in and will not be dynamically loaded. >> >> thanks, >> bill > From mike.duigou at oracle.com Wed Mar 6 16:47:34 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 06 Mar 2013 16:47:34 +0000 Subject: hg: jdk8/tl: 8009162: root repo "make test" target should run against image Message-ID: <20130306164734.C6784478A4@hg.openjdk.java.net> Changeset: b35d986ff276 Author: mduigou Date: 2013-03-06 08:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b35d986ff276 8009162: root repo "make test" target should run against image Reviewed-by: alanb, martin, erikj ! common/makefiles/Main.gmk From Alan.Bateman at oracle.com Wed Mar 6 17:19:55 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 06 Mar 2013 17:19:55 +0000 Subject: RFR: 8006593: Performance and compatibility improvements to hash based Map implementations In-Reply-To: References: <79A5A703-12DA-4C66-94F7-34534761D217@oracle.com> <51351CD1.2030804@gmail.com> <51351F60.30502@gmail.com> <8CE8CB62-1F4F-430F-B770-DB78CA530531@oracle.com> <5135B039.7000604@gmail.com> Message-ID: <51377ABB.3040409@oracle.com> On 05/03/2013 22:46, Mike Duigou wrote: > I have updated the webrev to remove the useAltHashing boolean. > > http://cr.openjdk.java.net/~mduigou/JDK-8006593/5/webrev/ > > Mike > Peter's suggestion to remove the useAltHashing field is a great idea. I've looked at the webrev and it looks good to me. The logical xor in initHashSeedAsNeeded is subtle. As this is for jdk7u only then I assume you'll get approval on jdk7u-dev once you are done here. -Alan. From mike.duigou at oracle.com Wed Mar 6 17:30:23 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 6 Mar 2013 09:30:23 -0800 Subject: RFR: 8006593: Performance and compatibility improvements to hash based Map implementations In-Reply-To: <51377ABB.3040409@oracle.com> References: <79A5A703-12DA-4C66-94F7-34534761D217@oracle.com> <51351CD1.2030804@gmail.com> <51351F60.30502@gmail.com> <8CE8CB62-1F4F-430F-B770-DB78CA530531@oracle.com> <5135B039.7000604@gmail.com> <51377ABB.3040409@oracle.com> Message-ID: <98F0500F-45CB-430A-9A7E-215189F3CAEC@oracle.com> On Mar 6 2013, at 09:19 , Alan Bateman wrote: > On 05/03/2013 22:46, Mike Duigou wrote: >> >> I have updated the webrev to remove the useAltHashing boolean. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8006593/5/webrev/ >> >> Mike >> > Peter's suggestion to remove the useAltHashing field is a great idea. > > I've looked at the webrev and it looks good to me. The logical xor in initHashSeedAsNeeded is subtle. > > As this is for jdk7u only then I assume you'll get approval on jdk7u-dev once you are done here. Yes. Per the original review request: > Once review is completed here this patch will be proposed to JDK7u-dev for integration into the next 7u > performance/feature release. I am going to leave this review open for another 24 hours before requesting approval from JDK7u-dev. Mike From joel.franck at oracle.com Wed Mar 6 17:40:50 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Wed, 06 Mar 2013 17:40:50 +0000 Subject: hg: jdk8/tl/jdk: 8007808: Missing method: Executable.getAnnotatedReturnType() Message-ID: <20130306174104.E4845478A9@hg.openjdk.java.net> Changeset: 38e1821c4472 Author: jfranck Date: 2013-03-06 18:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/38e1821c4472 8007808: Missing method: Executable.getAnnotatedReturnType() Reviewed-by: darcy, forax ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Method.java From joel.franck at oracle.com Wed Mar 6 17:45:00 2013 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Wed, 6 Mar 2013 18:45:00 +0100 Subject: RFR: 8007808: Missing method: Executable.getAnnotatedReturnType() In-Reply-To: <51376B9F.6080800@univ-mlv.fr> References: <51375499.2070500@oracle.com> <51376232.4050904@oracle.com> <51376B9F.6080800@univ-mlv.fr> Message-ID: <73F5FE94-F4BE-4FA3-8C4A-CA539B595D6D@oracle.com> Thanks for the reviews Joe and Remi cheers /Joel On 6 mar 2013, at 17:15, Remi Forax wrote: > Hi Joel, > looks good for me too :) > > R?mi > > On 03/06/2013 04:35 PM, Joe Darcy wrote: >> Hi Joel, >> >> Look good; approved. >> >> -Joe >> >> On 3/6/2013 6:37 AM, Joel Borggr?n-Franck wrote: >>> Hi, >>> >>> Can I get a review of this small fix for issue 8007808: Missing method: Executable.getAnnotatedReturnType() >>> >>> http://cr.openjdk.java.net/~jfranck/8007808/webrev.00/ >>> >>> When we added Core Reflection support for type annotations this method got left out on Executable, but were included on Method and Constructor. >>> >>> For Oracle reviewers, CCC is approved. >>> >>> cheers >>> /Joel >> > From mike.duigou at oracle.com Wed Mar 6 17:50:16 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 6 Mar 2013 09:50:16 -0800 Subject: Request for review- RFE 8005716 In-Reply-To: <51367A43.1060606@oracle.com> References: <51367A43.1060606@oracle.com> Message-ID: <6B264182-3ECA-46BC-94E8-9A2A02AAA6F3@oracle.com> Hi Bill; Some notes from reviewing the JDK side changes. System.java/Runtime.java: The example which begins with the name "If the filename argument, " needs to better identify that "L" is an example. (Italics?) java/lang/ClassLoader.java: NativeLibrary::fromClass could be final. ClassLoader.c: In Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib() These two values are known at compile time. int prefixLen = (int) strlen(JNI_LIB_PREFIX); int suffixLen = (int) strlen(JNI_LIB_SUFFIX); Some of the error conditions don't throw exceptions. Such as: if (cname == NULL) { return NULL; } The prefix and suffix are stripped from cname without checking that cname actually contains the prefix or suffix. if (len > prefixLen) is invariant. src/solaris/native/common/jni_util_md.c: void* getProcessHandle() { static void* procHandle = NULL; if (procHandle == NULL) { procHandle = (void*)dlopen(NULL, RTLD_LAZY); } return procHandle; } Why is the error handling code commented out? Mike On Mar 5 2013, at 15:05 , bill.pittore at oracle.com wrote: > This request is tied to bugid 8005716 that deals with adding support for statically linked JNI libraries. > > The JEP is here: http://openjdk.java.net/jeps/178 > > The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716 > > The webrevs are here: > > http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.00/ > http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ > > The main piece of functionality is to check for the presence of JNI_OnLoad_libname to determine if the library specified by 'libname' has been statically linked into the VM. If the symbol is found, it is assumed that the library is linked in and will not be dynamically loaded. > > thanks, > bill From mike.duigou at oracle.com Wed Mar 6 17:56:12 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 6 Mar 2013 09:56:12 -0800 Subject: Request for review- RFE 8005716 In-Reply-To: <03D91B6F-800F-4DA0-852C-6FC2D5AF06F1@oracle.com> References: <51367A43.1060606@oracle.com> <51368F88.8000309@oracle.com> <03D91B6F-800F-4DA0-852C-6FC2D5AF06F1@oracle.com> Message-ID: <024FE42F-C0CB-4C01-9D3B-052B693AF80D@oracle.com> On Mar 6 2013, at 08:21 , Bob Vandette wrote: > For a traditional > JRE that doesn't even require static library support, we'd have to make sure to run on a VM that > support JNI_VERSION_1_8. It looks like the JDK maintains their own copy of jni.h. In earlier days the jni.h file was copied from hotspot into jdk during the compilation process. The current build process doesn't validate that the two files match which opens up opportunities for inconsistencies and problems. > If they didn't > do that, we would have already gone down that path. If it's possible to improve upon having two jni.h instances then we should consider doing so. Mike From mandy.chung at oracle.com Wed Mar 6 17:58:07 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 06 Mar 2013 09:58:07 -0800 Subject: RFR: 8002070 Remove the stack search for a resource bundle for Logger to use In-Reply-To: <51362879.5010004@oracle.com> References: <51311CC4.5000106@oracle.com> <51313053.2080605@oracle.com> <51362879.5010004@oracle.com> Message-ID: <513783AF.1090101@oracle.com> On 3/5/2013 9:16 AM, Jim Gish wrote: > > On 03/01/2013 05:48 PM, Mandy Chung wrote: >> On 3/1/2013 1:25 PM, Jim Gish wrote: >>> Please review >>> http://cr.openjdk.java.net/~jgish/Bug8002070-RemoveResourceBundleStackSearch/ >>> >>> This removes the stack search from Logger.findResourceBundle() >>> >> >> It's good to see this stack walk search of resource bundle going away. >> >> In Logger.java, the existing implementation returns the previous >> cached resource bundle if it fails to find one matching the current >> locale but the name matches: >> >> 1608 if (name.equals(catalogName)) { >> 1609 // Return the previous cached value for that name. >> 1610 // This may be null. >> 1611 return catalog; >> 1612 } >> >> >> Your fix removes these lines which I think is fine. The >> Logger.getResourceBundle method specifies to return the resource >> bundle for this logger for the current default locale. I think it'd >> be rare to change the default locale during the execution of an >> application. > The old behavior upon reaching this point in the code was as follows: > To get here, the sought after bundle was not found and (from the > checks on line 1559,1560), either > (1) the previously cached catalog was null, meaning nothing was yet > cached and so null was returned, or correct. > (2) the current locale had changed and no bundle for that locale was > found, in which case the cached bundle (for the old/wrong locale) was > returned, or do you mean it returns the cached bundle only if the name matches? or am I missing the code that you read? > (3) the name was the same but the location of the objects used to > compare the cached name with that passed in was different, Can you elaborate? Are you referring the "if (name.equals(catalogName))" statement? > so the previously cached bundle was returned (this is frankly an odd > case, because it also means that re-searching for a previously found > bundle is now failing, which only seems possible if the bundle is/was > (a) not available via the system classloader, (b) the context > classloader, or (c), the classloaders up the call chain. > > The new behavior /does /still allow for a change in the default > locale. For example, if you first call findResourceBundleName("foo") > and the default locale is US, it will search for the foo_US bundle and > set catalogLocale=US, and catalogName=foo and return the foo_US > bundle. If you then search for "foo" and have changed the default > locale to DE (if that is indeed a valid locale), it will then search > for foo_DE and if found set catalogLocale=DE and cache and return the > foo_DE bundle. The /only /change in behavior that I see here, is > that if you change the locale and the bundle is not found, null will > be returned instead of the previously cached bundle (if one exists), > for a /different/ locale. > Right. The behavioral difference that I point out was when foo_DE is cached, later the current locale is set to JP where foo_JP and foo don't exist, the old behavior returns foo_DE which was a bug too me whereas the new behavior returns null which matches the spec of Logger.getResourceBundle(). > So, the old behavior in effect had a notion of a default catalog, but > only if you happened to find a bundle on a previous lookup and cache > it. However, you wouldn't be guaranteed of acquiring this same bundle > on a subsequent search if a search for a different name had intervened. > > Thus, the new behavior is that if you search for a name/locale and > it's not found, you will get null (every time). This seems better to > me because it's consistent, explainable and simple. > This matches what Logger.getResourceBundle() is specified and the behavior is correct. The difference in behavior is a minimal compatibility risk. Comments on the updated webrev: > http://cr.openjdk.java.net/~jgish/Bug8002070-RemoveResourceBundleStackSearch/ L122-125: you may want to replace .... with {@code .... } L129-130: you can use @linkplain instead: {@linkplain ClassLoader#getSystemClassLoader()system ClassLoader} L141-142: "the bundle associated with the Logger object itself cannot be changed" - is this statement correct? The cached catalog object is not accessed directly; instead when it finds the resource bundle every time it logs a message. In addition the new paragraph L132-142 doesn't seem to be necessary since the spec is pretty clear on using the resource bundle of the current locale. L1575: the @link here is not necessary in a comment LoggerResourceBundleRace.java: I think what you really want is to add a new test that sets a context class loader to a class loader that finds the resource bundle for a logger that a system class loader can't find. I suggest to leave this test as it is and then add a new test to exercise the context class loader search of a resource bundle as a separate RFE that will improve the test coverage. Mandy > I'd appreciate you verifying this. > > Thanks, > > Jim >> >> I suggest to document this behavioral change as well in the bug >> report and CCC. >> >> Thanks >> Mandy > > -- > Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 > Oracle Java Platform Group | Core Libraries Team > 35 Network Drive > Burlington, MA 01803 > jim.gish at oracle.com From jason.uh at oracle.com Fri Mar 1 00:37:54 2013 From: jason.uh at oracle.com (jason.uh at oracle.com) Date: Fri, 01 Mar 2013 00:37:54 +0000 Subject: hg: jdk8/tl/jdk: 8006853: OCSP timeout set to wrong value if com.sun.security.ocsp.timeout < 0 Message-ID: <20130301003818.CFA9E474D9@hg.openjdk.java.net> Changeset: 7246a6e4dd5a Author: juh Date: 2013-02-28 16:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7246a6e4dd5a 8006853: OCSP timeout set to wrong value if com.sun.security.ocsp.timeout < 0 Reviewed-by: mullan ! src/share/classes/sun/security/provider/certpath/OCSP.java From uschindler at apache.org Sat Mar 2 22:34:30 2013 From: uschindler at apache.org (Uwe Schindler) Date: Sat, 2 Mar 2013 23:34:30 +0100 Subject: JDK 8 RFR: 8009267: Restore isAnnotationPresent methods in public AnnotatedElement implementations In-Reply-To: <51315E97.6010406@oracle.com> References: <51315E97.6010406@oracle.com> Message-ID: <016701ce1796$1bcfa790$536ef6b0$@apache.org> Looks good to me! Are this the only methods in the corelib that were removed in favour of a default implementation in the interface? Uwe ----- Uwe Schindler uschindler at apache.org Apache Lucene PMC Member / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: Joe Darcy [mailto:joe.darcy at oracle.com] > Sent: Saturday, March 02, 2013 3:06 AM > To: Core-Libs-Dev > Cc: Jonathan Gibbons; Alexander Buckley; Maurizio Cimadamore; > uschindler at apache.org > Subject: JDK 8 RFR: 8009267: Restore isAnnotationPresent methods in public > AnnotatedElement implementations > > Hello, > > The changes pushed under > > 8007113: Upgrade AnnotatedElement.isAnnotionPresent to be a default > method > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e04467fa13af > > combined with how javac currently models default methods under pre-JDK-8 > source versions can result in some source compatibility impacts for those > using JDK 8 to compile under older source versions if the recommended > practice of setting the bootclasspath is not followed. [1] > > To mitigate these impacts, I'm proposing the changes in > > 8009267: Restore isAnnotationPresent methods in public > AnnotatedElement implementations > http://cr.openjdk.java.net/~darcy/8009267.1/ > > which have the effect of restoring a concrete isAnnotationPresent method > to Class, Package, Field, Method, and Constructor. The implementation > delegates to the default method on the AnnotatedElement interface. > > Thanks, > > -Joe > > [1] > http://mail.openjdk.java.net/pipermail/compiler-dev/2013- > February/005738.html From uschindler at apache.org Mon Mar 4 16:45:11 2013 From: uschindler at apache.org (Uwe Schindler) Date: Mon, 4 Mar 2013 17:45:11 +0100 Subject: JDK 8 RFR: 8009267: Restore isAnnotationPresent methods in public AnnotatedElement implementations In-Reply-To: <5134C8BF.3020702@oracle.com> References: <51315E97.6010406@oracle.com> <016701ce1796$1bcfa790$536ef6b0$@apache.org> <5134C8BF.3020702@oracle.com> Message-ID: <000701ce18f7$a3c9c060$eb5d4120$@apache.org> My intention was to say "implementation removed". Uwe ----- Uwe Schindler uschindler at apache.org Apache Lucene PMC Member / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: Joe Darcy [mailto:joe.darcy at oracle.com] > Sent: Monday, March 04, 2013 5:16 PM > To: Uwe Schindler > Cc: 'Core-Libs-Dev'; 'Jonathan Gibbons'; 'Alexander Buckley'; 'Maurizio > Cimadamore' > Subject: Re: JDK 8 RFR: 8009267: Restore isAnnotationPresent methods in > public AnnotatedElement implementations > > On 03/02/2013 02:34 PM, Uwe Schindler wrote: > > Looks good to me! > > Are this the only methods in the corelib that were removed in favour of a > default implementation in the interface? > > I would not described the method as "removed," but to my knowledge > AnnotatedElement.isAnnotationPresent was the only existing interface > method in the core libraries replaced by a default method. The intended use > case for default methods is adding new methods to interface and that > change has certainly been done in other parts of the API. > > Cheers, > > -Joe > > > > > Uwe > > > > ----- > > Uwe Schindler > > uschindler at apache.org > > Apache Lucene PMC Member / Committer > > Bremen, Germany > > http://lucene.apache.org/ > > > >> -----Original Message----- > >> From: Joe Darcy [mailto:joe.darcy at oracle.com] > >> Sent: Saturday, March 02, 2013 3:06 AM > >> To: Core-Libs-Dev > >> Cc: Jonathan Gibbons; Alexander Buckley; Maurizio Cimadamore; > >> uschindler at apache.org > >> Subject: JDK 8 RFR: 8009267: Restore isAnnotationPresent methods in > >> public AnnotatedElement implementations > >> > >> Hello, > >> > >> The changes pushed under > >> > >> 8007113: Upgrade AnnotatedElement.isAnnotionPresent to be a > >> default method > >> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e04467fa13af > >> > >> combined with how javac currently models default methods under > >> pre-JDK-8 source versions can result in some source compatibility > >> impacts for those using JDK 8 to compile under older source versions > >> if the recommended practice of setting the bootclasspath is not > >> followed. [1] > >> > >> To mitigate these impacts, I'm proposing the changes in > >> > >> 8009267: Restore isAnnotationPresent methods in public > >> AnnotatedElement implementations > >> http://cr.openjdk.java.net/~darcy/8009267.1/ > >> > >> which have the effect of restoring a concrete isAnnotationPresent > >> method to Class, Package, Field, Method, and Constructor. The > >> implementation delegates to the default method on the > AnnotatedElement interface. > >> > >> Thanks, > >> > >> -Joe > >> > >> [1] > >> http://mail.openjdk.java.net/pipermail/compiler-dev/2013- > >> February/005738.html From michael.hixson at gmail.com Wed Mar 6 10:31:42 2013 From: michael.hixson at gmail.com (Michael Hixson) Date: Wed, 6 Mar 2013 02:31:42 -0800 Subject: CFR - updated 8001667: Comparator combinators and extension methods In-Reply-To: <51364B80.6030801@oracle.com> References: <51364B80.6030801@oracle.com> Message-ID: Hello, I'm not one of the people that you're looking at to review this, but I have to give this feedback anyway. I tried to give similar feedback on another mailing list and got no response (maybe I chose the wrong list). These changes have been bothering me. :) 1. Why disable the following code even though it is (theoretically) safe? Comparator a = comparing(CharSequence::length); Comparator b = a.thenComparing(CASE_INSENSITIVE_ORDER); That code would compile if the signatures of the thenComparing methods had generics like instead of . The example above is conjured up and ridiculous, but I think real code will have use for it. Is there any downside to narrowing the return type this way? 2. There's a thenComparing(Function), but no thenComparing(Function, Comparator). This seems like a big omission. Surely people will want secondary orderings on fields by something other than natural (null-unfriendly) ordering. Also, a Comparators.comparing(Function, Comparator) method would remove the need for all the Map-centric methods that are currently in the Comparators class. For instance: comparing(Map.Entry::getValue, naturalOrder()). 3. There is no support for sorting of nullable values or fields. Sorting of nullable values directly perhaps should not be encouraged, but sorting values by nullable fields within a chained sort is completely reasonable. Please add some support for this, either as chain methods on Comparator, or as factory methods on Comparators. 4. If Comparator had min(a,b) and max(a,b) methods, the Comparators.lesserOf(c) and greaterOf(c) methods would be unnecessary. The min/max methods would be generally more useful than the BinaryOperators returned from Comparators, and c::min reads better than Comparators.lesserOf(c). 5. Comparators.reverseOrder(c) is confusing in that it has different behavior than Collections.reverseOrder(c). It throws an NPE. Also, this new method seems to be useless because one could call c.reverseOrder() instead. I suggest removing the method. 6. I don't see why Comparators.compose(c1,c2) is useful given that users can call c1.thenComparing(c2). The latter reads better; the word "compose" does not naturally fit with comparators and has strange connotations for those with Math backgrounds. 7. Last I checked, even this simple example did not compile: Comparator c = comparing(String::length); It was confused about whether I was implying a ToDoubleFunction or a ToLongFunction, which were both wrong. I also ran into a lot of type inference loop problems when chaining. Is this simply a problem with lambda evaluation that's going to be fixed before Java 8 is officially released? Is there something more complex going on here that makes statements like this impossible? If the compilation problems aren't going to be fixed prior to the release, or if they cannot be fixed, then none of these Comparator/Comparators additions are useful. You would be better off removing them. -Michael On Tue, Mar 5, 2013 at 11:46 AM, Henry Jen wrote: > Hi, > > Another update to reflect functional interface renames involved in the > API, and a bug fix for a regression found earlier. > > CCC had been approved. Can we get it reviewed and pushed? > > [1] http://cr.openjdk.java.net/~henryjen/ccc/8001667.4/webrev > > Cheers, > Henry > From jed.wesleysmith at gmail.com Wed Mar 6 10:54:01 2013 From: jed.wesleysmith at gmail.com (Jed Wesley-Smith) Date: Wed, 6 Mar 2013 21:54:01 +1100 Subject: RFR : JDK-8001642 : Add Optional, OptionalDouble, OptionalInt, OptionalLong In-Reply-To: <513710CC.3010903@univ-mlv.fr> References: <513710CC.3010903@univ-mlv.fr> Message-ID: Really, this is a lot of fuss over nothing. There is actually no fundamental difference between Scala's Option, Guava's Optional, Fugue's Option, Java's Optional and Haskell's Maybe ? they are modelling the same thing, the possibility of a value not being present. The fact that there may be minor differences in api or semantics around whether null is a legal value are minor in the scheme of things (and yes, null is a pretty stupid legal value of a Some IMHO). Stephen's example is ludicrous, why have a list of optional values? You'd flatten down into just a list ? and an optional list only makes sense if the enclosed list is guaranteed to be non-empty, otherwise you just return an empty list! If we are going to use potential straw-men as arguments we can stall all progress. Please concentrate on the important matters, let's disavow null as a valid value and save us all a billion dollars. cheers, jed. On 06/03/2013, at 8:47 PM, Remi Forax wrote: > Ok, let be nuclear on this, > There is no good reason to introduce Optional in java.util. > > It doen't work like Google's Guava Optional despite having the same > name, it doesn't work like Scala's Option despite having a similar name, > moreover the lambda pipeline face a similar issue with the design of > collectors (see stream.collect()) but solve that similar problem with a > different design, so the design of Optional is not even consistent with > the rest of the stream API. > > So why do we want something like Optional, we want it to be able to > represent the fact that as Mike states a returning result can have no > value by example Colections.emptyList().stream().findFirst() should > 'return' no value. > > As Stephen Colebourne said, Optional is a bad name because Scala uses > Option [1] which can used in the same context, as result of a filter/map > etc. but Option in Scala is a way to mask null. Given the name > proximity, people will start to use Optional like Option in Scala and we > will see methods returning things like Optional>>. > > Google's Guava, which is a popular library, defines a class named > Optional, but allow to store null unlike the current proposed > implementation, this will generate a lot of confusions and frustrations. > > In fact, we don't need Optional at all, because we don't need to return > a value that can represent a value or no value, > the idea is that methods like findFirst should take a lambda as > parameter letting the user to decide what value should be returned by > findFirst if there is a value and if there is no value. > So instead of > stream.findFirst().orElse(null) > you will write > stream.findFirst(orNull) > with orNull() defined as like that > public static Optionalizer orNull() { > return (isPresent, element) -> isPresent? element: null; > } > > The whole design is explained here [2] and is similar to the way > Collectors are defined [3], > it's basically the lambda way of thinking, instead of creating an object > representing the different states resulting of a call to findFirst, > findFirst takes a lambda as parameter which is fed with the states of a > call. > > cheers, > R?mi > > [1] http://www.scala-lang.org/api/current/index.html#scala.Option > [2] > http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2013-February/001470.html > [3] > http://hg.openjdk.java.net/lambda/lambda/jdk/file/tip/src/share/classes/java/util/stream/Collectors.java > > > On 03/04/2013 09:29 PM, Mike Duigou wrote: >> Hello All; >> >> This patch introduces Optional container objects to be used by the lambda streams libraries for returning results. >> >> The reference Optional type, as defined, intentionally does not allow null values. null may be used with the Optional.orElse() method. >> >> All of the Optional types define hashCode() and equals implementations. Use of Optional types in collections should be generally discouraged but having useful equals() and hashCode() is ever so convenient. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8001642/0/webrev/ >> >> Mike >> > > From ali.ebrahimi1781 at gmail.com Wed Mar 6 11:28:13 2013 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Wed, 6 Mar 2013 15:58:13 +0430 Subject: CFR - updated 8001667: Comparator combinators and extension methods In-Reply-To: <51364B80.6030801@oracle.com> References: <51364B80.6030801@oracle.com> Message-ID: Hi, just one suggestion: rename comparing with compareWith 1) public static > Comparator compareWith(Function keyExtractor) { 2) default Comparator thenCompareWith(Comparator other) Best Regards, Ali Ebrahimi On Wed, Mar 6, 2013 at 12:16 AM, Henry Jen wrote: > Hi, > > Another update to reflect functional interface renames involved in the > API, and a bug fix for a regression found earlier. > > CCC had been approved. Can we get it reviewed and pushed? > > [1] http://cr.openjdk.java.net/~henryjen/ccc/8001667.4/webrev > > Cheers, > Henry > > From jack at moxley.co.uk Wed Mar 6 12:19:20 2013 From: jack at moxley.co.uk (Jack Moxley) Date: Wed, 06 Mar 2013 12:19:20 +0000 Subject: =?iso-8859-1?Q?Re=3A_RFR_=3A_JDK-8001642_=3A_Add_Optional=3CT=3E?= =?iso-8859-1?Q?=2C_OptionalDouble=2C_OptionalInt=2C_=09OptionalLon?= =?iso-8859-1?Q?g?= In-Reply-To: <51372F73.70004@univ-mlv.fr> Message-ID: <20130306121920.e0c5c9b9@mailgate.office.moxley.co.uk> Whatever happened to the elvis operator solution from project coin, surely that solves the majority of issues Optional was meant to solve anyway, without the headache of type-mix mud clutering up the code. http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000047.html _____ From: Remi Forax [mailto:forax at univ-mlv.fr] To: Jed Wesley-Smith [mailto:jed.wesleysmith at gmail.com] Cc: lambda-libs-spec-experts at openjdk.java.net [mailto:lambda-libs-spec-experts at openjdk.java.net], lambda-dev at openjdk.java.net [mailto:lambda-dev at openjdk.java.net], core-libs-dev at openjdk.java.net [mailto:core-libs-dev at openjdk.java.net] Sent: Wed, 06 Mar 2013 11:58:43 +0000 Subject: Re: RFR : JDK-8001642 : Add Optional, OptionalDouble, OptionalInt, OptionalLong On 03/06/2013 11:54 AM, Jed Wesley-Smith wrote: > Really, this is a lot of fuss over nothing. > > There is actually no fundamental difference between Scala's Option, Guava's Optional, Fugue's Option, Java's Optional and Haskell's Maybe ? they are modelling the same thing, the possibility of a value not being present. > > The fact that there may be minor differences in api or semantics around whether null is a legal value are minor in the scheme of things (and yes, null is a pretty stupid legal value of a Some IMHO). > > Stephen's example is ludicrous, why have a list of optional values? You'd flatten down into just a list ? and an optional list only makes sense if the enclosed list is guaranteed to be non-empty, otherwise you just return an empty list! People like shooting their own feet. http://cs.calstatela.edu/wiki/index.php/Courses/CS_460/Fall_2012/Week_8/gamePlay.combat.BattleAnalysis > > If we are going to use potential straw-men as arguments we can stall all progress. Please concentrate on the important matters, let's disavow null as a valid value and save us all a billion dollars Also Scala Option is not the only way to solve the null problem. The JSR308 annotation @Nullable/@NonNull are recognized by Eclipse and IntelliJ at least. > . > > cheers, > jed. cheers, R?mi > > On 06/03/2013, at 8:47 PM, Remi Forax wrote: > >> Ok, let be nuclear on this, >> There is no good reason to introduce Optional in java.util. >> >> It doen't work like Google's Guava Optional despite having the same >> name, it doesn't work like Scala's Option despite having a similar name, >> moreover the lambda pipeline face a similar issue with the design of >> collectors (see stream.collect()) but solve that similar problem with a >> different design, so the design of Optional is not even consistent with >> the rest of the stream API. >> >> So why do we want something like Optional, we want it to be able to >> represent the fact that as Mike states a returning result can have no >> value by example Colections.emptyList().stream().findFirst() should >> 'return' no value. >> >> As Stephen Colebourne said, Optional is a bad name because Scala uses >> Option [1] which can used in the same context, as result of a filter/map >> etc. but Option in Scala is a way to mask null. Given the name >> proximity, people will start to use Optional like Option in Scala and we >> will see methods returning things like Optional>>. >> >> Google's Guava, which is a popular library, defines a class named >> Optional, but allow to store null unlike the current proposed >> implementation, this will generate a lot of confusions and frustrations. >> >> In fact, we don't need Optional at all, because we don't need to return >> a value that can represent a value or no value, >> the idea is that methods like findFirst should take a lambda as >> parameter letting the user to decide what value should be returned by >> findFirst if there is a value and if there is no value. >> So instead of >> stream.findFirst().orElse(null) >> you will write >> stream.findFirst(orNull) >> with orNull() defined as like that >> public static Optionalizer orNull() { >> return (isPresent, element) -> isPresent? element: null; >> } >> >> The whole design is explained here [2] and is similar to the way >> Collectors are defined [3], >> it's basically the lambda way of thinking, instead of creating an object >> representing the different states resulting of a call to findFirst, >> findFirst takes a lambda as parameter which is fed with the states of a >> call. >> >> cheers, >> R?mi >> >> [1] http://www.scala-lang.org/api/current/index.html#scala.Option >> [2] >> http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2013-February/001470.html >> [3] >> http://hg.openjdk.java.net/lambda/lambda/jdk/file/tip/src/share/classes/java/util/stream/Collectors.java >> >> >> On 03/04/2013 09:29 PM, Mike Duigou wrote: >>> Hello All; >>> >>> This patch introduces Optional container objects to be used by the lambda streams libraries for returning results. >>> >>> The reference Optional type, as defined, intentionally does not allow null values. null may be used with the Optional.orElse() method. >>> >>> All of the Optional types define hashCode() and equals implementations. Use of Optional types in collections should be generally discouraged but having useful equals() and hashCode() is ever so convenient. >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-8001642/0/webrev/ >>> >>> Mike >>> >> From jed.wesleysmith at gmail.com Wed Mar 6 12:29:52 2013 From: jed.wesleysmith at gmail.com (Jed Wesley-Smith) Date: Wed, 6 Mar 2013 23:29:52 +1100 Subject: RFR : JDK-8001642 : Add Optional, OptionalDouble, OptionalInt, OptionalLong In-Reply-To: <51372F73.70004@univ-mlv.fr> References: <513710CC.3010903@univ-mlv.fr> <51372F73.70004@univ-mlv.fr> Message-ID: <62DC0C9F-6C5A-4AB5-95B7-01E343D11C5B@gmail.com> There is no need for an Option container to show how nested collections may be misused, you could just as easily show an example of a List>> that is isomorphic to a flattened Iterable . I'd simply point to the utility of the monadic bind or flatMap function! There are several reasons why Option types provide serious usability improvements over null, notwithstanding annotation support. The first is that the type-system prevents misuse (modulo unsafe API), and the second is that it allows operations that produce optional results to be sequenced easily without if checks. For mor information see previous posts on Optional forming a Monad. cheers, jed. On 06/03/2013, at 10:58 PM, Remi Forax wrote: > On 03/06/2013 11:54 AM, Jed Wesley-Smith wrote: >> Really, this is a lot of fuss over nothing. >> >> There is actually no fundamental difference between Scala's Option, Guava's Optional, Fugue's Option, Java's Optional and Haskell's Maybe ? they are modelling the same thing, the possibility of a value not being present. >> >> The fact that there may be minor differences in api or semantics around whether null is a legal value are minor in the scheme of things (and yes, null is a pretty stupid legal value of a Some IMHO). >> >> Stephen's example is ludicrous, why have a list of optional values? You'd flatten down into just a list ? and an optional list only makes sense if the enclosed list is guaranteed to be non-empty, otherwise you just return an empty list! > > People like shooting their own feet. > http://cs.calstatela.edu/wiki/index.php/Courses/CS_460/Fall_2012/Week_8/gamePlay.combat.BattleAnalysis > >> >> If we are going to use potential straw-men as arguments we can stall all progress. Please concentrate on the important matters, let's disavow null as a valid value and save us all a billion dollars > > Also Scala Option is not the only way to solve the null problem. > The JSR308 annotation @Nullable/@NonNull are recognized by Eclipse and IntelliJ at least. > >> . >> >> cheers, >> jed. > > cheers, > R?mi > >> >> On 06/03/2013, at 8:47 PM, Remi Forax wrote: >> >>> Ok, let be nuclear on this, >>> There is no good reason to introduce Optional in java.util. >>> >>> It doen't work like Google's Guava Optional despite having the same >>> name, it doesn't work like Scala's Option despite having a similar name, >>> moreover the lambda pipeline face a similar issue with the design of >>> collectors (see stream.collect()) but solve that similar problem with a >>> different design, so the design of Optional is not even consistent with >>> the rest of the stream API. >>> >>> So why do we want something like Optional, we want it to be able to >>> represent the fact that as Mike states a returning result can have no >>> value by example Colections.emptyList().stream().findFirst() should >>> 'return' no value. >>> >>> As Stephen Colebourne said, Optional is a bad name because Scala uses >>> Option [1] which can used in the same context, as result of a filter/map >>> etc. but Option in Scala is a way to mask null. Given the name >>> proximity, people will start to use Optional like Option in Scala and we >>> will see methods returning things like Optional>>. >>> >>> Google's Guava, which is a popular library, defines a class named >>> Optional, but allow to store null unlike the current proposed >>> implementation, this will generate a lot of confusions and frustrations. >>> >>> In fact, we don't need Optional at all, because we don't need to return >>> a value that can represent a value or no value, >>> the idea is that methods like findFirst should take a lambda as >>> parameter letting the user to decide what value should be returned by >>> findFirst if there is a value and if there is no value. >>> So instead of >>> stream.findFirst().orElse(null) >>> you will write >>> stream.findFirst(orNull) >>> with orNull() defined as like that >>> public static Optionalizer orNull() { >>> return (isPresent, element) -> isPresent? element: null; >>> } >>> >>> The whole design is explained here [2] and is similar to the way >>> Collectors are defined [3], >>> it's basically the lambda way of thinking, instead of creating an object >>> representing the different states resulting of a call to findFirst, >>> findFirst takes a lambda as parameter which is fed with the states of a >>> call. >>> >>> cheers, >>> R?mi >>> >>> [1] http://www.scala-lang.org/api/current/index.html#scala.Option >>> [2] >>> http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2013-February/001470.html >>> [3] >>> http://hg.openjdk.java.net/lambda/lambda/jdk/file/tip/src/share/classes/java/util/stream/Collectors.java >>> >>> >>> On 03/04/2013 09:29 PM, Mike Duigou wrote: >>>> Hello All; >>>> >>>> This patch introduces Optional container objects to be used by the lambda streams libraries for returning results. >>>> >>>> The reference Optional type, as defined, intentionally does not allow null values. null may be used with the Optional.orElse() method. >>>> >>>> All of the Optional types define hashCode() and equals implementations. Use of Optional types in collections should be generally discouraged but having useful equals() and hashCode() is ever so convenient. >>>> >>>> http://cr.openjdk.java.net/~mduigou/JDK-8001642/0/webrev/ >>>> >>>> Mike >>>> >>> > From dean.long at oracle.com Wed Mar 6 00:36:24 2013 From: dean.long at oracle.com (Dean Long) Date: Tue, 05 Mar 2013 16:36:24 -0800 Subject: Request for review- RFE 8005716 In-Reply-To: <51367A43.1060606@oracle.com> References: <51367A43.1060606@oracle.com> Message-ID: <51368F88.8000309@oracle.com> If JNI_ONLOAD_SYMBOLS contains something like "_JNI_OnLoad at 8" on Windows, you can't just turn that into "_JNI_OnLoad at 8_" + . I think it needs to be "_JNI_OnLoad_" + + "@8" Looks like onLoadSymbols[] is unused in Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib(). Instead of adding getProcessHandle(), why not add JVM_FindBuiltinLibraryEntry() instead? This would make it easier to support table-lookup when runtime symbol information is missing or not supported by the platform. dl On 3/5/2013 3:05 PM, bill.pittore at oracle.com wrote: > This request is tied to bugid 8005716 that deals with adding support > for statically linked JNI libraries. > > The JEP is here: http://openjdk.java.net/jeps/178 > > The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716 > > The webrevs are here: > > http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.00/ > http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ > > The main piece of functionality is to check for the presence of > JNI_OnLoad_libname to determine if the library specified by 'libname' > has been statically linked into the VM. If the symbol is found, it is > assumed that the library is linked in and will not be dynamically loaded. > > thanks, > bill From dean.long at oracle.com Wed Mar 6 05:54:06 2013 From: dean.long at oracle.com (Dean Long) Date: Tue, 05 Mar 2013 21:54:06 -0800 Subject: Request for review- RFE 8005716 In-Reply-To: <5136C26B.7000805@oracle.com> References: <51367A43.1060606@oracle.com> <51368F88.8000309@oracle.com> <5136C26B.7000805@oracle.com> Message-ID: <5136D9FE.5040009@oracle.com> On 3/5/2013 8:13 PM, BILL PITTORE wrote: > On 3/5/2013 7:36 PM, Dean Long wrote: >> If JNI_ONLOAD_SYMBOLS contains something like "_JNI_OnLoad at 8" on >> Windows, you can't just >> turn that into "_JNI_OnLoad at 8_" + . I think it needs to be >> "_JNI_OnLoad_" + + "@8" > I'll look into that. When I built for windows and ran our test, the > JNI_OnLoad_TestStaticLib was exported without the decoration just > based on the JNIEXPORT JNICALL specifiers on the function. I didn't do > anything special to export it. But I recall this problem from another > project. > 1 0 00001014 JNI_OnLoad_TestStaticLib = > @ILT+15(?JNI_OnLoad_TestStaticLib@@YGHPAUJavaVM_@@PAX at Z) >> >> Looks like onLoadSymbols[] is unused in >> Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib(). > I'll remove that. I redid the call to findBuiltinJniFunction but > forgot to remove that. > >> >> Instead of adding getProcessHandle(), why not add >> JVM_FindBuiltinLibraryEntry() instead? >> This would make it easier to support table-lookup when runtime symbol >> information is missing or not >> supported by the platform. > Not sure I'm following you on this. Make JVM_FindBuiltinLibraryEntry() > an exported function in the VM? How does it find JNI_OnLoad_L? For Windows and Linux, it would use basically your same code, just refactored a little. By the way, did you consider using the special RTLD_DEFAULT handle instead of dlopen(NULL)? > Via a table setup by the developer/build system when the library is > linked in? > Yes, in previous projects we did exactly that for more exotic OSes. dl > bill > >> >> dl >> >> On 3/5/2013 3:05 PM, bill.pittore at oracle.com wrote: >>> This request is tied to bugid 8005716 that deals with adding support >>> for statically linked JNI libraries. >>> >>> The JEP is here: http://openjdk.java.net/jeps/178 >>> >>> The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716 >>> >>> The webrevs are here: >>> >>> http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.00/ >>> http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ >>> >>> The main piece of functionality is to check for the presence of >>> JNI_OnLoad_libname to determine if the library specified by >>> 'libname' has been statically linked into the VM. If the symbol is >>> found, it is assumed that the library is linked in and will not be >>> dynamically loaded. >>> >>> thanks, >>> bill >> > From brian.burkhalter at oracle.com Wed Mar 6 18:55:51 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 6 Mar 2013 10:55:51 -0800 Subject: Review: 7032154 - Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal In-Reply-To: <3E47081F-1F08-4A61-8122-FB9209725232@oracle.com> References: <611D45A4-8B28-408E-8914-4BCEEB4F883D@oracle.com> <3E47081F-1F08-4A61-8122-FB9209725232@oracle.com> Message-ID: <5D88B1AB-F038-4000-884C-9CAD0BDB9D48@oracle.com> The link below has been updated with a few minor changes, notably to use constants from {Double,Float}Consts and to include the link to the OpenJDK issue report. A formatting issue resulting from an awk failure during webrev script execution was also fixed. B. On Feb 28, 2013, at 1:34 PM, Brian Burkhalter wrote: > I forgot that the attachment is not redistributed and that I can now post on cr.openjdk.java.net so here's the webrev: > > http://cr.openjdk.java.net/~bpb/7032154/ > > Begin forwarded message: > >> This concerns the issue http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7032154. >> >> The patch described in the issue has been updated to be with respect to the current JDK repository tip. The updated version is attached to this message. From staffan.larsen at oracle.com Wed Mar 6 19:36:00 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 6 Mar 2013 20:36:00 +0100 Subject: RFR(S): 8009397 test/com/sun/jdi/PrivateTransportTest.sh: ERROR: transport library missing onLoad entry: private_dt_socket In-Reply-To: <513646F9.3060601@oracle.com> References: <2A1F6D24-22FC-4CB4-84FD-05E8ECDDC9BF@oracle.com> <513646F9.3060601@oracle.com> Message-ID: Nice catch, Serguei! Unfortunately I have already pushed my change, but I filed "JDK-8009558: linked_md.c::dll_build_name can get stuck in an infinite loop" to track this new problem and I am working on a fix. Thanks, /Staffan On 5 mar 2013, at 20:26, serguei.spitsyn at oracle.com wrote: > Hi Staffan, > > Thank you for this discovery! > It looks good, but I have a couple of comments. > > It seems, there is one more problem in this code: > 68 /* check for NULL path */ > 69 if (p == pathname) { > 70 continue; <== Endless loop if we hit this line > 71 } > > Do we need to do 'pathname++' before continuing at the line #70? > It is going to be endless loop in cases there is a PATH_SEPARATOR > at the beginning of paths or two PATH_SEPARATOR's in a row. > These would be incorrect path lists but the code above is targeting exactly such cases. > > Also, the argument name "pathname" in the original code is confusing. > Should we rename it to "pathnames"? > > Thanks, > Serguei > > > On 3/4/13 10:56 AM, Staffan Larsen wrote: >> I accidentally stepped on this bug the other day. There is a problem in linker_md.c : dll_build_name() where an internal pointer can be moved to point outside the string. The code looks like: >> >> 57 static void dll_build_name(char* buffer, size_t buflen, >> 58 const char* pname, const char* fname) { >> 59 // Based on os_solaris.cpp >> 60 >> 61 char *path_sep = PATH_SEPARATOR; >> 62 char *pathname = (char *)pname; >> 63 while (strlen(pathname) > 0) { >> 64 char *p = strchr(pathname, *path_sep); >> 65 if (p == NULL) { >> 66 p = pathname + strlen(pathname); >> 67 } >> 68 /* check for NULL path */ >> 69 if (p == pathname) { >> 70 continue; >> 71 } >> 72 (void)snprintf(buffer, buflen, "%.*s/lib%s." LIB_SUFFIX, (p - pathname), >> 73 pathname, fname); >> 74 >> 75 if (access(buffer, F_OK) == 0) { >> 76 break; >> 77 } >> 78 pathname = p + 1; >> 79 *buffer = '\0'; >> 80 } >> >> If the supplied pname is a buffer with a simple path without any path separators in it, p will be set to the terminating nul on line 66. Then on line 78 it will be moved outside the buffer. Fixing this also necessitates fixes to the callers to check for an empty return string (in buffer). >> >> The same code show up in both the solaris code and the windows code as well as hprof. >> >> bug: http://bugs.sun.com/view_bug.do?bug_id=8009397 >> webrev: http://cr.openjdk.java.net/~sla/8009397/webrev.00/ >> >> Thanks, >> /Staffan > From jim.gish at oracle.com Wed Mar 6 19:42:34 2013 From: jim.gish at oracle.com (Jim Gish) Date: Wed, 06 Mar 2013 14:42:34 -0500 Subject: RFR: 8002070 Remove the stack search for a resource bundle for Logger to use In-Reply-To: <513783AF.1090101@oracle.com> References: <51311CC4.5000106@oracle.com> <51313053.2080605@oracle.com> <51362879.5010004@oracle.com> <513783AF.1090101@oracle.com> Message-ID: <51379C2A.7030604@oracle.com> On 03/06/2013 12:58 PM, Mandy Chung wrote: > > > On 3/5/2013 9:16 AM, Jim Gish wrote: >> >> On 03/01/2013 05:48 PM, Mandy Chung wrote: >>> On 3/1/2013 1:25 PM, Jim Gish wrote: >>>> Please review >>>> http://cr.openjdk.java.net/~jgish/Bug8002070-RemoveResourceBundleStackSearch/ >>>> >>>> This removes the stack search from Logger.findResourceBundle() >>>> >>> >>> It's good to see this stack walk search of resource bundle going away. >>> >>> In Logger.java, the existing implementation returns the previous >>> cached resource bundle if it fails to find one matching the current >>> locale but the name matches: >>> >>> 1608 if (name.equals(catalogName)) { >>> 1609 // Return the previous cached value for that name. >>> 1610 // This may be null. >>> 1611 return catalog; >>> 1612 } >>> >>> >>> Your fix removes these lines which I think is fine. The >>> Logger.getResourceBundle method specifies to return the resource >>> bundle for this logger for the current default locale. I think it'd >>> be rare to change the default locale during the execution of an >>> application. >> The old behavior upon reaching this point in the code was as follows: >> To get here, the sought after bundle was not found and (from the >> checks on line 1559,1560), either >> (1) the previously cached catalog was null, meaning nothing was yet >> cached and so null was returned, or > > correct. > >> (2) the current locale had changed and no bundle for that locale was >> found, in which case the cached bundle (for the old/wrong locale) was >> returned, or > > do you mean it returns the cached bundle only if the name matches? or > am I missing the code that you read? Yes. > >> (3) the name was the same but the location of the objects used to >> compare the cached name with that passed in was different, > > Can you elaborate? Are you referring the "if > (name.equals(catalogName))" statement? It used to be: "if (name == catalogName)" and now is "if (name.equals(catalogName))" Therefore if a different object was passed in for name than catalogName, that test would fail. However, even if name.equals(catalogName) was initially true in the old code it could proceed to do the search (possibly unnecessarily in the case where it would simply return the cached bundle anyway), but even if the search failed it would discover the String value of the name was equivalent to the String value of catalogName and then and only then return the cached catalog. Now, we simply check for matching String values at the beginning and return the cached catalog if the Locale hasn't changed. > >> so the previously cached bundle was returned (this is frankly an odd >> case, because it also means that re-searching for a previously found >> bundle is now failing, which only seems possible if the bundle is/was >> (a) not available via the system classloader, (b) the context >> classloader, or (c), the classloaders up the call chain. >> >> The new behavior /does /still allow for a change in the default >> locale. For example, if you first call findResourceBundleName("foo") >> and the default locale is US, it will search for the foo_US bundle >> and set catalogLocale=US, and catalogName=foo and return the foo_US >> bundle. If you then search for "foo" and have changed the default >> locale to DE (if that is indeed a valid locale), it will then search >> for foo_DE and if found set catalogLocale=DE and cache and return the >> foo_DE bundle. The /only /change in behavior that I see here, is >> that if you change the locale and the bundle is not found, null will >> be returned instead of the previously cached bundle (if one exists), >> for a /different/ locale. >> > > Right. The behavioral difference that I point out was when foo_DE is > cached, later the current locale is set to JP where foo_JP and foo > don't exist, the old behavior returns foo_DE which was a bug too me > whereas the new behavior returns null which matches the spec of > Logger.getResourceBundle(). > >> So, the old behavior in effect had a notion of a default catalog, but >> only if you happened to find a bundle on a previous lookup and cache >> it. However, you wouldn't be guaranteed of acquiring this same >> bundle on a subsequent search if a search for a different name had >> intervened. >> >> Thus, the new behavior is that if you search for a name/locale and >> it's not found, you will get null (every time). This seems better to >> me because it's consistent, explainable and simple. >> > > This matches what Logger.getResourceBundle() is specified and the > behavior is correct. The difference in behavior is a minimal > compatibility risk. > > Comments on the updated webrev: > >> http://cr.openjdk.java.net/~jgish/Bug8002070-RemoveResourceBundleStackSearch/ > > > L122-125: you may want to replace .... with {@code .... } I think we'll save that for a later day - and then update all the occurrences of to {@code} > L129-130: you can use @linkplain instead: > {@linkplain ClassLoader#getSystemClassLoader()system ClassLoader} All other existing links are using @link. Why should we use @linkplain here? > L141-142: "the bundle associated with the Logger object itself cannot > be changed" - is this statement correct? The cached catalog object is > not accessed directly; instead when it finds the resource bundle every > time it logs a message. I meant to say "cannot be /directly/ changed" I'll fix it. Thanks. > > In addition the new paragraph L132-142 doesn't seem to be necessary > since the spec is pretty clear on using the resource bundle of the > current locale. I'll take another look at that. > > L1575: the @link here is not necessary in a comment OK -- just trying to be complete and consistent with the previous references. > > LoggerResourceBundleRace.java: I think what you really want is to add > a new test that sets a context class loader to a class loader that > finds the resource bundle for a logger that a system class loader > can't find. I suggest to leave this test as it is and then add a new > test to exercise the context class loader search of a resource bundle > as a separate RFE that will improve the test coverage. Leaving the existing test as is not an option unless we change the test to run in othervm as I had on my first webrev. The bundles are not found otherwise. Hence the change to set the context classloader. > > Mandy > >> I'd appreciate you verifying this. >> >> Thanks, >> >> Jim >>> >>> I suggest to document this behavioral change as well in the bug >>> report and CCC. >>> >>> Thanks >>> Mandy >> >> -- >> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 >> Oracle Java Platform Group | Core Libraries Team >> 35 Network Drive >> Burlington, MA 01803 >> jim.gish at oracle.com -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From serguei.spitsyn at oracle.com Wed Mar 6 19:48:24 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 06 Mar 2013 11:48:24 -0800 Subject: RFR(S): 8009397 test/com/sun/jdi/PrivateTransportTest.sh: ERROR: transport library missing onLoad entry: private_dt_socket In-Reply-To: References: <2A1F6D24-22FC-4CB4-84FD-05E8ECDDC9BF@oracle.com> <513646F9.3060601@oracle.com> Message-ID: <51379D88.6080807@oracle.com> Staffan, Thank you for the confirmation and taking care about this issue! Thanks, Serguei On 3/6/13 11:36 AM, Staffan Larsen wrote: > Nice catch, Serguei! > > Unfortunately I have already pushed my change, but I filed > "JDK-8009558: linked_md.c::dll_build_name can get stuck in an infinite > loop" to track this new problem and I am working on a fix. > > Thanks, > /Staffan > > > On 5 mar 2013, at 20:26, serguei.spitsyn at oracle.com > wrote: > >> Hi Staffan, >> >> Thank you for this discovery! >> It looks good, but I have a couple of comments. >> >> It seems, there is one more problem in this code: >> 68 /* check for NULL path */ >> 69 if (p == pathname) { >> 70 continue;<== Endless loop if we hit this line >> 71 } >> >> Do we need to do 'pathname++' before continuing at the line #70? >> It is going to be endless loop in cases there is a PATH_SEPARATOR >> at the beginning of paths or two PATH_SEPARATOR's in a row. >> These would be incorrect path lists but the code above is targeting >> exactly such cases. >> >> Also, the argument name "pathname" in the original code is confusing. >> Should we rename it to "pathnames"? >> >> Thanks, >> Serguei >> >> >> On 3/4/13 10:56 AM, Staffan Larsen wrote: >>> I accidentally stepped on this bug the other day. There is a problem in linker_md.c : dll_build_name() where an internal pointer can be moved to point outside the string. The code looks like: >>> >>> 57 static void dll_build_name(char* buffer, size_t buflen, >>> 58 const char* pname, const char* fname) { >>> 59 // Based on os_solaris.cpp >>> 60 >>> 61 char *path_sep = PATH_SEPARATOR; >>> 62 char *pathname = (char *)pname; >>> 63 while (strlen(pathname) > 0) { >>> 64 char *p = strchr(pathname, *path_sep); >>> 65 if (p == NULL) { >>> 66 p = pathname + strlen(pathname); >>> 67 } >>> 68 /* check for NULL path */ >>> 69 if (p == pathname) { >>> 70 continue; >>> 71 } >>> 72 (void)snprintf(buffer, buflen, "%.*s/lib%s." LIB_SUFFIX, (p - pathname), >>> 73 pathname, fname); >>> 74 >>> 75 if (access(buffer, F_OK) == 0) { >>> 76 break; >>> 77 } >>> 78 pathname = p + 1; >>> 79 *buffer = '\0'; >>> 80 } >>> >>> If the supplied pname is a buffer with a simple path without any path separators in it, p will be set to the terminating nul on line 66. Then on line 78 it will be moved outside the buffer. Fixing this also necessitates fixes to the callers to check for an empty return string (in buffer). >>> >>> The same code show up in both the solaris code and the windows code as well as hprof. >>> >>> bug:http://bugs.sun.com/view_bug.do?bug_id=8009397 >>> webrev:http://cr.openjdk.java.net/~sla/8009397/webrev.00/ >>> >>> Thanks, >>> /Staffan >> > From henry.jen at oracle.com Wed Mar 6 19:52:55 2013 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 06 Mar 2013 11:52:55 -0800 Subject: CFR - updated 8001667: Comparator combinators and extension methods In-Reply-To: References: <51364B80.6030801@oracle.com> Message-ID: <51379E97.7060403@oracle.com> On 03/06/2013 03:28 AM, Ali Ebrahimi wrote: > Hi, > just one suggestion: > > rename comparing with compareWith > There was a round of discussion on naming. http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2012-November/000446.html I have my personal preference among proposals, but EG seems to have come to a consensus on this. I don't feel strongly between thenCompare, thenComparing or thenCompareWith. But we should be consistent between Comparators and Comparator, and consider that Comparators methods could be static interface method on Comparator in the future. Cheers, Henry > 1) > > public static > Comparator compareWith(Function keyExtractor) { > > > 2) > default Comparator thenCompareWith(Comparator other) > > > > Best Regards, > Ali Ebrahimi > On Wed, Mar 6, 2013 at 12:16 AM, Henry Jen > wrote: > > Hi, > > Another update to reflect functional interface renames involved in the > API, and a bug fix for a regression found earlier. > > CCC had been approved. Can we get it reviewed and pushed? > > [1] http://cr.openjdk.java.net/~henryjen/ccc/8001667.4/webrev > > Cheers, > Henry > > From bill.pittore at oracle.com Wed Mar 6 20:43:10 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Wed, 06 Mar 2013 15:43:10 -0500 Subject: Request for review- RFE 8005716 In-Reply-To: <5136C26B.7000805@oracle.com> References: <51367A43.1060606@oracle.com> <51368F88.8000309@oracle.com> <5136C26B.7000805@oracle.com> Message-ID: <5137AA5E.2070602@oracle.com> Actually for windows I *did* export the undecorated name. I just didn't see where I did it in the VS IDE. If you don't export the undecorated name it doesn't work of course. bill On 3/5/2013 11:13 PM, BILL PITTORE wrote: > On 3/5/2013 7:36 PM, Dean Long wrote: >> If JNI_ONLOAD_SYMBOLS contains something like "_JNI_OnLoad at 8" on >> Windows, you can't just >> turn that into "_JNI_OnLoad at 8_" + . I think it needs to be >> "_JNI_OnLoad_" + + "@8" > I'll look into that. When I built for windows and ran our test, the > JNI_OnLoad_TestStaticLib was exported without the decoration just > based on the JNIEXPORT JNICALL specifiers on the function. I didn't do > anything special to export it. But I recall this problem from another > project. > 1 0 00001014 JNI_OnLoad_TestStaticLib = > @ILT+15(?JNI_OnLoad_TestStaticLib@@YGHPAUJavaVM_@@PAX at Z) >> >> Looks like onLoadSymbols[] is unused in >> Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib(). > I'll remove that. I redid the call to findBuiltinJniFunction but > forgot to remove that. > >> >> Instead of adding getProcessHandle(), why not add >> JVM_FindBuiltinLibraryEntry() instead? >> This would make it easier to support table-lookup when runtime symbol >> information is missing or not >> supported by the platform. > Not sure I'm following you on this. Make JVM_FindBuiltinLibraryEntry() > an exported function in the VM? How does it find JNI_OnLoad_L? Via a > table setup by the developer/build system when the library is linked in? > > bill > >> >> dl >> >> On 3/5/2013 3:05 PM, bill.pittore at oracle.com wrote: >>> This request is tied to bugid 8005716 that deals with adding support >>> for statically linked JNI libraries. >>> >>> The JEP is here: http://openjdk.java.net/jeps/178 >>> >>> The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716 >>> >>> The webrevs are here: >>> >>> http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.00/ >>> http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ >>> >>> The main piece of functionality is to check for the presence of >>> JNI_OnLoad_libname to determine if the library specified by >>> 'libname' has been statically linked into the VM. If the symbol is >>> found, it is assumed that the library is linked in and will not be >>> dynamically loaded. >>> >>> thanks, >>> bill >> > From mandy.chung at oracle.com Wed Mar 6 20:42:47 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 06 Mar 2013 12:42:47 -0800 Subject: RFR: 8002070 Remove the stack search for a resource bundle for Logger to use In-Reply-To: <51379C2A.7030604@oracle.com> References: <51311CC4.5000106@oracle.com> <51313053.2080605@oracle.com> <51362879.5010004@oracle.com> <513783AF.1090101@oracle.com> <51379C2A.7030604@oracle.com> Message-ID: <5137AA47.9080003@oracle.com> On 3/6/2013 11:42 AM, Jim Gish wrote: >>> http://cr.openjdk.java.net/~jgish/Bug8002070-RemoveResourceBundleStackSearch/ >> >> >> L122-125: you may want to replace .... with {@code .... } > I think we'll save that for a later day - and then update all the > occurrences of to {@code} Fine with me. >> L129-130: you can use @linkplain instead: >> {@linkplain ClassLoader#getSystemClassLoader()system ClassLoader} > All other existing links are using @link. Why should we use > @linkplain here? The javadoc generated in your current change will show: system ClassLoader, ClassLoader.getSystemClassLoader(), If you use @linkplain, the javadoc will show: system ClassLoader >> >> LoggerResourceBundleRace.java: I think what you really want is to add >> a new test that sets a context class loader to a class loader that >> finds the resource bundle for a logger that a system class loader >> can't find. I suggest to leave this test as it is and then add a >> new test to exercise the context class loader search of a resource >> bundle as a separate RFE that will improve the test coverage. > Leaving the existing test as is not an option unless we change the > test to run in othervm as I had on my first webrev. The bundles are > not found otherwise. Hence the change to set the context classloader. I'm confused. Is the resource bundle "LoggerResourceBundleRace$MyResources" in the classpath as this test class is located? Should the system class loader be able to find them? This test shouldn't depend on the stack search. Shouldn't the thread context classloader be null and then use the system class loader? Is another test set the thread context classloader in the jtreg run? Does the test pass if you run it directly (not via jtreg)? Mandy From steven.loomis at oracle.com Wed Mar 6 20:44:14 2013 From: steven.loomis at oracle.com (Steven R. Loomis) Date: Wed, 06 Mar 2013 12:44:14 -0800 Subject: Java regex vs. Unicode TR#18 vs. ICU Message-ID: <5137AA9E.1030309@oracle.com> Hello, Someone on the ICU team recently compared the use of "\w" between ICU, Java, and Unicode TR#18 . The results are in the following ICU bug . A question for core-libs-dev is, does Java plan to change the semantics of \w to match TR#18's list? Thanks, Steven From henry.jen at oracle.com Wed Mar 6 21:01:01 2013 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 06 Mar 2013 13:01:01 -0800 Subject: CFR - updated 8001667: Comparator combinators and extension methods In-Reply-To: References: <51364B80.6030801@oracle.com> Message-ID: <5137AE8D.5050203@oracle.com> On 03/06/2013 02:31 AM, Michael Hixson wrote: > Hello, > > I'm not one of the people that you're looking at to review this, but I > have to give this feedback anyway. I tried to give similar feedback > on another mailing list and got no response (maybe I chose the wrong > list). These changes have been bothering me. :) > I find your earlier posts on lambda-libs-spec-comments archive. I was not on that list. > 1. Why disable the following code even though it is (theoretically) safe? > > Comparator a = comparing(CharSequence::length); > Comparator b = a.thenComparing(CASE_INSENSITIVE_ORDER); > > That code would compile if the signatures of the thenComparing methods > had generics like instead of . The example above is > conjured up and ridiculous, but I think real code will have use for > it. Is there any downside to narrowing the return type this way? > I think that make sense, will need to do some experiment to make sure it won't confuse type system when chaining all together, and I am not sure how much burden this has on inference engine. I prefer simplicity. Theoretically, if all function take Comparator carefully allows super type, which we have, isn't that enough? Your above example can be, Comparator a = comparing 2. There's a thenComparing(Function), but no thenComparing(Function, > Comparator). This seems like a big omission. Surely people will want > secondary orderings on fields by something other than natural > (null-unfriendly) ordering. Also, a Comparators.comparing(Function, > Comparator) method would remove the need for all the Map-centric > methods that are currently in the Comparators class. For instance: > comparing(Map.Entry::getValue, naturalOrder()). > Note that Function form must return a Comparable, which implies an order already. Combine with Comparator.reverseOrder() method, that would cover the ground. If the Comparable is not a fit, probably write a Comparator in lambda is needed anyway? > 3. There is no support for sorting of nullable values or fields. > Sorting of nullable values directly perhaps should not be encouraged, > but sorting values by nullable fields within a chained sort is > completely reasonable. Please add some support for this, either as > chain methods on Comparator, or as factory methods on Comparators. > Not sure what do you propose to be added. NULL is a controversial topic, only application know what it means. Therefore, avoid try to interpret null is probably a better approach. Write a Comparator if needed. > 4. If Comparator had min(a,b) and max(a,b) methods, the > Comparators.lesserOf(c) and greaterOf(c) methods would be unnecessary. > The min/max methods would be generally more useful than the > BinaryOperators returned from Comparators, and c::min reads better > than Comparators.lesserOf(c). > +1. > 5. Comparators.reverseOrder(c) is confusing in that it has different > behavior than Collections.reverseOrder(c). It throws an NPE. Also, > this new method seems to be useless because one could call > c.reverseOrder() instead. I suggest removing the method. > I agree. > 6. I don't see why Comparators.compose(c1,c2) is useful given that > users can call c1.thenComparing(c2). The latter reads better; the > word "compose" does not naturally fit with comparators and has strange > connotations for those with Math backgrounds. > > 7. Last I checked, even this simple example did not compile: > > Comparator c = comparing(String::length); > > It was confused about whether I was implying a ToDoubleFunction or a > ToLongFunction, which were both wrong. I also ran into a lot of type > inference loop problems when chaining. > > Is this simply a problem with lambda evaluation that's going to be > fixed before Java 8 is officially released? Is there something more > complex going on here that makes statements like this impossible? > > If the compilation problems aren't going to be fixed prior to the > release, or if they cannot be fixed, then none of these > Comparator/Comparators additions are useful. You would be better off > removing them. > My hope is this to be fixed. Cheers, Henry From xueming.shen at oracle.com Wed Mar 6 21:06:14 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 06 Mar 2013 13:06:14 -0800 Subject: Java regex vs. Unicode TR#18 vs. ICU In-Reply-To: <5137AA9E.1030309@oracle.com> References: <5137AA9E.1030309@oracle.com> Message-ID: <5137AFC6.1020805@oracle.com> On 03/06/2013 12:44 PM, Steven R. Loomis wrote: > Hello, > Someone on the ICU team recently compared the use of "\w" between ICU, Java, and Unicode TR#18 > . > The results are in the following ICU bug . > > A question for core-libs-dev is, does Java plan to change the semantics of \w to match TR#18's list? It appears the "standard" has just added one more entry \p{Join_Control} during their last update :-( I may consider to update the spec/impl to match that, I would assume there is no any jdk7 application really has dependency on the updated \w (in jdk7). -Sherman From steven.loomis at oracle.com Wed Mar 6 22:01:19 2013 From: steven.loomis at oracle.com (Steven R. Loomis) Date: Wed, 06 Mar 2013 14:01:19 -0800 Subject: Java regex vs. Unicode TR#18 vs. ICU In-Reply-To: <5137AFC6.1020805@oracle.com> References: <5137AA9E.1030309@oracle.com> <5137AFC6.1020805@oracle.com> Message-ID: <5137BCAF.7000107@oracle.com> On 3/6/13 1:06 PM, Xueming Shen wrote: > On 03/06/2013 12:44 PM, Steven R. Loomis wrote: >> Hello, >> Someone on the ICU team recently compared the use of "\w" between >> ICU, Java, and Unicode TR#18 >> . >> The results are in the following ICU bug >> . >> >> A question for core-libs-dev is, does Java plan to change the >> semantics of \w to match TR#18's list? > > It appears the "standard" has just added one more entry \p{Join_Control} > during their last update :-( I may consider to update the spec/impl to > match > that, I would assume there is no any jdk7 application really has > dependency > on the updated \w (in jdk7). > > -Sherman > > Thanks, Sherman Do you want to open a bug to track this? You can reference the above URLs Steven From bill.pittore at oracle.com Thu Mar 7 02:51:57 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Wed, 06 Mar 2013 21:51:57 -0500 Subject: Request for review- RFE 8005716 In-Reply-To: <6B264182-3ECA-46BC-94E8-9A2A02AAA6F3@oracle.com> References: <51367A43.1060606@oracle.com> <6B264182-3ECA-46BC-94E8-9A2A02AAA6F3@oracle.com> Message-ID: <513800CD.6000502@oracle.com> On 3/6/2013 12:50 PM, Mike Duigou wrote: > Hi Bill; > > Some notes from reviewing the JDK side changes. > > > System.java/Runtime.java: > > The example which begins with the name "If the filename argument, " needs to better identify that "L" is an example. (Italics?) Re-worded that a bit. > java/lang/ClassLoader.java: > > NativeLibrary::fromClass could be final. Ok. > > ClassLoader.c: > > In Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib() > > These two values are known at compile time. > > int prefixLen = (int) strlen(JNI_LIB_PREFIX); > int suffixLen = (int) strlen(JNI_LIB_SUFFIX); > > Some of the error conditions don't throw exceptions. Such as: > > if (cname == NULL) { > return NULL; > } Fixed. > The prefix and suffix are stripped from cname without checking that cname actually contains the prefix or suffix. ..._findBuiltinLib is only called after System.mapLibraryName has added prefix and suffix. > > if (len > prefixLen) is invariant. Based on System.mapLibraryName always called, then this could just be an assert. Unless JNU_GetStringPlatformChars returns some bogus string. > > src/solaris/native/common/jni_util_md.c: > > void* getProcessHandle() { > static void* procHandle = NULL; > if (procHandle == NULL) { > procHandle = (void*)dlopen(NULL, RTLD_LAZY); > } > > return procHandle; > } > > Why is the error handling code commented out? That was just for some debugging. I've removed it. Thanks for commenting. I'll get a new webrev up shortly. bill > > Mike > > > On Mar 5 2013, at 15:05 , bill.pittore at oracle.com wrote: > >> This request is tied to bugid 8005716 that deals with adding support for statically linked JNI libraries. >> >> The JEP is here: http://openjdk.java.net/jeps/178 >> >> The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716 >> >> The webrevs are here: >> >> http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.00/ >> http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ >> >> The main piece of functionality is to check for the presence of JNI_OnLoad_libname to determine if the library specified by 'libname' has been statically linked into the VM. If the symbol is found, it is assumed that the library is linked in and will not be dynamically loaded. >> >> thanks, >> bill From martinrb at google.com Thu Mar 7 02:55:09 2013 From: martinrb at google.com (martinrb at google.com) Date: Thu, 07 Mar 2013 02:55:09 +0000 Subject: hg: jdk8/tl/jdk: 8008759: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so Message-ID: <20130307025522.AD40C47D95@hg.openjdk.java.net> Changeset: 14e49a70729a Author: martin Date: 2013-03-06 17:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/14e49a70729a 8008759: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so Summary: Define FILES_m to force use of linker script Reviewed-by: sherman, alanb, ohair ! make/java/zip/Makefile ! src/share/native/java/util/zip/Inflater.c From martinrb at google.com Thu Mar 7 02:57:57 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 6 Mar 2013 18:57:57 -0800 Subject: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so In-Reply-To: References: <5128AD43.2000809@oracle.com> <51292295.4040802@oracle.com> <512F63AB.2050204@oracle.com> Message-ID: Pushed to jdk8/tl/jdk. I recommend this be backported to jdk7u. From weijun.wang at oracle.com Thu Mar 7 03:39:22 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Thu, 07 Mar 2013 03:39:22 +0000 Subject: hg: jdk8/tl/jdk: 8009604: old make images failed: JarBASE64Encoder class not found Message-ID: <20130307034007.ECBA047D9B@hg.openjdk.java.net> Changeset: cf54f6be3e9e Author: weijun Date: 2013-03-07 11:32 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf54f6be3e9e 8009604: old make images failed: JarBASE64Encoder class not found Reviewed-by: xuelei, wetmore ! make/common/Release.gmk From staffan.larsen at oracle.com Thu Mar 7 08:10:07 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 7 Mar 2013 09:10:07 +0100 Subject: RFR(S): 8006637 Failure to filter out native frame events on Solaris In-Reply-To: References: Message-ID: <47E924B8-0406-4EA9-B9C5-2C30B7E3EBE6@oracle.com> Adding core-libs-dev and re-asking for a review. Thanks, /Staffan On 27 feb 2013, at 15:59, Staffan Larsen wrote: > Please review the following test fix. > > webrev: http://cr.openjdk.java.net/~sla/8006637/webrev.00/ > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006637 > > The problem is that the test assumes that no other threads call String.intern() while the tests is running. This is normally ok, but when running with JFR there are other threads calling String.intern() in the background and the test fails. The solution is to add a thread filter to the method exit requests so that only calls to String.inter() in the main thread are reported. > > Thanks, > /Staffan From serguei.spitsyn at oracle.com Thu Mar 7 10:05:00 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 07 Mar 2013 02:05:00 -0800 Subject: RFR(S): 8006637 Failure to filter out native frame events on Solaris In-Reply-To: <47E924B8-0406-4EA9-B9C5-2C30B7E3EBE6@oracle.com> References: <47E924B8-0406-4EA9-B9C5-2C30B7E3EBE6@oracle.com> Message-ID: <5138664C.8060907@oracle.com> Looks good. Thanks, Serguei On 3/7/13 12:10 AM, Staffan Larsen wrote: > Adding core-libs-dev and re-asking for a review. > > Thanks, > /Staffan > > On 27 feb 2013, at 15:59, Staffan Larsen wrote: > >> Please review the following test fix. >> >> webrev: http://cr.openjdk.java.net/~sla/8006637/webrev.00/ >> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006637 >> >> The problem is that the test assumes that no other threads call String.intern() while the tests is running. This is normally ok, but when running with JFR there are other threads calling String.intern() in the background and the test fails. The solution is to add a thread filter to the method exit requests so that only calls to String.inter() in the main thread are reported. >> >> Thanks, >> /Staffan From vicente.romero at oracle.com Thu Mar 7 10:08:16 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Thu, 07 Mar 2013 10:08:16 +0000 Subject: hg: jdk8/tl/langtools: 8009138: javac, equals-hashCode warning tuning Message-ID: <20130307100821.D563B47DD3@hg.openjdk.java.net> Changeset: 3806171b52d8 Author: vromero Date: 2013-03-07 10:04 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3806171b52d8 8009138: javac, equals-hashCode warning tuning Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/6563143/EqualsHashCodeWarningTest.java + test/tools/javac/6563143/EqualsHashCodeWarningTest.out - test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.java - test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.out From vicente.romero at oracle.com Thu Mar 7 10:14:15 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Thu, 07 Mar 2013 10:14:15 +0000 Subject: hg: jdk8/tl/langtools: 8009170: Regression: javac generates redundant bytecode in assignop involving arrays Message-ID: <20130307101418.ED30447DD6@hg.openjdk.java.net> Changeset: 823fb9229724 Author: vromero Date: 2013-03-07 10:12 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/823fb9229724 8009170: Regression: javac generates redundant bytecode in assignop involving arrays Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! test/tools/javac/7167125/DiffResultAfterSameOperationInnerClasses.java + test/tools/javac/8009170/RedundantByteCodeInArrayTest.java From chris.hegarty at oracle.com Thu Mar 7 10:22:06 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 07 Mar 2013 10:22:06 +0000 Subject: hg: jdk8/tl/jdk: 6370908: Add support for HTTP_CONNECT proxy in Socket class Message-ID: <20130307102235.A0BFF47DD9@hg.openjdk.java.net> Changeset: 48b7295f02f8 Author: chegar Date: 2013-03-07 10:07 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/48b7295f02f8 6370908: Add support for HTTP_CONNECT proxy in Socket class Reviewed-by: chegar Contributed-by: Damjan Jovanovic , Chris Hegarty + src/share/classes/java/net/HttpConnectSocketImpl.java ! src/share/classes/java/net/Socket.java + test/java/net/Socket/HttpProxy.java From staffan.larsen at oracle.com Thu Mar 7 11:54:08 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 7 Mar 2013 12:54:08 +0100 Subject: RFR(S): 8009397 test/com/sun/jdi/PrivateTransportTest.sh: ERROR: transport library missing onLoad entry: private_dt_socket In-Reply-To: <51379D88.6080807@oracle.com> References: <2A1F6D24-22FC-4CB4-84FD-05E8ECDDC9BF@oracle.com> <513646F9.3060601@oracle.com> <51379D88.6080807@oracle.com> Message-ID: <6E926A33-CBCE-46C9-86A4-2C3F57E058CB@oracle.com> Here is a webrev for fixing this problem. I actually removed all of our own tokenization code in dll_build_name() and replaced it with calls to strtok_r (strtok_s on windows) instead. I think this should be more robust, at the cost of an extra memory allocation. I've also added the const qualifier to some of the parameters. http://cr.openjdk.java.net/~sla/8009558/webrev.02/ All of the jdi and hprof tests passes with this change. Thanks, /Staffan On 6 mar 2013, at 20:48, serguei.spitsyn at oracle.com wrote: > Staffan, > > Thank you for the confirmation and taking care about this issue! > > Thanks, > Serguei > > > On 3/6/13 11:36 AM, Staffan Larsen wrote: >> Nice catch, Serguei! >> >> Unfortunately I have already pushed my change, but I filed "JDK-8009558: linked_md.c::dll_build_name can get stuck in an infinite loop" to track this new problem and I am working on a fix. >> >> Thanks, >> /Staffan >> >> >> On 5 mar 2013, at 20:26, serguei.spitsyn at oracle.com wrote: >> >>> Hi Staffan, >>> >>> Thank you for this discovery! >>> It looks good, but I have a couple of comments. >>> >>> It seems, there is one more problem in this code: >>> 68 /* check for NULL path */ >>> 69 if (p == pathname) { >>> 70 continue; <== Endless loop if we hit this line >>> 71 } >>> >>> Do we need to do 'pathname++' before continuing at the line #70? >>> It is going to be endless loop in cases there is a PATH_SEPARATOR >>> at the beginning of paths or two PATH_SEPARATOR's in a row. >>> These would be incorrect path lists but the code above is targeting exactly such cases. >>> >>> Also, the argument name "pathname" in the original code is confusing. >>> Should we rename it to "pathnames"? >>> >>> Thanks, >>> Serguei >>> >>> >>> On 3/4/13 10:56 AM, Staffan Larsen wrote: >>>> I accidentally stepped on this bug the other day. There is a problem in linker_md.c : dll_build_name() where an internal pointer can be moved to point outside the string. The code looks like: >>>> >>>> 57 static void dll_build_name(char* buffer, size_t buflen, >>>> 58 const char* pname, const char* fname) { >>>> 59 // Based on os_solaris.cpp >>>> 60 >>>> 61 char *path_sep = PATH_SEPARATOR; >>>> 62 char *pathname = (char *)pname; >>>> 63 while (strlen(pathname) > 0) { >>>> 64 char *p = strchr(pathname, *path_sep); >>>> 65 if (p == NULL) { >>>> 66 p = pathname + strlen(pathname); >>>> 67 } >>>> 68 /* check for NULL path */ >>>> 69 if (p == pathname) { >>>> 70 continue; >>>> 71 } >>>> 72 (void)snprintf(buffer, buflen, "%.*s/lib%s." LIB_SUFFIX, (p - pathname), >>>> 73 pathname, fname); >>>> 74 >>>> 75 if (access(buffer, F_OK) == 0) { >>>> 76 break; >>>> 77 } >>>> 78 pathname = p + 1; >>>> 79 *buffer = '\0'; >>>> 80 } >>>> >>>> If the supplied pname is a buffer with a simple path without any path separators in it, p will be set to the terminating nul on line 66. Then on line 78 it will be moved outside the buffer. Fixing this also necessitates fixes to the callers to check for an empty return string (in buffer). >>>> >>>> The same code show up in both the solaris code and the windows code as well as hprof. >>>> >>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8009397 >>>> webrev: http://cr.openjdk.java.net/~sla/8009397/webrev.00/ >>>> >>>> Thanks, >>>> /Staffan >>> >> > From Alan.Bateman at oracle.com Thu Mar 7 12:30:38 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 07 Mar 2013 12:30:38 +0000 Subject: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so In-Reply-To: References: <5128AD43.2000809@oracle.com> <51292295.4040802@oracle.com> <512F63AB.2050204@oracle.com> Message-ID: <5138886E.9050307@oracle.com> On 07/03/2013 02:57, Martin Buchholz wrote: > Pushed to jdk8/tl/jdk. > I recommend this be backported to jdk7u. I agree that it would be good to backport. It doesn't happen automatically so you'll need to mail jdk7u-dev asking for approved to push it to jdk7u/jdk7u-dev. -Alan From Alan.Bateman at oracle.com Thu Mar 7 12:40:22 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 07 Mar 2013 12:40:22 +0000 Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code In-Reply-To: <51363BCD.7070700@oracle.com> References: <50FE3EE5.20600@oracle.com> <5100065A.9080801@oracle.com> <51029C56.9020302@oracle.com> <5106CB48.3010102@oracle.com> <5107B89A.3050400@oracle.com> <510ACEFC.2060607@oracle.com> <510B900B.1030406@oracle.com> <510C008A.2000107@oracle.com> <510C32D2.2080508@oracle.com> <51363BCD.7070700@oracle.com> Message-ID: <51388AB6.4000504@oracle.com> On 05/03/2013 18:39, Dan Xu wrote: > Hi All, > > Thanks for your good suggestions. I have updated this fix and put the > new webrev at http://cr.openjdk.java.net/~dxu/8001334/webrev.01/. > Please help review it. Thanks! > > -Dan > I've looked at the latest webrev and it looks quite good. There are several other things that should be done, like the O_CLOEXEC topic that we discussed here, but they can be done later. The main thing is that we've removed the dependency on the JVM_* functions and so finally being the interruptible I/O story to to end. For naming then I probably should chosen something other than handle* for the *nix code but I guess what you have is okay. A few comments on the *nix handleOpen: - it doesn't look like "flag" is needed as you can pass oflag to open64. - it looks like close could set errno. At least for the EISDIR case you probably should set this after the close. - I assume fstat64 should use RESTARTABLE. A small comment on handleRead/handleWrite is that the return from read/write is normally ssize_t. Something for another day but we would re-examine handleAppend as the file should be open for O_APPEND already. Minor nit in handleAvailable is that the last if-then-else is missing braces around the return 0. Minor nit in the RESTARTABLE macro (io_util_md.c), probably should use 4-space indent. That's all I have. -Alan. From alexey.utkin at oracle.com Thu Mar 7 13:21:10 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Thu, 07 Mar 2013 17:21:10 +0400 Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code In-Reply-To: <51388AB6.4000504@oracle.com> References: <50FE3EE5.20600@oracle.com> <5100065A.9080801@oracle.com> <51029C56.9020302@oracle.com> <5106CB48.3010102@oracle.com> <5107B89A.3050400@oracle.com> <510ACEFC.2060607@oracle.com> <510B900B.1030406@oracle.com> <510C008A.2000107@oracle.com> <510C32D2.2080508@oracle.com> <51363BCD.7070700@oracle.com> <51388AB6.4000504@oracle.com> Message-ID: <51389446.1000405@oracle.com> Can I say two word about the file http://cr.openjdk.java.net/~dxu/8001334/webrev.01/src/windows/native/java/io/io_util_md.c.frames.html and function getLastErrorString(char *buf, size_t len) Here is the documentation for [FormatMessage]: http://msdn.microsoft.com/en-gb/library/windows/desktop/ms679351%28v=vs.85%29.aspx if you are using ASCII version of FormatMessage that is a good idea to have the direct reference to [FormatMessageA], not define. The second word is about the third world countries: Russia and China. Windows OS has localized version. The error messages on that systems would contains only [?] in the worst case. =========================== dwLanguageId [in] The language identifier for the requested message. This parameter is ignored if dwFlags includes FORMAT_MESSAGE_FROM_STRING. If you pass a specific LANGID in this parameter, FormatMessage will return a message for that LANGID only. If the function cannot find a message for that LANGID, it sets Last-Error to ERROR_RESOURCE_LANG_NOT_FOUND. !!!!------------>If you pass in zero, FormatMessage looks for a message for LANGIDs in the following order: Language neutral Thread LANGID, based on the thread's locale value User default LANGID, based on the user's default locale value System default LANGID, based on the system default locale value US English <-------------!!!! If FormatMessage does not locate a message for any of the preceding LANGIDs, it returns any language message string that is present. If that fails, it returns ERROR_RESOURCE_LANG_NOT_FOUND. =========================== On 07.03.2013 16:40, Alan Bateman wrote: > On 05/03/2013 18:39, Dan Xu wrote: >> Hi All, >> >> Thanks for your good suggestions. I have updated this fix and put the >> new webrev at http://cr.openjdk.java.net/~dxu/8001334/webrev.01/. >> Please help review it. Thanks! >> >> -Dan >> > I've looked at the latest webrev and it looks quite good. There are > several other things that should be done, like the O_CLOEXEC topic > that we discussed here, but they can be done later. The main thing is > that we've removed the dependency on the JVM_* functions and so > finally being the interruptible I/O story to to end. > > For naming then I probably should chosen something other than handle* > for the *nix code but I guess what you have is okay. > > A few comments on the *nix handleOpen: > > - it doesn't look like "flag" is needed as you can pass oflag to open64. > > - it looks like close could set errno. At least for the EISDIR case > you probably should set this after the close. > > - I assume fstat64 should use RESTARTABLE. > > A small comment on handleRead/handleWrite is that the return from > read/write is normally ssize_t. > > Something for another day but we would re-examine handleAppend as the > file should be open for O_APPEND already. > > Minor nit in handleAvailable is that the last if-then-else is missing > braces around the return 0. > > Minor nit in the RESTARTABLE macro (io_util_md.c), probably should use > 4-space indent. > > That's all I have. > > -Alan. > > > From Alan.Bateman at oracle.com Thu Mar 7 13:28:15 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 07 Mar 2013 13:28:15 +0000 Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code In-Reply-To: <51389446.1000405@oracle.com> References: <50FE3EE5.20600@oracle.com> <5100065A.9080801@oracle.com> <51029C56.9020302@oracle.com> <5106CB48.3010102@oracle.com> <5107B89A.3050400@oracle.com> <510ACEFC.2060607@oracle.com> <510B900B.1030406@oracle.com> <510C008A.2000107@oracle.com> <510C32D2.2080508@oracle.com> <51363BCD.7070700@oracle.com> <51388AB6.4000504@oracle.com> <51389446.1000405@oracle.com> Message-ID: <513895EF.6040001@oracle.com> On 07/03/2013 13:21, Alexey Utkin wrote: > Can I say two word about the file > http://cr.openjdk.java.net/~dxu/8001334/webrev.01/src/windows/native/java/io/io_util_md.c.frames.html > > and function > getLastErrorString(char *buf, size_t len) > > Here is the documentation for [FormatMessage]: > http://msdn.microsoft.com/en-gb/library/windows/desktop/ms679351%28v=vs.85%29.aspx > > if you are using ASCII version of FormatMessage that is a good idea > to have the direct reference to [FormatMessageA], not define. > > The second word is about the third world countries: Russia and China. > Windows OS has localized version. The error messages on that systems > would contains only [?] in the worst case. > It's good to re-examine this but just to mention that this is just bringing over what is in os::lasterror (in hotspot/src/os/windows/vm/os_windows.cpp). -Alan From Alan.Bateman at oracle.com Thu Mar 7 14:33:48 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 07 Mar 2013 14:33:48 +0000 Subject: 8006000: TEST_BUG: java/lang/invoke/lambda/LambdaAccessControlTest.java fails intermittently Message-ID: <5138A54C.5040304@oracle.com> Robert - LambdaAccessControlTest is a problem when running the jdk tests concurrently (jtreg -concurrency...). The test extends LUtils so it's only going to compile if LambdaAccessControlDoPrivilegedTest.java has been previously compiled into the same work directory. I'd like to move LUtils into its own source file so that it can be compiled correctly by both tests. The webrev is here: http://cr.openjdk.java.net/~alanb/8006000/webrev/ Thanks, Alan. From robert.field at oracle.com Thu Mar 7 16:27:35 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Thu, 07 Mar 2013 16:27:35 +0000 Subject: hg: jdk8/tl/langtools: 8009582: Method reference generic constructor gives: IllegalArgumentException: Invalid lambda deserialization Message-ID: <20130307162738.D16F347E00@hg.openjdk.java.net> Changeset: a02c3ddc182b Author: rfield Date: 2013-03-07 08:26 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a02c3ddc182b 8009582: Method reference generic constructor gives: IllegalArgumentException: Invalid lambda deserialization Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/GenericMethodRefImplClass.java From bill.pittore at oracle.com Thu Mar 7 16:36:59 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Thu, 07 Mar 2013 11:36:59 -0500 Subject: Request for review- RFE 8005716 In-Reply-To: <513748D4.3080803@oracle.com> References: <51367A43.1060606@oracle.com> <513748D4.3080803@oracle.com> Message-ID: <5138C22B.5070803@oracle.com> I updated the code based on the feedback. To fix the windows symbol name issue that Dean brought up I added a platform specific function, buildJniFunctionName. In windows it will properly convert _JNI_OnLoad at 8 to _JNI_OnLoad_libname at 8 as well as handle JNI_OnLoad symbol name. Fixed copyright headers as well. Tested on linux and windows Webrevs are here: http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.01/ http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ bill On 3/6/2013 8:47 AM, Alan Bateman wrote: > On 05/03/2013 23:05, bill.pittore at oracle.com wrote: >> This request is tied to bugid 8005716 that deals with adding support >> for statically linked JNI libraries. >> >> The JEP is here: http://openjdk.java.net/jeps/178 >> >> The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716 >> >> The webrevs are here: >> >> http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.00/ >> http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ >> >> The main piece of functionality is to check for the presence of >> JNI_OnLoad_libname to determine if the library specified by 'libname' >> has been statically linked into the VM. If the symbol is found, it is >> assumed that the library is linked in and will not be dynamically >> loaded. > Overall I think this is quite good and follows the proposal in the > JEP. I don't see anything obvious wrong with the logic and everything > should just work for shared libraries as it does today. I assume > you'll run all the appropriate tests. > > I see Dean's suggestion to add a JVM function to allow for a lookup > table when the symbol information is available, If you do that then > you'll need to get the hotspot changes in first. Alternatively, change > what you have later once the hotspot changes are in.Just on the > > As findBuiltJniFunction can locate a built-in or a JNI_OnLoad/OnUnload > in a library then the function name is probably not quite right > (shouldn't have "Builtin" in the name). > > A minor nit in _findBuiltinLib is that if the OOME path should call > JNU_ReleaseStringPlatformChars before returning. > > There are a few commented out statements in jni_util_md.c that I > assume will be removed. Also you might want to check the indentation > in both getProcessHandle implementations as they look like 2-spaces > whereas the libs uses 4 (although this may be mute if you use a JVM > function). > > Otherwise I think this is good and I can sponsor the jdk part to this > and help get it into jdk8/tl. > > -Alan > From serguei.spitsyn at oracle.com Thu Mar 7 17:39:21 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 07 Mar 2013 09:39:21 -0800 Subject: RFR(S): 8009397 test/com/sun/jdi/PrivateTransportTest.sh: ERROR: transport library missing onLoad entry: private_dt_socket In-Reply-To: <6E926A33-CBCE-46C9-86A4-2C3F57E058CB@oracle.com> References: <2A1F6D24-22FC-4CB4-84FD-05E8ECDDC9BF@oracle.com> <513646F9.3060601@oracle.com> <51379D88.6080807@oracle.com> <6E926A33-CBCE-46C9-86A4-2C3F57E058CB@oracle.com> Message-ID: <5138D0C9.4030705@oracle.com> Nice fix! This is more clear and robust. Extra memory allocation is Ok. Thanks, Serguei On 3/7/13 3:54 AM, Staffan Larsen wrote: > Here is a webrev for fixing this problem. I actually removed all of > our own tokenization code in dll_build_name() and replaced it with > calls to strtok_r (strtok_s on windows) instead. I think this should > be more robust, at the cost of an extra memory allocation. I've also > added the const qualifier to some of the parameters. > > http://cr.openjdk.java.net/~sla/8009558/webrev.02/ > > > All of the jdi and hprof tests passes with this change. > > Thanks, > /Staffan > > On 6 mar 2013, at 20:48, serguei.spitsyn at oracle.com > wrote: > >> Staffan, >> >> Thank you for the confirmation and taking care about this issue! >> >> Thanks, >> Serguei >> >> >> On 3/6/13 11:36 AM, Staffan Larsen wrote: >>> Nice catch, Serguei! >>> >>> Unfortunately I have already pushed my change, but I filed >>> "JDK-8009558: linked_md.c::dll_build_name can get stuck in an >>> infinite loop" to track this new problem and I am working on a fix. >>> >>> Thanks, >>> /Staffan >>> >>> >>> On 5 mar 2013, at 20:26, serguei.spitsyn at oracle.com >>> wrote: >>> >>>> Hi Staffan, >>>> >>>> Thank you for this discovery! >>>> It looks good, but I have a couple of comments. >>>> >>>> It seems, there is one more problem in this code: >>>> 68 /* check for NULL path */ >>>> 69 if (p == pathname) { >>>> 70 continue;<== Endless loop if we hit this line >>>> 71 } >>>> >>>> Do we need to do 'pathname++' before continuing at the line #70? >>>> It is going to be endless loop in cases there is a PATH_SEPARATOR >>>> at the beginning of paths or two PATH_SEPARATOR's in a row. >>>> These would be incorrect path lists but the code above is targeting >>>> exactly such cases. >>>> >>>> Also, the argument name "pathname" in the original code is confusing. >>>> Should we rename it to "pathnames"? >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 3/4/13 10:56 AM, Staffan Larsen wrote: >>>>> I accidentally stepped on this bug the other day. There is a problem in linker_md.c : dll_build_name() where an internal pointer can be moved to point outside the string. The code looks like: >>>>> >>>>> 57 static void dll_build_name(char* buffer, size_t buflen, >>>>> 58 const char* pname, const char* fname) { >>>>> 59 // Based on os_solaris.cpp >>>>> 60 >>>>> 61 char *path_sep = PATH_SEPARATOR; >>>>> 62 char *pathname = (char *)pname; >>>>> 63 while (strlen(pathname) > 0) { >>>>> 64 char *p = strchr(pathname, *path_sep); >>>>> 65 if (p == NULL) { >>>>> 66 p = pathname + strlen(pathname); >>>>> 67 } >>>>> 68 /* check for NULL path */ >>>>> 69 if (p == pathname) { >>>>> 70 continue; >>>>> 71 } >>>>> 72 (void)snprintf(buffer, buflen, "%.*s/lib%s." LIB_SUFFIX, (p - pathname), >>>>> 73 pathname, fname); >>>>> 74 >>>>> 75 if (access(buffer, F_OK) == 0) { >>>>> 76 break; >>>>> 77 } >>>>> 78 pathname = p + 1; >>>>> 79 *buffer = '\0'; >>>>> 80 } >>>>> >>>>> If the supplied pname is a buffer with a simple path without any path separators in it, p will be set to the terminating nul on line 66. Then on line 78 it will be moved outside the buffer. Fixing this also necessitates fixes to the callers to check for an empty return string (in buffer). >>>>> >>>>> The same code show up in both the solaris code and the windows code as well as hprof. >>>>> >>>>> bug:http://bugs.sun.com/view_bug.do?bug_id=8009397 >>>>> webrev:http://cr.openjdk.java.net/~sla/8009397/webrev.00/ >>>>> >>>>> Thanks, >>>>> /Staffan >>>> >>> >> > From mike.duigou at oracle.com Thu Mar 7 18:07:03 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 7 Mar 2013 10:07:03 -0800 Subject: Request for review- RFE 8005716 In-Reply-To: <5138C22B.5070803@oracle.com> References: <51367A43.1060606@oracle.com> <513748D4.3080803@oracle.com> <5138C22B.5070803@oracle.com> Message-ID: <8AE06366-AA0B-4F3A-8B6F-F0A9661F6A0D@oracle.com> Changes look good to me. Mike On Mar 7 2013, at 08:36 , BILL PITTORE wrote: > I updated the code based on the feedback. To fix the windows symbol name issue that Dean brought up I added a platform specific function, buildJniFunctionName. In windows it will properly convert _JNI_OnLoad at 8 to _JNI_OnLoad_libname at 8 as well as handle JNI_OnLoad symbol name. > > Fixed copyright headers as well. > > Tested on linux and windows > > Webrevs are here: > > http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.01/ > http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ > > bill > > On 3/6/2013 8:47 AM, Alan Bateman wrote: >> On 05/03/2013 23:05, bill.pittore at oracle.com wrote: >>> This request is tied to bugid 8005716 that deals with adding support for statically linked JNI libraries. >>> >>> The JEP is here: http://openjdk.java.net/jeps/178 >>> >>> The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716 >>> >>> The webrevs are here: >>> >>> http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.00/ >>> http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ >>> >>> The main piece of functionality is to check for the presence of JNI_OnLoad_libname to determine if the library specified by 'libname' has been statically linked into the VM. If the symbol is found, it is assumed that the library is linked in and will not be dynamically loaded. >> Overall I think this is quite good and follows the proposal in the JEP. I don't see anything obvious wrong with the logic and everything should just work for shared libraries as it does today. I assume you'll run all the appropriate tests. >> >> I see Dean's suggestion to add a JVM function to allow for a lookup table when the symbol information is available, If you do that then you'll need to get the hotspot changes in first. Alternatively, change what you have later once the hotspot changes are in.Just on the >> >> As findBuiltJniFunction can locate a built-in or a JNI_OnLoad/OnUnload in a library then the function name is probably not quite right (shouldn't have "Builtin" in the name). >> >> A minor nit in _findBuiltinLib is that if the OOME path should call JNU_ReleaseStringPlatformChars before returning. >> >> There are a few commented out statements in jni_util_md.c that I assume will be removed. Also you might want to check the indentation in both getProcessHandle implementations as they look like 2-spaces whereas the libs uses 4 (although this may be mute if you use a JVM function). >> >> Otherwise I think this is good and I can sponsor the jdk part to this and help get it into jdk8/tl. >> >> -Alan >> > > > From jeremymanson at google.com Thu Mar 7 18:18:52 2013 From: jeremymanson at google.com (Jeremy Manson) Date: Thu, 7 Mar 2013 10:18:52 -0800 Subject: Request for review- RFE 8005716 In-Reply-To: <03D91B6F-800F-4DA0-852C-6FC2D5AF06F1@oracle.com> References: <51367A43.1060606@oracle.com> <51368F88.8000309@oracle.com> <03D91B6F-800F-4DA0-852C-6FC2D5AF06F1@oracle.com> Message-ID: Hi guys, I'm really glad to see you are doing this. We've done something similar to good effect within Google (and we'll probably drop our similar, internal patch and pick up this patch once it is pushed). Have you thought about support for having a JNI_OnLoad inside of a main executable that *doesn't* have a postfixed _lib? Our Google-internal patch treats the main executable as a regular JNI library if you execute a special System.loadFromLauncher() function. We also do the same thing with JVMTI. Nit: The comments that read like this: * for example, L, and a native library called L is statically linked * with the VM, then the JNI_OnLoad_L function exported by the library Should these read "linked with the VM", or "linked with the native application loading the VM"? Jeremy On Wed, Mar 6, 2013 at 8:21 AM, Bob Vandette wrote: > > On Mar 5, 2013, at 7:36 PM, Dean Long wrote: > > > If JNI_ONLOAD_SYMBOLS contains something like "_JNI_OnLoad at 8" on > Windows, you can't just > > turn that into "_JNI_OnLoad at 8_" + . I think it needs to be > > "_JNI_OnLoad_" + + "@8" > > > Good catch Dean. > > > > Looks like onLoadSymbols[] is unused in > Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib(). > > > > Instead of adding getProcessHandle(), why not add > JVM_FindBuiltinLibraryEntry() instead? > > This would make it easier to support table-lookup when runtime symbol > information is missing or not > > supported by the platform. > > Bill has already factored out the implementation of getProcessHandle. > Although your > approach is cleaner, I'm concerned about creating a VM version dependency. > For a traditional > JRE that doesn't even require static library support, we'd have to make > sure to run on a VM that > support JNI_VERSION_1_8. It looks like the JDK maintains their own copy > of jni.h. If they didn't > do that, we would have already gone down that path. The jdk sources > already contain several > instances of dlopen, dlysym and the Windows equivalents so I don't see a > need to add a new > VM function. > > Bob. > > > > > dl > > > > On 3/5/2013 3:05 PM, bill.pittore at oracle.com wrote: > >> This request is tied to bugid 8005716 that deals with adding support > for statically linked JNI libraries. > >> > >> The JEP is here: http://openjdk.java.net/jeps/178 > >> > >> The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716 > >> > >> The webrevs are here: > >> > >> http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.00/ > >> http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ > >> > >> The main piece of functionality is to check for the presence of > JNI_OnLoad_libname to determine if the library specified by 'libname' has > been statically linked into the VM. If the symbol is found, it is assumed > that the library is linked in and will not be dynamically loaded. > >> > >> thanks, > >> bill > > > > From bill.pittore at oracle.com Thu Mar 7 18:45:02 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Thu, 07 Mar 2013 13:45:02 -0500 Subject: Request for review- RFE 8005716 In-Reply-To: References: <51367A43.1060606@oracle.com> <51368F88.8000309@oracle.com> <03D91B6F-800F-4DA0-852C-6FC2D5AF06F1@oracle.com> Message-ID: <5138E02E.7040804@oracle.com> On 3/7/2013 1:18 PM, Jeremy Manson wrote: > Hi guys, > > I'm really glad to see you are doing this. We've done something > similar to good effect within Google (and we'll probably drop our > similar, internal patch and pick up this patch once it is pushed). > > Have you thought about support for having a JNI_OnLoad inside of a > main executable that *doesn't* have a postfixed _lib? Our > Google-internal patch treats the main executable as a regular JNI > library if you execute a special System.loadFromLauncher() function. > We also do the same thing with JVMTI. > > Nit: The comments that read like this: > * for example, L, and a native library called L is statically linked > * with the VM, then the JNI_OnLoad_L function exported by the library Hows this sound. * If the filename argument, when stripped of any platform-specific library * prefix, path, and file extension, indicates a library whose name is, * for example, L, and a native library called L is statically linked * with the native application or the VM (which itself may be statically * linked into the native application), then the JNI_OnLoad_L * function exported by the library is invoked rather than attempting * to load a dynamic library. bill > Should these read "linked with the VM", or "linked with the native > application loading the VM"? > > Jeremy > > > On Wed, Mar 6, 2013 at 8:21 AM, Bob Vandette > wrote: > > > On Mar 5, 2013, at 7:36 PM, Dean Long wrote: > > > If JNI_ONLOAD_SYMBOLS contains something like "_JNI_OnLoad at 8" on > Windows, you can't just > > turn that into "_JNI_OnLoad at 8_" + . I think it needs to be > > "_JNI_OnLoad_" + + "@8" > > > Good catch Dean. > > > > Looks like onLoadSymbols[] is unused in > Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib(). > > > > Instead of adding getProcessHandle(), why not add > JVM_FindBuiltinLibraryEntry() instead? > > This would make it easier to support table-lookup when runtime > symbol information is missing or not > > supported by the platform. > > Bill has already factored out the implementation of > getProcessHandle. Although your > approach is cleaner, I'm concerned about creating a VM version > dependency. For a traditional > JRE that doesn't even require static library support, we'd have to > make sure to run on a VM that > support JNI_VERSION_1_8. It looks like the JDK maintains their > own copy of jni.h. If they didn't > do that, we would have already gone down that path. The jdk > sources already contain several > instances of dlopen, dlysym and the Windows equivalents so I don't > see a need to add a new > VM function. > > Bob. > > > > > dl > > > > On 3/5/2013 3:05 PM, bill.pittore at oracle.com > wrote: > >> This request is tied to bugid 8005716 that deals with adding > support for statically linked JNI libraries. > >> > >> The JEP is here: http://openjdk.java.net/jeps/178 > >> > >> The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716 > >> > >> The webrevs are here: > >> > >> http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.00/ > > >> http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ > > >> > >> The main piece of functionality is to check for the presence of > JNI_OnLoad_libname to determine if the library specified by > 'libname' has been statically linked into the VM. If the symbol is > found, it is assumed that the library is linked in and will not be > dynamically loaded. > >> > >> thanks, > >> bill > > > > From Alan.Bateman at oracle.com Thu Mar 7 20:50:47 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 07 Mar 2013 20:50:47 +0000 Subject: Request for review- RFE 8005716 In-Reply-To: <5138C22B.5070803@oracle.com> References: <51367A43.1060606@oracle.com> <513748D4.3080803@oracle.com> <5138C22B.5070803@oracle.com> Message-ID: <5138FDA7.6040108@oracle.com> On 07/03/2013 16:36, BILL PITTORE wrote: > I updated the code based on the feedback. To fix the windows symbol > name issue that Dean brought up I added a platform specific function, > buildJniFunctionName. In windows it will properly convert > _JNI_OnLoad at 8 to _JNI_OnLoad_libname at 8 as well as handle JNI_OnLoad > symbol name. > > Fixed copyright headers as well. > > Tested on linux and windows > > Webrevs are here: > > http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.01/ > http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ > > bill Thanks for sorting out the decorator issue. One comment on that part of the implementation is that findJniFunction is sizing the buffer and buildJniFunctionName is using strcpy in the components. I wonder if this could be changed so that buildJniFunctionName sizes the buffer and uses strncpy. That way it will be obviously safe when just looking at one function. It makes it easier for static analysis tools to check too. -Alan From bill.pittore at oracle.com Thu Mar 7 21:10:25 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Thu, 07 Mar 2013 16:10:25 -0500 Subject: Request for review- RFE 8005716 In-Reply-To: <5138FDA7.6040108@oracle.com> References: <51367A43.1060606@oracle.com> <513748D4.3080803@oracle.com> <5138C22B.5070803@oracle.com> <5138FDA7.6040108@oracle.com> Message-ID: <51390241.6060309@oracle.com> On 3/7/2013 3:50 PM, Alan Bateman wrote: > On 07/03/2013 16:36, BILL PITTORE wrote: >> I updated the code based on the feedback. To fix the windows symbol >> name issue that Dean brought up I added a platform specific function, >> buildJniFunctionName. In windows it will properly convert >> _JNI_OnLoad at 8 to _JNI_OnLoad_libname at 8 as well as handle JNI_OnLoad >> symbol name. >> >> Fixed copyright headers as well. >> >> Tested on linux and windows >> >> Webrevs are here: >> >> http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.01/ >> http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ >> >> bill > Thanks for sorting out the decorator issue. One comment on that part > of the implementation is that findJniFunction is sizing the buffer and > buildJniFunctionName is using strcpy in the components. I wonder if > this could be changed so that buildJniFunctionName sizes the buffer > and uses strncpy. That way it will be obviously safe when just looking > at one function. It makes it easier for static analysis tools to check > too. > I actually was passing in 'len' at one point and checking but it seemed redundant. The comment about static analysis tools having a fit makes sense. I'll tweak it as you suggest. bill > -Alan From bharadwaj.yadavalli at oracle.com Thu Mar 7 21:14:17 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Thu, 07 Mar 2013 16:14:17 -0500 Subject: RFR(XS) : JDK-8009552 - test/vm/verifier/TestStaticIF.java failing with hs25.0-b20 Message-ID: <51390329.3070400@oracle.com> I would like to request for a review of changes whose details are as follows: Bug fixed: https://jbs.oracle.com/bugs/browse/JDK-8009552 Webrev: http://cr.openjdk.java.net/~bharadwaj/8009552/webrev/ Summary of changes : To support JDK 8 features, javac now generates invokespecial instructions to reference interface methods. The proposed change modifies bytecode verification (in old verifier) of Java 8 classfiles to allow invokespecial to refer to methods in CONSTANT_InterfaceMethodref as well as in CONSTANT_Methodref. Consequently, class hierarchy walk to validate the operand of invokespecial is restricted to classes with version less than 52. Note that this change is to the old verifier. The new verifier (split verifier) already handles this. Thanks, Bharadwaj From bradford.wetmore at oracle.com Thu Mar 7 21:42:20 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Thu, 07 Mar 2013 13:42:20 -0800 Subject: PKCS11 support on 64bit sun java In-Reply-To: References: Message-ID: <513909BC.4070206@oracle.com> Are you talking about windows-64 bit? All the other platforms should have 64-bit support. JDK 8 does have windows-x64 support for PKCS11. http://openjdk.java.net/jeps/131 I don't know of any plans to backport. Brad On 3/6/2013 9:16 PM, mohankumar kanaka wrote: > Hi, > > > This is Mohankumar working based in Hyderabad India working for MNC > > Recently i have worked on PKCS11 support for 64 bit Sun/oracle java i > found the SUNPKCS11.jar and j2pkcs11.dll are not present in jdk and > which are core elements for PKCS11 support due to absence of this > on*64bit java* we are unable work with tokens and HSMs > > > So i tried to build sunpkcs11.jar and j2pkcs11.dll > > 1. Downloaded open jdk source code jdk version 6 > 2. figured out the classes for j2pkcs11.dll and sunpkcs11.jar respectively. > 3. I was able to build the j2pkcs11.dll and sunpkcs11.jar and also > tested primarily with safenet ikey 2032 token and i was successfully get > provider by using sunpkcs11 class and also able to get the key store. > > > But i do not know the where to submit the solution so that it would be > helpful for others. > > Have a Great Day!! > Regards > Mohankumar kanaka From jim.gish at oracle.com Thu Mar 7 21:50:20 2013 From: jim.gish at oracle.com (Jim Gish) Date: Thu, 07 Mar 2013 16:50:20 -0500 Subject: RFR: 8002070 Remove the stack search for a resource bundle for Logger to use In-Reply-To: <5137AA47.9080003@oracle.com> References: <51311CC4.5000106@oracle.com> <51313053.2080605@oracle.com> <51362879.5010004@oracle.com> <513783AF.1090101@oracle.com> <51379C2A.7030604@oracle.com> <5137AA47.9080003@oracle.com> Message-ID: <51390B9C.4090504@oracle.com> On 03/06/2013 03:42 PM, Mandy Chung wrote: > >>> >>> LoggerResourceBundleRace.java: I think what you really want is to >>> add a new test that sets a context class loader to a class loader >>> that finds the resource bundle for a logger that a system class >>> loader can't find. I suggest to leave this test as it is and then >>> add a new test to exercise the context class loader search of a >>> resource bundle as a separate RFE that will improve the test coverage. >> Leaving the existing test as is not an option unless we change the >> test to run in othervm as I had on my first webrev. The bundles are >> not found otherwise. Hence the change to set the context classloader. > > I'm confused. Is the resource bundle > "LoggerResourceBundleRace$MyResources" in the classpath as this test > class is located? Should the system class loader be able to find > them? This test shouldn't depend on the stack search. Shouldn't the > thread context classloader be null and then use the system class > loader? Is another test set the thread context classloader in the > jtreg run? Does the test pass if you run it directly (not via jtreg)? > > I figured it out. I was running jtreg locally with -s -- samevm. In this case, the bundles can't be found via the system classloader. However, both directly running the tests and running in jprt which uses jtreg -a (agentvm) works fine. I can leave the test as is. Thanks, Jim -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From ali.ebrahimi1781 at gmail.com Wed Mar 6 20:20:58 2013 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Thu, 7 Mar 2013 00:50:58 +0430 Subject: CFR - updated 8001667: Comparator combinators and extension methods In-Reply-To: <51379E97.7060403@oracle.com> References: <51364B80.6030801@oracle.com> <51379E97.7060403@oracle.com> Message-ID: Hi, for me this is more readable than current naming. Comparator cmp1 = compareWith(People::getFirstName). thenCompareWith(People::getLastName); Ali Ebrahimi On Thu, Mar 7, 2013 at 12:22 AM, Henry Jen wrote: > On 03/06/2013 03:28 AM, Ali Ebrahimi wrote: > > Hi, > > just one suggestion: > > > > rename comparing with compareWith > > > > There was a round of discussion on naming. > > > http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2012-November/000446.html > > I have my personal preference among proposals, but EG seems to have come > to a consensus on this. > > I don't feel strongly between thenCompare, thenComparing or > thenCompareWith. But we should be consistent between Comparators and > Comparator, and consider that Comparators methods could be static > interface method on Comparator in the future. > > Cheers, > Henry > > > > 1) > > > > public static > Comparator > compareWith(Function keyExtractor) { > > > > > > 2) > > default Comparator thenCompareWith(Comparator other) > > > > > > > > Best Regards, > > Ali Ebrahimi > > On Wed, Mar 6, 2013 at 12:16 AM, Henry Jen > > wrote: > > > > Hi, > > > > Another update to reflect functional interface renames involved in > the > > API, and a bug fix for a regression found earlier. > > > > CCC had been approved. Can we get it reviewed and pushed? > > > > [1] http://cr.openjdk.java.net/~henryjen/ccc/8001667.4/webrev > > > > Cheers, > > Henry > > > > > > From michael.hixson at gmail.com Wed Mar 6 23:06:50 2013 From: michael.hixson at gmail.com (Michael Hixson) Date: Wed, 6 Mar 2013 15:06:50 -0800 Subject: CFR - updated 8001667: Comparator combinators and extension methods In-Reply-To: <5137AE8D.5050203@oracle.com> References: <51364B80.6030801@oracle.com> <5137AE8D.5050203@oracle.com> Message-ID: On Wed, Mar 6, 2013 at 1:01 PM, Henry Jen wrote: > On 03/06/2013 02:31 AM, Michael Hixson wrote: > >> 1. Why disable the following code even though it is (theoretically) safe? >> >> Comparator a = comparing(CharSequence::length); >> Comparator b = a.thenComparing(CASE_INSENSITIVE_ORDER); >> >> That code would compile if the signatures of the thenComparing methods >> had generics like instead of . The example above is >> conjured up and ridiculous, but I think real code will have use for >> it. Is there any downside to narrowing the return type this way? >> > > I think that make sense, will need to do some experiment to make sure it > won't confuse type system when chaining all together, and I am not sure > how much burden this has on inference engine. I prefer simplicity. > > Theoretically, if all function take Comparator carefully allows super > type, which we have, isn't that enough? Your above example can be, > > Comparator a = comparing a.thenComparing(CASE_INSENSITIVE_ORDER); > The idea is that I wanted to use both comparators. It's important that "a" remains Comparator because I want to sort List objects with it and use it to generate other CharSequence-subclass comparators in addition to "b". Also, min/max will need or else it will break Guava's Ordering class. The same thing happened a while back with comparator.reverse() (which was then renamed to reverseOrder). If the only reason for the rename was to unbreak Guava, then if you use you could change it back because the signatures will match. (Maybe the Guava devs have more insight about this signature? They went that route for most of Ordering's methods. Some of the same reasoning might apply here.) > >> 2. There's a thenComparing(Function), but no thenComparing(Function, >> Comparator). This seems like a big omission. Surely people will want >> secondary orderings on fields by something other than natural >> (null-unfriendly) ordering. Also, a Comparators.comparing(Function, >> Comparator) method would remove the need for all the Map-centric >> methods that are currently in the Comparators class. For instance: >> comparing(Map.Entry::getValue, naturalOrder()). >> > > Note that Function form must return a Comparable, which implies an order > already. Combine with Comparator.reverseOrder() method, that would cover > the ground. > > If the Comparable is not a fit, probably write a Comparator in lambda is > needed anyway? > >> 3. There is no support for sorting of nullable values or fields. >> Sorting of nullable values directly perhaps should not be encouraged, >> but sorting values by nullable fields within a chained sort is >> completely reasonable. Please add some support for this, either as >> chain methods on Comparator, or as factory methods on Comparators. >> > > Not sure what do you propose to be added. NULL is a controversial topic, > only application know what it means. Therefore, avoid try to interpret > null is probably a better approach. Write a Comparator if needed. > Regarding comparing(Function,comparator) and nulls - I'm possibly just repeating old arguments but I'll give it another shot. There are use cases for these all over the code base I ported to Java 8. I'll repost the example from my first email since I think that may answer your question about nulls: // Sort a list of people by: // 1) Last name, ignoring case // 2) Email address, with no email (null) last, ignoring case people.sort( comparing(Person::getLastName, CASE_INSENSITIVE_ORDER) .thenComparing( Person::getEmailAddress, nullsLast().thenComparing(CASE_INSENSITIVE_ORDER))); The Comparators class itself presents four use cases for comparing(Function,Comparator). I don't think they're especially good cases, but: naturalOrderKeys, naturalOrderValues, byKey, byValue could all be done instead as comparing(Map.Entry::get{Key,Value},c). It is odd to me that four specialized versions of this are being offered (I can't recall the last time I wanted to sort map entries) but the more primitive operation behind them is not. -Michael From kanakamohankumar at gmail.com Thu Mar 7 05:16:12 2013 From: kanakamohankumar at gmail.com (mohankumar kanaka) Date: Thu, 7 Mar 2013 10:46:12 +0530 Subject: PKCS11 support on 64bit sun java Message-ID: Hi, This is Mohankumar working based in Hyderabad India working for MNC Recently i have worked on PKCS11 support for 64 bit Sun/oracle java i found the SUNPKCS11.jar and j2pkcs11.dll are not present in jdk and which are core elements for PKCS11 support due to absence of this on* 64bit java* we are unable work with tokens and HSMs So i tried to build sunpkcs11.jar and j2pkcs11.dll 1. Downloaded open jdk source code jdk version 6 2. figured out the classes for j2pkcs11.dll and sunpkcs11.jar respectively. 3. I was able to build the j2pkcs11.dll and sunpkcs11.jar and also tested primarily with safenet ikey 2032 token and i was successfully get provider by using sunpkcs11 class and also able to get the key store. But i do not know the where to submit the solution so that it would be helpful for others. Have a Great Day!! Regards Mohankumar kanaka From dean.long at oracle.com Thu Mar 7 23:26:13 2013 From: dean.long at oracle.com (Dean Long) Date: Thu, 07 Mar 2013 15:26:13 -0800 Subject: Request for review- RFE 8005716 In-Reply-To: References: <51367A43.1060606@oracle.com> <51368F88.8000309@oracle.com> <03D91B6F-800F-4DA0-852C-6FC2D5AF06F1@oracle.com> Message-ID: <51392215.8020905@oracle.com> On 3/7/2013 10:18 AM, Jeremy Manson wrote: > Hi guys, > > I'm really glad to see you are doing this. We've done something > similar to good effect within Google (and we'll probably drop our > similar, internal patch and pick up this patch once it is pushed). > > Have you thought about support for having a JNI_OnLoad inside of a > main executable that *doesn't* have a postfixed _lib? Our > Google-internal patch treats the main executable as a regular JNI > library if you execute a special System.loadFromLauncher() function. > We also do the same thing with JVMTI. > Would that require additional changes to the JNI spec? Is there an advantage to treating it as an unnamed library rather than a named library (i.e. JNI_OnLoad_main)? dl > Nit: The comments that read like this: > * for example, L, and a native library called L is statically linked > * with the VM, then the JNI_OnLoad_L function exported by the library > Should these read "linked with the VM", or "linked with the native > application loading the VM"? > > Jeremy > > > On Wed, Mar 6, 2013 at 8:21 AM, Bob Vandette > wrote: > > > On Mar 5, 2013, at 7:36 PM, Dean Long wrote: > > > If JNI_ONLOAD_SYMBOLS contains something like "_JNI_OnLoad at 8" on > Windows, you can't just > > turn that into "_JNI_OnLoad at 8_" + . I think it needs to be > > "_JNI_OnLoad_" + + "@8" > > > Good catch Dean. > > > > Looks like onLoadSymbols[] is unused in > Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib(). > > > > Instead of adding getProcessHandle(), why not add > JVM_FindBuiltinLibraryEntry() instead? > > This would make it easier to support table-lookup when runtime > symbol information is missing or not > > supported by the platform. > > Bill has already factored out the implementation of > getProcessHandle. Although your > approach is cleaner, I'm concerned about creating a VM version > dependency. For a traditional > JRE that doesn't even require static library support, we'd have to > make sure to run on a VM that > support JNI_VERSION_1_8. It looks like the JDK maintains their > own copy of jni.h. If they didn't > do that, we would have already gone down that path. The jdk > sources already contain several > instances of dlopen, dlysym and the Windows equivalents so I don't > see a need to add a new > VM function. > > Bob. > > > > > dl > > > > On 3/5/2013 3:05 PM, bill.pittore at oracle.com > wrote: > >> This request is tied to bugid 8005716 that deals with adding > support for statically linked JNI libraries. > >> > >> The JEP is here: http://openjdk.java.net/jeps/178 > >> > >> The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716 > >> > >> The webrevs are here: > >> > >> http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.00/ > > >> http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ > > >> > >> The main piece of functionality is to check for the presence of > JNI_OnLoad_libname to determine if the library specified by > 'libname' has been statically linked into the VM. If the symbol is > found, it is assumed that the library is linked in and will not be > dynamically loaded. > >> > >> thanks, > >> bill > > > > From jeremymanson at google.com Fri Mar 8 01:01:53 2013 From: jeremymanson at google.com (Jeremy Manson) Date: Thu, 7 Mar 2013 17:01:53 -0800 Subject: Request for review- RFE 8005716 In-Reply-To: <51392215.8020905@oracle.com> References: <51367A43.1060606@oracle.com> <51368F88.8000309@oracle.com> <03D91B6F-800F-4DA0-852C-6FC2D5AF06F1@oracle.com> <51392215.8020905@oracle.com> Message-ID: On Thu, Mar 7, 2013 at 3:26 PM, Dean Long wrote: > On 3/7/2013 10:18 AM, Jeremy Manson wrote: > > Hi guys, > > I'm really glad to see you are doing this. We've done something similar > to good effect within Google (and we'll probably drop our similar, internal > patch and pick up this patch once it is pushed). > > Have you thought about support for having a JNI_OnLoad inside of a main > executable that *doesn't* have a postfixed _lib? Our Google-internal patch > treats the main executable as a regular JNI library if you execute a > special System.loadFromLauncher() function. We also do the same thing with > JVMTI. > > Would that require additional changes to the JNI spec? Is there an > advantage to treating it as an unnamed library rather than > a named library (i.e. JNI_OnLoad_main)? > > A couple of advantages, neither of which is a home run, but which are worth considering: First, it means you can write libraries that are intended to be both statically and dynamically compiled without making any code changes. Maybe all this means is that JNI_OnLoad_foo should work if you are trying to load libfoo.so (maybe it already does, and I didn't see that feature.) Second, you avoid potential name clashes with dynamic libraries named the same thing. This would be most useful in adding JNI_OnLoads to general-purpose launchers, where the author of the launcher doesn't have complete control over the code that gets loaded. The only one of these I know of in the wild is in Eclipse, so let's take that as an example. I could see Eclipse bundling all of its native code into a launcher, and making itself into a single executable. Let's say an Eclipse plugin wanted to load a native library called libfoo.so, but Eclipse itself had a JNI_OnLoad_foo in its launcher. Blech. Much better for the Eclipse launcher to have a single JNI_OnLoad that delegates to initialization code for foo. (The problem is compounded when you think about the fact that these will probably be (potentially different versions of) the same library. This implies a deep, deep need to worry about visibility / using Bdynamic when compiling your launcher and your static libraries.) Jeremy From david.holmes at oracle.com Fri Mar 8 01:48:35 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 08 Mar 2013 11:48:35 +1000 Subject: RFR: 8009428 and 8009429 - Profile related fixes and clean ups Message-ID: <51394373.4040404@oracle.com> Not sure which is best list for this given Alan will likely be the only reviewer anyway :) Webrevs under: http://cr.openjdk.java.net/~dholmes/8009428_8009429/ Two related sets of fixes here: JDK-8009428: Revert changes to $ substitution performed as part of nashorn integration This removes the special $ handling in ListPathSafely in MakeBase.gmk; and reverts the change in file names in CreateJars.gmk so that \$$ is restored to \$$$$ --- JDK-8009429 Miscellaneous profiles cleanup Miscellaneous cleanups to the Profiles.gmk file and the include lists: - ensure all lists are expanded in case they contain wildcards Previously I only expanded lists I knew to be (or have been non-empty). - use wildcards to list related classes Avoid listing explicit classes, particularly if nested classes are involved. - remove redundant subpackage entries if all subpackages are in the same profile The original list was generated from a list of all packages and subpackages and contained a lot of redundancy. If profile_1 for example contains java/lang then it implicitly contains java/lang/ref, java/lang/reflect etc, and doesn't need them listed. If a particular subpackage is not part of profile_1, say java/lang/special is in the full JRE only, then we need only list java/lang/special as an included package for the full JRE. All included packages for the full JRE and higher numbered profiles become excluded packages for the lower numbered profiles hence profile_1 would be "everything in java/lang except java/lang/special". (Things are a little more complicated when the subpackage exists in the lower numbered profiles. In that case the higher-level has to list out the included subpackages explicitly together with included classes.) - rename things so that the full JRE is not referred to as "PROFILE_4" The Full JRE is not a compact profile. While we logically treated it as a fourth profile for build purposes this is potentially confusing and so we no longer do that. A JRE may be a full JRE or it may be a Compact Profile JRE. Plus in CreateJars.gmk: - cleanup the de-beaning actions Now we've got a better understanding of the way $ gets processed I figured out how to express this the "natural" way. --- Thanks, David From john.r.rose at oracle.com Fri Mar 8 02:21:24 2013 From: john.r.rose at oracle.com (John Rose) Date: Thu, 7 Mar 2013 18:21:24 -0800 Subject: JEP 176: Mechanical Checking of Caller-Sensitive Methods In-Reply-To: References: <20130301175923.6475FCF8@eggemoggin.niobe.net> Message-ID: <35B2E4D5-3549-4FFD-B768-10E7216DE7E7@oracle.com> On Mar 2, 2013, at 12:46 AM, Jeroen Frijters wrote: > This is really great. I've been using an annotation for caller sensitive methods for many year in IKVM as a performance enhancement and I can say that my experiences with my simple mechanism are really great. Hi Jeroen. I'm glad you (and others) like this. Your idea makes good sense, even for Hotspot. Remi's idea (using invokedynamic) makes a good proof of concept, too. But because we use getCallerClass to observe a non-forgeable caller identity, the @CS mechanism has to be something that works "underneath" any visible bytecode pattern, at least in the caller. Thinking out loud... In JVM terms, a @CS method might also be implemented with two entry points like this: class ImportantSystemAPI { ... /** Returns the name of the class of the calling method. */ @CallerSensitive public static String currentClassName() { return currentClassName(Reflection.getCallerClass()); } private static String currentClassName(Class caller) { return caller.getName(); } } The link-resolver could be taught to look for this pattern, and accordingly tweak call sites (invokestatic instructions). The call site would have an extra parameter appended, and would be bound to the private method instead of the public one. Interestingly, the current version of the Hotspot JVM has a mechanism for appending an extra reference argument in selected calls (used for MH.invoke* and invokedynamic itself). The decision to append the extra argument (known as the "appendix") is made at call-site link time (<= first time execution of the call site). In this case, we might append the class of the caller, or (as in your design) something which allows lazy evaluation and supports derived values (class loader instead of class). In fact, the derived values are more interesting than the class itself. And if we are ever to share linkage information across classes (a desirable thing, judging by experience in the ME world) then we need to be able to make resolved @CS sites be applicable across a group of classes (all sharing a common package or CL). Thanks for the discussion! ? John From bill.pittore at oracle.com Fri Mar 8 02:22:20 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Thu, 07 Mar 2013 21:22:20 -0500 Subject: Request for review- RFE 8005716 In-Reply-To: <5138FDA7.6040108@oracle.com> References: <51367A43.1060606@oracle.com> <513748D4.3080803@oracle.com> <5138C22B.5070803@oracle.com> <5138FDA7.6040108@oracle.com> Message-ID: <51394B5C.2090306@oracle.com> Moved the string allocation into buildJniFunctionName as Alan suggested. Built and tested on windows and linux. Updated the webrev: http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.02/ bill On 3/7/2013 3:50 PM, Alan Bateman wrote: > On 07/03/2013 16:36, BILL PITTORE wrote: >> I updated the code based on the feedback. To fix the windows symbol >> name issue that Dean brought up I added a platform specific function, >> buildJniFunctionName. In windows it will properly convert >> _JNI_OnLoad at 8 to _JNI_OnLoad_libname at 8 as well as handle JNI_OnLoad >> symbol name. >> >> Fixed copyright headers as well. >> >> Tested on linux and windows >> >> Webrevs are here: >> >> http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.01/ >> http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ >> >> bill > Thanks for sorting out the decorator issue. One comment on that part > of the implementation is that findJniFunction is sizing the buffer and > buildJniFunctionName is using strcpy in the components. I wonder if > this could be changed so that buildJniFunctionName sizes the buffer > and uses strncpy. That way it will be obviously safe when just looking > at one function. It makes it easier for static analysis tools to check > too. > > -Alan From david.holmes at oracle.com Fri Mar 8 06:04:20 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 08 Mar 2013 16:04:20 +1000 Subject: RFR(XS) : JDK-8009552 - test/vm/verifier/TestStaticIF.java failing with hs25.0-b20 In-Reply-To: <51390329.3070400@oracle.com> References: <51390329.3070400@oracle.com> Message-ID: <51397F64.20503@oracle.com> Hi Bharadwaj, Given 8009697 [1] this work would only seem to be one part of what is needed to use invokestatic with an interface method. David ----- [1] The JVMS 4.9.2 states: "Each invokespecial instruction must name an instance initialization method (?2.9), a method in the current class, or a method in a superclass of the current class. " Hence no calls to an inherited interface presently allowed. On 8/03/2013 7:14 AM, Bharadwaj Yadavalli wrote: > I would like to request for a review of changes whose details are as > follows: > > Bug fixed: https://jbs.oracle.com/bugs/browse/JDK-8009552 > Webrev: http://cr.openjdk.java.net/~bharadwaj/8009552/webrev/ > > Summary of changes : > To support JDK 8 features, javac now generates invokespecial > instructions to reference interface methods. The proposed change > modifies bytecode verification (in old verifier) of Java 8 classfiles to > allow invokespecial to refer to methods in CONSTANT_InterfaceMethodref > as well as in CONSTANT_Methodref. Consequently, class hierarchy walk to > validate the operand of invokespecial is restricted to classes with > version less than 52. > > Note that this change is to the old verifier. The new verifier (split > verifier) already handles this. > > Thanks, > > Bharadwaj > > From henry.jen at oracle.com Fri Mar 8 06:57:42 2013 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 07 Mar 2013 22:57:42 -0800 Subject: CFR - updated 8001667: Comparator combinators and extension methods In-Reply-To: References: <51364B80.6030801@oracle.com> <5137AE8D.5050203@oracle.com> Message-ID: <51398BE6.8050009@oracle.com> I think it all boiled down to re-use an existing Comparator to compare for another type. What about we added this to Comparator as a default method, > default Comparator apply(Function keyExtractor) { > Objects.requireNonNull(keyExtractor); > return (Comparator & Serializable) > (c1, c2) -> compare(keyExtractor.apply(c1), keyExtractor.apply(c2)); > } Then the code you illustrated would be, people.sort(CASE_INSENSITIVE_ORDER.apply(Person::getLastName) .thenComparing(nullsLast.thenComparing(CASE_INSENSITIVE_ORDER) .apply(Person::getEmailAddress))); byKey and byValue is actually added based on the same thought that when something is not a Comparable. With above, it can be replaced with cmp.apply(Map.Entry::getKey); This is just inverse thinking of comparing, where the thoughts is mainly for Comparable and primitive type. For those, comparing/thenComparing is a more convenient and comprehensive expression. Thoughts? Cheers, Henry On 03/06/2013 03:06 PM, Michael Hixson wrote: > On Wed, Mar 6, 2013 at 1:01 PM, Henry Jen wrote: >> On 03/06/2013 02:31 AM, Michael Hixson wrote: >> >>> 1. Why disable the following code even though it is (theoretically) safe? >>> >>> Comparator a = comparing(CharSequence::length); >>> Comparator b = a.thenComparing(CASE_INSENSITIVE_ORDER); >>> >>> That code would compile if the signatures of the thenComparing methods >>> had generics like instead of . The example above is >>> conjured up and ridiculous, but I think real code will have use for >>> it. Is there any downside to narrowing the return type this way? >>> >> >> I think that make sense, will need to do some experiment to make sure it >> won't confuse type system when chaining all together, and I am not sure >> how much burden this has on inference engine. I prefer simplicity. >> >> Theoretically, if all function take Comparator carefully allows super >> type, which we have, isn't that enough? Your above example can be, >> >> Comparator a = comparing> a.thenComparing(CASE_INSENSITIVE_ORDER); >> > > The idea is that I wanted to use both comparators. It's important > that "a" remains Comparator because I want to sort > List objects with it and use it to generate other > CharSequence-subclass comparators in addition to "b". > > Also, min/max will need or else it will break Guava's > Ordering class. The same thing happened a while back with > comparator.reverse() (which was then renamed to reverseOrder). If the > only reason for the rename was to unbreak Guava, then if you use extends T> you could change it back because the signatures will match. > > (Maybe the Guava devs have more insight about this signature? They > went that route for most of Ordering's methods. Some of the same > reasoning might apply here.) > >> >>> 2. There's a thenComparing(Function), but no thenComparing(Function, >>> Comparator). This seems like a big omission. Surely people will want >>> secondary orderings on fields by something other than natural >>> (null-unfriendly) ordering. Also, a Comparators.comparing(Function, >>> Comparator) method would remove the need for all the Map-centric >>> methods that are currently in the Comparators class. For instance: >>> comparing(Map.Entry::getValue, naturalOrder()). >>> >> >> Note that Function form must return a Comparable, which implies an order >> already. Combine with Comparator.reverseOrder() method, that would cover >> the ground. >> >> If the Comparable is not a fit, probably write a Comparator in lambda is >> needed anyway? >> >>> 3. There is no support for sorting of nullable values or fields. >>> Sorting of nullable values directly perhaps should not be encouraged, >>> but sorting values by nullable fields within a chained sort is >>> completely reasonable. Please add some support for this, either as >>> chain methods on Comparator, or as factory methods on Comparators. >>> >> >> Not sure what do you propose to be added. NULL is a controversial topic, >> only application know what it means. Therefore, avoid try to interpret >> null is probably a better approach. Write a Comparator if needed. >> > > Regarding comparing(Function,comparator) and nulls - I'm possibly just > repeating old arguments but I'll give it another shot. > > There are use cases for these all over the code base I ported to Java > 8. I'll repost the example from my first email since I think that may > answer your question about nulls: > > // Sort a list of people by: > // 1) Last name, ignoring case > // 2) Email address, with no email (null) last, ignoring case > people.sort( > comparing(Person::getLastName, CASE_INSENSITIVE_ORDER) > .thenComparing( > Person::getEmailAddress, > nullsLast().thenComparing(CASE_INSENSITIVE_ORDER))); > > The Comparators class itself presents four use cases for > comparing(Function,Comparator). I don't think they're especially good > cases, but: naturalOrderKeys, naturalOrderValues, byKey, byValue could > all be done instead as comparing(Map.Entry::get{Key,Value},c). It is > odd to me that four specialized versions of this are being offered (I > can't recall the last time I wanted to sort map entries) but the more > primitive operation behind them is not. > > -Michael > From Alan.Bateman at oracle.com Fri Mar 8 09:19:01 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 08 Mar 2013 09:19:01 +0000 Subject: RFR: 8009428 and 8009429 - Profile related fixes and clean ups In-Reply-To: <51394373.4040404@oracle.com> References: <51394373.4040404@oracle.com> Message-ID: <5139AD05.1060208@oracle.com> On 08/03/2013 01:48, David Holmes wrote: > Not sure which is best list for this given Alan will likely be the > only reviewer anyway :) > > Webrevs under: > > http://cr.openjdk.java.net/~dholmes/8009428_8009429/ As further background to others, the reverting of the $ substitution became possible when Nashorn removed $ from its generated classes [1]. I've looked through the changes and they look really good to me. Putting $< in single quotes to avoid shell expansion is the solution that I could not find when adding the de-beaning recipes a few months ago. It's great to see PROFILE_4 renamed to FULL_JRE and is also great to remove the redundant sub-packages from the include lists. For profiles-rtjar-includes then I think it makes it much more readable and maintainable. Two minor inconsistencies: the sub-packages of javax.naming are listed and com/sun/jndi/ has a trailing slash. One probable side effect of removing the redundant sub-packages will be the javadoc. The one case to date where we didn't list sub-packages is java.time (because there are still changes going on there) and that the result is that the sub-packages of java.time don't show up in the profiles view. I created 8008367 a few weeks for that and I suspect that once these changes are pushed that the profiles view will be very incomplete. I don't think this should be a reason to hold off your changes as the profiles view isn't right now anyway. Hopefully Bhavesh will get to this soon. I think Erik should review this too as it's important that the build changes in jdk8/tl will merge easily with changes going into jdk8/build. -Alan. [1] http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fe5211fc3114 From eliasen at mindspring.com Fri Mar 8 10:01:38 2013 From: eliasen at mindspring.com (Alan Eliasen) Date: Fri, 08 Mar 2013 03:01:38 -0700 Subject: Review: 7032154 - Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal In-Reply-To: <5D88B1AB-F038-4000-884C-9CAD0BDB9D48@oracle.com> References: <611D45A4-8B28-408E-8914-4BCEEB4F883D@oracle.com> <3E47081F-1F08-4A61-8122-FB9209725232@oracle.com> <5D88B1AB-F038-4000-884C-9CAD0BDB9D48@oracle.com> Message-ID: <5139B702.8000803@mindspring.com> On 03/06/2013 11:55 AM, Brian Burkhalter wrote: > The link below has been updated with a few minor changes, notably to > use constants from {Double,Float}Consts and to include the link to > the OpenJDK issue report. A formatting issue resulting from an awk > failure during webrev script execution was also fixed. > > B. > > On Feb 28, 2013, at 1:34 PM, Brian Burkhalter wrote: > >> I forgot that the attachment is not redistributed and that I can >> now post on cr.openjdk.java.net so here's the webrev: >> >> http://cr.openjdk.java.net/~bpb/7032154/ >> >> Begin forwarded message: >> >>> This concerns the issue >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7032154. I notice that the solution introduces yet another version of BigInteger to add to BigInteger, MutableBigInteger, SignedMutableBigInteger, and whatever other proprietary classes are lurking. That should give The Fear to anyone who has to maintain this code. The comments for the new class don't contain a justification for yet another class other than "A really, really simple bigint package tailored to the needs of floating base conversion." I'm not quite sure what that means. The algorithms are drastically inefficient for large numbers. (To give an order of magnitude estimate, a BigInteger calculation that takes more than 18 hours (that's 64800 seconds) in JDK 1.7 takes less than 200 seconds with the BigInteger patches that we've posted.) I would posit that all of the work that has been done improving the algorithms in BigInteger by several orders of magnitude are vastly more significant than introducing yet another BigInteger class with only small percentage increases in speed for some small arguments with another sun-namespace, non-supported class. The comments don't even describe the point of methods. For example, what does multByPow52 do? Comments like "hope it fits!" don't exactly inspire confidence either. It should be noted that the multiplication algorithms are O(n^2) and will certainly be orders of magnitude slower than the new BigInteger algorithms for large numbers. (Which are stunningly faster than this class could ever be.) This class is unnecessary, and adds huge maintenance costs, and is demonstrably orders of magnitude slower for large numbers. If it contains faster algorithms for some small number sizes, they should be carefully merged with the pending patches for BigInteger that have been posted by Timothy Buktu and myself, otherwise they will just make things much slower, harder to maintain, non-portable to open projects, and decidedly inferior. Also, swearing and stuff in the comments should be filtered out, along with typos like "Chache" etc. The algorithms for base conversions that I have developed, along with the drastically faster multiplication and division and exponentiation routines that Timothy Buktu and I have developed and posted, will blow these timings out of the water for perhaps all but small number sizes. If the new class contains algorithms are more efficient for small number sizes, that code should be merged into BigInteger, rather than introducing yet another limited BigInteger class and all of its liabilities and bugs and maintenance effort. MutableBigInteger and SignedMutableBigInteger should probably also be eliminated. There is little that they do that couldn't be done approximately as efficiently in BigInteger for small numbers, and vastly faster for large numbers. This would also improve the performance of BigDecimal by orders of magnitude for large numbers. (BigDecimal uses O(n^2) algorithms from MutableBigInteger which makes division of large numbers very slow.) This new class is 1252 lines of new code, compared to, say 400 lines of well-tested code for my multiplication improvements to BigInteger which are orders of magnitude faster for large numbers. Timothy Buktu's stunning FFT multiplication algorithms (added to the existing BigInteger class) could add more lines that would turn Java into a best-of-class language for large integer work. That work should be done first. Summary: It would be a drastic mistake to add yet another BigInteger class with demonstrably inefficient algorithms for large numbers. The new proprietary and inefficient class sun.misc.FDBigInteger should be rejected summarily until the BigInteger algorithm improvements have been accepted. All reviewers should reject a patch that includes this class. After that point, any improvements in the algorithms of FDBigInteger should be merged into the existing BigInteger class, and tested against the vastly faster algorithms that would then exist, not against the slow code in JDK 1.7. If my code isn't 100 times faster for large numbers, (not 100 percent, 100 *times*,) I'll eat my head. (My tests on big numbers are 330 *times* faster easily. And that's without Timothy Buktu's magic FFT routines.) -- Alan Eliasen eliasen at mindspring.com http://futureboy.us/ From scolebourne at joda.org Fri Mar 8 10:18:55 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 8 Mar 2013 10:18:55 +0000 Subject: RFR: 8009428 and 8009429 - Profile related fixes and clean ups In-Reply-To: <5139AD05.1060208@oracle.com> References: <51394373.4040404@oracle.com> <5139AD05.1060208@oracle.com> Message-ID: On 8 March 2013 09:19, Alan Bateman wrote: > One probable side effect of removing the redundant sub-packages will be the > javadoc. The one case to date where we didn't list sub-packages is java.time > (because there are still changes going on there) and that the result is that > the sub-packages of java.time don't show up in the profiles view. I created > 8008367 a few weeks for that and I suspect that once these changes are > pushed that the profiles view will be very incomplete. I don't think this > should be a reason to hold off your changes as the profiles view isn't right > now anyway. Hopefully Bhavesh will get to this soon. The set of java.time packages is now final as far as I am concerned: java.time java.time.chrono java.time.format java.time.temporal java.time.zone All packages linked together for the same profile as java.util.Date. Stephen From chris.hegarty at oracle.com Fri Mar 8 10:59:18 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 08 Mar 2013 10:59:18 +0000 Subject: 8006000: TEST_BUG: java/lang/invoke/lambda/LambdaAccessControlTest.java fails intermittently In-Reply-To: <5138A54C.5040304@oracle.com> References: <5138A54C.5040304@oracle.com> Message-ID: <5139C486.3030307@oracle.com> This change looks fine to me Alan. I came across a similar issue with networking tests a while back. -Chris. On 07/03/2013 14:33, Alan Bateman wrote: > > Robert - LambdaAccessControlTest is a problem when running the jdk tests > concurrently (jtreg -concurrency...). The test extends LUtils so it's > only going to compile if LambdaAccessControlDoPrivilegedTest.java has > been previously compiled into the same work directory. I'd like to move > LUtils into its own source file so that it can be compiled correctly by > both tests. The webrev is here: > > http://cr.openjdk.java.net/~alanb/8006000/webrev/ > > Thanks, > Alan. From dmitry.nadezhin at gmail.com Fri Mar 8 11:17:40 2013 From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin) Date: Fri, 8 Mar 2013 14:17:40 +0300 Subject: Review: 7032154 - Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal In-Reply-To: <5139B702.8000803@mindspring.com> References: <611D45A4-8B28-408E-8914-4BCEEB4F883D@oracle.com> <3E47081F-1F08-4A61-8122-FB9209725232@oracle.com> <5D88B1AB-F038-4000-884C-9CAD0BDB9D48@oracle.com> <5139B702.8000803@mindspring.com> Message-ID: Alan, I guess that one of the reasons for all these classes (MutableBigInteger and SignedMutableBigInteger, FDBigInteger) is that they are mutable. The immutable class java.math.BigInteger will require more memory allocations. The efficient conversion from string to double has some aspects that are absent in conversion from string to BigInteger. FDBigInteger class has some methods that are useful in string<->double conversions: cmpPow52(int p5, int p2); addAndCmp(FDBigInteger x,FDBigInteger y); Their behavior is equivalent tp this.cmp(valueOfPow52(p5, p2)) this.cmp(x.add(y)) but they do their work without allocation of valueOfPow52(p5, p2) or x.add(y). These methods speed up efficent string<->double conversion. I'm not sure that these methods should be in common BigInteger API, as they make it more complicated. Alan, I'm sorry that this patch delays your patch. Nevertheless, the queue of math patches moves now. Thanks to Brian. I hope that your patch will be considered soon. Best Regards, -Dima On Fri, Mar 8, 2013 at 2:01 PM, Alan Eliasen wrote: > On 03/06/2013 11:55 AM, Brian Burkhalter wrote: >> The link below has been updated with a few minor changes, notably to >> use constants from {Double,Float}Consts and to include the link to >> the OpenJDK issue report. A formatting issue resulting from an awk >> failure during webrev script execution was also fixed. >> >> B. >> >> On Feb 28, 2013, at 1:34 PM, Brian Burkhalter wrote: >> >>> I forgot that the attachment is not redistributed and that I can >>> now post on cr.openjdk.java.net so here's the webrev: >>> >>> http://cr.openjdk.java.net/~bpb/7032154/ >>> >>> Begin forwarded message: >>> >>>> This concerns the issue >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7032154. > > I notice that the solution introduces yet another version of > BigInteger to add to BigInteger, MutableBigInteger, > SignedMutableBigInteger, and whatever other proprietary classes are > lurking. That should give The Fear to anyone who has to maintain this > code. The comments for the new class don't contain a justification for > yet another class other than "A really, really simple bigint package > tailored to the needs of floating base conversion." I'm not quite sure > what that means. The algorithms are drastically inefficient for large > numbers. > > (To give an order of magnitude estimate, a BigInteger calculation > that takes more than 18 hours (that's 64800 seconds) in JDK 1.7 takes > less than 200 seconds with the BigInteger patches that we've posted.) > > I would posit that all of the work that has been done improving the > algorithms in BigInteger by several orders of magnitude are vastly more > significant than introducing yet another BigInteger class with only > small percentage increases in speed for some small arguments with > another sun-namespace, non-supported class. > > The comments don't even describe the point of methods. For example, > what does multByPow52 do? Comments like "hope it fits!" don't exactly > inspire confidence either. > > It should be noted that the multiplication algorithms are O(n^2) and > will certainly be orders of magnitude slower than the new BigInteger > algorithms for large numbers. (Which are stunningly faster than this > class could ever be.) This class is unnecessary, and adds huge > maintenance costs, and is demonstrably orders of magnitude slower for > large numbers. If it contains faster algorithms for some small number > sizes, they should be carefully merged with the pending patches for > BigInteger that have been posted by Timothy Buktu and myself, otherwise > they will just make things much slower, harder to maintain, non-portable > to open projects, and decidedly inferior. Also, swearing and stuff in > the comments should be filtered out, along with typos like "Chache" etc. > > The algorithms for base conversions that I have developed, along with > the drastically faster multiplication and division and exponentiation > routines that Timothy Buktu and I have developed and posted, will blow > these timings out of the water for perhaps all but small number sizes. > If the new class contains algorithms are more efficient for small number > sizes, that code should be merged into BigInteger, rather than > introducing yet another limited BigInteger class and all of its > liabilities and bugs and maintenance effort. > > MutableBigInteger and SignedMutableBigInteger should probably also be > eliminated. There is little that they do that couldn't be done > approximately as efficiently in BigInteger for small numbers, and vastly > faster for large numbers. This would also improve the performance of > BigDecimal by orders of magnitude for large numbers. (BigDecimal uses > O(n^2) algorithms from MutableBigInteger which makes division of large > numbers very slow.) > > This new class is 1252 lines of new code, compared to, say 400 lines > of well-tested code for my multiplication improvements to BigInteger > which are orders of magnitude faster for large numbers. Timothy Buktu's > stunning FFT multiplication algorithms (added to the existing BigInteger > class) could add more lines that would turn Java into a best-of-class > language for large integer work. That work should be done first. > > Summary: It would be a drastic mistake to add yet another BigInteger > class with demonstrably inefficient algorithms for large numbers. The > new proprietary and inefficient class sun.misc.FDBigInteger should be > rejected summarily until the BigInteger algorithm improvements have been > accepted. All reviewers should reject a patch that includes this class. > After that point, any improvements in the algorithms of FDBigInteger > should be merged into the existing BigInteger class, and tested against > the vastly faster algorithms that would then exist, not against the slow > code in JDK 1.7. If my code isn't 100 times faster for large numbers, > (not 100 percent, 100 *times*,) I'll eat my head. (My tests on big > numbers are 330 *times* faster easily. And that's without Timothy > Buktu's magic FFT routines.) > > -- > Alan Eliasen > eliasen at mindspring.com > http://futureboy.us/ From erik.joelsson at oracle.com Fri Mar 8 11:25:33 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 08 Mar 2013 12:25:33 +0100 Subject: RFR: 8009428 and 8009429 - Profile related fixes and clean ups In-Reply-To: <5139AD05.1060208@oracle.com> References: <51394373.4040404@oracle.com> <5139AD05.1060208@oracle.com> Message-ID: <5139CAAD.5070401@oracle.com> On 2013-03-08 10:19, Alan Bateman wrote: > On 08/03/2013 01:48, David Holmes wrote: >> Not sure which is best list for this given Alan will likely be the >> only reviewer anyway :) >> >> Webrevs under: >> >> http://cr.openjdk.java.net/~dholmes/8009428_8009429/ > As further background to others, the reverting of the $ substitution > became possible when Nashorn removed $ from its generated classes [1]. > > I've looked through the changes and they look really good to me. > Putting $< in single quotes to avoid shell expansion is the solution > that I could not find when adding the de-beaning recipes a few months > ago. It's great to see PROFILE_4 renamed to FULL_JRE and is also great > to remove the redundant sub-packages from the include lists. For > profiles-rtjar-includes then I think it makes it much more readable > and maintainable. Two minor inconsistencies: the sub-packages of > javax.naming are listed and com/sun/jndi/ has a trailing slash. > > One probable side effect of removing the redundant sub-packages will > be the javadoc. The one case to date where we didn't list sub-packages > is java.time (because there are still changes going on there) and that > the result is that the sub-packages of java.time don't show up in the > profiles view. I created 8008367 a few weeks for that and I suspect > that once these changes are pushed that the profiles view will be very > incomplete. I don't think this should be a reason to hold off your > changes as the profiles view isn't right now anyway. Hopefully Bhavesh > will get to this soon. > > I think Erik should review this too as it's important that the build > changes in jdk8/tl will merge easily with changes going into jdk8/build. > > -Alan. > > [1] http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fe5211fc3114 Looks good to me and thanks again for cleaning up that $ business. I do not think this will conflict with anything coming from jdk8/build. /Erik From david.holmes at oracle.com Fri Mar 8 11:28:09 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 08 Mar 2013 21:28:09 +1000 Subject: RFR: 8009428 and 8009429 - Profile related fixes and clean ups In-Reply-To: <5139AD05.1060208@oracle.com> References: <51394373.4040404@oracle.com> <5139AD05.1060208@oracle.com> Message-ID: <5139CB49.5000601@oracle.com> On 8/03/2013 7:19 PM, Alan Bateman wrote: > On 08/03/2013 01:48, David Holmes wrote: >> Not sure which is best list for this given Alan will likely be the >> only reviewer anyway :) >> >> Webrevs under: >> >> http://cr.openjdk.java.net/~dholmes/8009428_8009429/ > As further background to others, the reverting of the $ substitution > became possible when Nashorn removed $ from its generated classes [1]. > > I've looked through the changes and they look really good to me. Putting > $< in single quotes to avoid shell expansion is the solution that I > could not find when adding the de-beaning recipes a few months ago. It's > great to see PROFILE_4 renamed to FULL_JRE and is also great to remove > the redundant sub-packages from the include lists. For > profiles-rtjar-includes then I think it makes it much more readable and > maintainable. Two minor inconsistencies: the sub-packages of > javax.naming are listed and com/sun/jndi/ has a trailing slash. Fixed - well spotted! > One probable side effect of removing the redundant sub-packages will be > the javadoc. The one case to date where we didn't list sub-packages is > java.time (because there are still changes going on there) and that the > result is that the sub-packages of java.time don't show up in the > profiles view. I created 8008367 a few weeks for that and I suspect that > once these changes are pushed that the profiles view will be very > incomplete. I don't think this should be a reason to hold off your > changes as the profiles view isn't right now anyway. Hopefully Bhavesh > will get to this soon. Now I'm a little concerned. I had not considered whether javac/javadoc considered these to be complete lists. They have to know how to combine the includes at a low-level with the excludes of a higher-level - and potentially vice-versa. > I think Erik should review this too as it's important that the build > changes in jdk8/tl will merge easily with changes going into jdk8/build. OK. Thanks, David > -Alan. > > [1] http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fe5211fc3114 From david.holmes at oracle.com Fri Mar 8 11:34:57 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 08 Mar 2013 21:34:57 +1000 Subject: RFR: 8009428 and 8009429 - Profile related fixes and clean ups In-Reply-To: <5139CAAD.5070401@oracle.com> References: <51394373.4040404@oracle.com> <5139AD05.1060208@oracle.com> <5139CAAD.5070401@oracle.com> Message-ID: <5139CCE1.8050904@oracle.com> Thanks Erik! David On 8/03/2013 9:25 PM, Erik Joelsson wrote: > > > On 2013-03-08 10:19, Alan Bateman wrote: >> On 08/03/2013 01:48, David Holmes wrote: >>> Not sure which is best list for this given Alan will likely be the >>> only reviewer anyway :) >>> >>> Webrevs under: >>> >>> http://cr.openjdk.java.net/~dholmes/8009428_8009429/ >> As further background to others, the reverting of the $ substitution >> became possible when Nashorn removed $ from its generated classes [1]. >> >> I've looked through the changes and they look really good to me. >> Putting $< in single quotes to avoid shell expansion is the solution >> that I could not find when adding the de-beaning recipes a few months >> ago. It's great to see PROFILE_4 renamed to FULL_JRE and is also great >> to remove the redundant sub-packages from the include lists. For >> profiles-rtjar-includes then I think it makes it much more readable >> and maintainable. Two minor inconsistencies: the sub-packages of >> javax.naming are listed and com/sun/jndi/ has a trailing slash. >> >> One probable side effect of removing the redundant sub-packages will >> be the javadoc. The one case to date where we didn't list sub-packages >> is java.time (because there are still changes going on there) and that >> the result is that the sub-packages of java.time don't show up in the >> profiles view. I created 8008367 a few weeks for that and I suspect >> that once these changes are pushed that the profiles view will be very >> incomplete. I don't think this should be a reason to hold off your >> changes as the profiles view isn't right now anyway. Hopefully Bhavesh >> will get to this soon. >> >> I think Erik should review this too as it's important that the build >> changes in jdk8/tl will merge easily with changes going into jdk8/build. >> >> -Alan. >> >> [1] http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fe5211fc3114 > > Looks good to me and thanks again for cleaning up that $ business. I do > not think this will conflict with anything coming from jdk8/build. > > /Erik From Alan.Bateman at oracle.com Fri Mar 8 12:00:49 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 08 Mar 2013 12:00:49 +0000 Subject: RFR: 8009428 and 8009429 - Profile related fixes and clean ups In-Reply-To: <5139CB49.5000601@oracle.com> References: <51394373.4040404@oracle.com> <5139AD05.1060208@oracle.com> <5139CB49.5000601@oracle.com> Message-ID: <5139D2F1.7070108@oracle.com> On 08/03/2013 11:28, David Holmes wrote: > > Now I'm a little concerned. I had not considered whether javac/javadoc > considered these to be complete lists. They have to know how to > combine the includes at a low-level with the excludes of a > higher-level - and potentially vice-versa. I think javac should be okay, and you can easily test this by trying to compile with "javac -profile compact ..." on a test that references types in one of these sub-packages. There are tests in the langtools repo for this too and it would be good to check ProfileOptionTest to see if need more sub-tests to cover a few sample types from these sub-packages. So I think the issue will be just the docs build and you can quickly check that too. To date we've only seen it with java.time because that was the one case where only the top-most API package was listed. I'm pretty sure the issue is in the standard doclet, in which case I think pushing your changes are okay. The only complication is that there is another issue with the generated docs and that is default view is the Profiles view so it is very confusing until you hit the "All Packages" link. -Alan From alan.bateman at oracle.com Fri Mar 8 12:08:11 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 08 Mar 2013 12:08:11 +0000 Subject: hg: jdk8/tl/jdk: 8006000: TEST_BUG: java/lang/invoke/lambda/LambdaAccessControlTest.java fails intermittently Message-ID: <20130308120900.960EE48005@hg.openjdk.java.net> Changeset: 98cf76df3e6e Author: alanb Date: 2013-03-08 12:03 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/98cf76df3e6e 8006000: TEST_BUG: java/lang/invoke/lambda/LambdaAccessControlTest.java fails intermittently Reviewed-by: chegar + test/java/lang/invoke/lambda/LUtils.java ! test/java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java ! test/java/lang/invoke/lambda/LambdaAccessControlTest.java From chris.hegarty at oracle.com Fri Mar 8 13:24:16 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 08 Mar 2013 13:24:16 +0000 Subject: RFR 8009517: Disable fatal compiler warning in the old build Message-ID: <5139E680.6000606@oracle.com> Since the new build does not enable -Werror when compiling any java code, and disables quite a few lint options, new changes my inadvertently introduce warnings without even realizing. This can cause problems when building with the old build as many areas do compile with -Werror set. Since the old build is on life support, probably best to just completely disable -Werror, so anyone still needing to use it can. diff -r 48b7295f02f8 make/common/shared/Defs-java.gmk --- a/make/common/shared/Defs-java.gmk Thu Mar 07 10:07:13 2013 +0000 +++ b/make/common/shared/Defs-java.gmk Thu Mar 07 11:10:37 2013 +0000 @@ -122,9 +122,10 @@ ifeq ($(JAVAC_MAX_WARNINGS), true) ifeq ($(JAVAC_MAX_WARNINGS), true) JAVAC_LINT_OPTIONS += -Xlint:all endif -ifeq ($(JAVAC_WARNINGS_FATAL), true) - JAVACFLAGS += -Werror -endif +# Disable fatal warnings, 8009517 +#ifeq ($(JAVAC_WARNINGS_FATAL), true) +# JAVACFLAGS += -Werror +#endif # TODO: Workaround for CR 7063027. Remove -path eventually. JAVAC_LINT_OPTIONS += -Xlint:-path -Chris. From jeroen at sumatra.nl Fri Mar 8 15:25:44 2013 From: jeroen at sumatra.nl (Jeroen Frijters) Date: Fri, 8 Mar 2013 15:25:44 +0000 Subject: JEP 176: Mechanical Checking of Caller-Sensitive Methods In-Reply-To: <35B2E4D5-3549-4FFD-B768-10E7216DE7E7@oracle.com> References: <20130301175923.6475FCF8@eggemoggin.niobe.net> <35B2E4D5-3549-4FFD-B768-10E7216DE7E7@oracle.com> Message-ID: John Rose wrote: > Remi's idea (using invokedynamic) makes a good proof of concept, too. > But because we use getCallerClass to observe a non-forgeable caller > identity, the @CS mechanism has to be something that works "underneath" > any visible bytecode pattern, at least in the caller. Yes. In IKVM CallerID also serves the purpose of making it non-forgeable by the caller. The CallerID object that is passed must be a subclass of CallerID that is nested inside the class it represents, that way .NET code can't forge a CallerID either (for Java code it is a non-issue since it can't see the CallerID parameter anyway). > Thinking out loud... In JVM terms, a @CS method might also be > implemented with two entry points like this: > > class ImportantSystemAPI { > ... > /** Returns the name of the class of the calling method. */ > @CallerSensitive > public static String currentClassName() { > return currentClassName(Reflection.getCallerClass()); > } > private static String currentClassName(Class caller) { > return caller.getName(); > } > } Maybe I'm misunderstanding, but I think my preference would be to hide the pattern from the Java developers, making the code less verbose and less fragile. HotSpot could simply add the extra parameter and turn Reflection.getCallerClass() into an intrinsic that loads the parameter. > In fact, the derived values are more interesting than the class itself. I haven't used it beyond Class and ClassLoader, but the CallerID indirection does make it easy to cache additional information (at the expense of having a field in every CallerID instance). > And if we are ever to share linkage information across classes (a > desirable thing, judging by experience in the ME world) then we need to > be able to make resolved @CS sites be applicable across a group of > classes (all sharing a common package or CL). I don't think I understand this bit, but one thing my scheme lacks is a distinction between requiring the caller's Class and just its ClassLoader. It would be more efficient to be able to share a single CallerID between all classes in a ClassLoader. Regards, Jeroen From Alan.Bateman at oracle.com Fri Mar 8 15:31:17 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 08 Mar 2013 15:31:17 +0000 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: <5139E680.6000606@oracle.com> References: <5139E680.6000606@oracle.com> Message-ID: <513A0445.4060502@oracle.com> On 08/03/2013 13:24, Chris Hegarty wrote: > Since the new build does not enable -Werror when compiling any java > code, and disables quite a few lint options, new changes my > inadvertently introduce warnings without even realizing. This can > cause problems when building with the old build as many areas do > compile with -Werror set. Since the old build is on life support, > probably best to just completely disable -Werror, so anyone still > needing to use it can. > > diff -r 48b7295f02f8 make/common/shared/Defs-java.gmk > --- a/make/common/shared/Defs-java.gmk Thu Mar 07 10:07:13 2013 +0000 > +++ b/make/common/shared/Defs-java.gmk Thu Mar 07 11:10:37 2013 +0000 > @@ -122,9 +122,10 @@ ifeq ($(JAVAC_MAX_WARNINGS), true) > ifeq ($(JAVAC_MAX_WARNINGS), true) > JAVAC_LINT_OPTIONS += -Xlint:all > endif > -ifeq ($(JAVAC_WARNINGS_FATAL), true) > - JAVACFLAGS += -Werror > -endif > +# Disable fatal warnings, 8009517 > +#ifeq ($(JAVAC_WARNINGS_FATAL), true) > +# JAVACFLAGS += -Werror > +#endif > > # TODO: Workaround for CR 7063027. Remove -path eventually. > JAVAC_LINT_OPTIONS += -Xlint:-path > > -Chris. This seems the most sensible thing to me as it is impossible to keep the old build warning working when warnings aren't fatal in the new build. -Alan. From mike.duigou at oracle.com Fri Mar 8 15:49:58 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 8 Mar 2013 07:49:58 -0800 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: <5139E680.6000606@oracle.com> References: <5139E680.6000606@oracle.com> Message-ID: Looks fine to me. Do we have an issue open for restoring warnings to the new build? Mike On Mar 8 2013, at 05:24 , Chris Hegarty wrote: > Since the new build does not enable -Werror when compiling any java code, and disables quite a few lint options, new changes my inadvertently introduce warnings without even realizing. This can cause problems when building with the old build as many areas do compile with -Werror set. Since the old build is on life support, probably best to just completely disable -Werror, so anyone still needing to use it can. > > diff -r 48b7295f02f8 make/common/shared/Defs-java.gmk > --- a/make/common/shared/Defs-java.gmk Thu Mar 07 10:07:13 2013 +0000 > +++ b/make/common/shared/Defs-java.gmk Thu Mar 07 11:10:37 2013 +0000 > @@ -122,9 +122,10 @@ ifeq ($(JAVAC_MAX_WARNINGS), true) > ifeq ($(JAVAC_MAX_WARNINGS), true) > JAVAC_LINT_OPTIONS += -Xlint:all > endif > -ifeq ($(JAVAC_WARNINGS_FATAL), true) > - JAVACFLAGS += -Werror > -endif > +# Disable fatal warnings, 8009517 > +#ifeq ($(JAVAC_WARNINGS_FATAL), true) > +# JAVACFLAGS += -Werror > +#endif > > # TODO: Workaround for CR 7063027. Remove -path eventually. > JAVAC_LINT_OPTIONS += -Xlint:-path > > -Chris. From chris.hegarty at oracle.com Fri Mar 8 15:58:14 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 08 Mar 2013 15:58:14 +0000 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: References: <5139E680.6000606@oracle.com> Message-ID: <513A0A96.7080508@oracle.com> On 08/03/2013 15:49, Mike Duigou wrote: > Looks fine to me. Thanks Mike. > Do we have an issue open for restoring warnings to the new build? Not yet, that I am aware of. We really need the ability to set lint options per package/subpackage. -Chris. > > Mike > > On Mar 8 2013, at 05:24 , Chris Hegarty wrote: > >> Since the new build does not enable -Werror when compiling any java code, and disables quite a few lint options, new changes my inadvertently introduce warnings without even realizing. This can cause problems when building with the old build as many areas do compile with -Werror set. Since the old build is on life support, probably best to just completely disable -Werror, so anyone still needing to use it can. >> >> diff -r 48b7295f02f8 make/common/shared/Defs-java.gmk >> --- a/make/common/shared/Defs-java.gmk Thu Mar 07 10:07:13 2013 +0000 >> +++ b/make/common/shared/Defs-java.gmk Thu Mar 07 11:10:37 2013 +0000 >> @@ -122,9 +122,10 @@ ifeq ($(JAVAC_MAX_WARNINGS), true) >> ifeq ($(JAVAC_MAX_WARNINGS), true) >> JAVAC_LINT_OPTIONS += -Xlint:all >> endif >> -ifeq ($(JAVAC_WARNINGS_FATAL), true) >> - JAVACFLAGS += -Werror >> -endif >> +# Disable fatal warnings, 8009517 >> +#ifeq ($(JAVAC_WARNINGS_FATAL), true) >> +# JAVACFLAGS += -Werror >> +#endif >> >> # TODO: Workaround for CR 7063027. Remove -path eventually. >> JAVAC_LINT_OPTIONS += -Xlint:-path >> >> -Chris. > From Alan.Bateman at oracle.com Fri Mar 8 15:56:37 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 08 Mar 2013 15:56:37 +0000 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: References: <5139E680.6000606@oracle.com> Message-ID: <513A0A35.40809@oracle.com> On 08/03/2013 15:49, Mike Duigou wrote: > Looks fine to me. Do we have an issue open for restoring warnings to the new build? > > Mike > I don't know if there is an issue for that yet but as the new build compiles thousands of classes in a single compilation unit then it means we will need to make significant inroads on the warnings before more can be enabled. The approach with the old build was by area and good progress had been made but with the new build, then it may have to be by warning type as all areas are compiled together. -Alan. From mike.duigou at oracle.com Fri Mar 8 16:09:51 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 8 Mar 2013 08:09:51 -0800 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: <513A0A35.40809@oracle.com> References: <5139E680.6000606@oracle.com> <513A0A35.40809@oracle.com> Message-ID: <431B8999-D7AE-42B4-B8F5-734AB8577906@oracle.com> On Mar 8 2013, at 07:56 , Alan Bateman wrote: > On 08/03/2013 15:49, Mike Duigou wrote: >> Looks fine to me. Do we have an issue open for restoring warnings to the new build? >> >> Mike >> > I don't know if there is an issue for that yet but as the new build compiles thousands of classes in a single compilation unit then it means we will need to make significant inroads on the warnings before more can be enabled. The approach with the old build was by area and good progress had been made but with the new build, then it may have to be by warning type as all areas are compiled together. Understood. Perhaps we can at least use JDK_FILTER incrementally. Do we have a way to override the warnings used by the makefile? Any thoughts towards perhaps disabling -Werror but enabling all of the warnings? Mike From Alan.Bateman at oracle.com Fri Mar 8 16:27:55 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 08 Mar 2013 16:27:55 +0000 Subject: 8009645: ClassFileTransformer hooks in ClassLoader no longer required Message-ID: <513A118B.5020802@oracle.com> I need a reviewer for a change to remove some crud from java.lang.ClassLoader. The crud in question is a hook to allow implementations of sun.misc.ClassFileTransformer be notified when defineClass fails with a class format error. It was originally added >10 years ago for Sun's Browser Plug-in to allow it fix up bad JDK1.1-era class files. I have confirmed that this is no longer needed. As always with sun.misc classes it is useful to know if they are used outside of the JDK. To than end, I checked the data that Mandy collected on sun.* usage by artifacts in Maven Central. In the case of ClassFileTransformer, we only found one usage and that was in an old version of an artifact so it's no longer an issue. Given that java.lang.instrument has been available since JDK5 then there really isn't any excuse to be using this class anyway. The webrev with the proposed changes is here. I've left sun.misc.ClassFileTransformer in place for now with a warning in the javadoc. It is a definitely a candidate to remove in the future. http://cr.openjdk.java.net/~alanb/8009645/webrev/ Thanks, -Alan. From Alan.Bateman at oracle.com Fri Mar 8 16:40:01 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 08 Mar 2013 16:40:01 +0000 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: <431B8999-D7AE-42B4-B8F5-734AB8577906@oracle.com> References: <5139E680.6000606@oracle.com> <513A0A35.40809@oracle.com> <431B8999-D7AE-42B4-B8F5-734AB8577906@oracle.com> Message-ID: <513A1461.4090402@oracle.com> On 08/03/2013 16:09, Mike Duigou wrote: > : > Understood. Perhaps we can at least use JDK_FILTER incrementally. Do we have a way to override the warnings used by the makefile? I haven't tried it but Erik suggested in a reply to Dan a few months ago, that is should be possible: http://mail.openjdk.java.net/pipermail/build-dev/2012-December/007427.html > > Any thoughts towards perhaps disabling -Werror but enabling all of the warnings? I think it would just annoy people and make it impossible to see the errors. We'll need to continue to make progress on the warnings and I think can only enable them when they are down to a manageable number, ideally 0. Stuart lead the last few campaigns and may have ideas or plans. -Alan From mandy.chung at oracle.com Fri Mar 8 16:53:11 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 08 Mar 2013 08:53:11 -0800 Subject: 8009645: ClassFileTransformer hooks in ClassLoader no longer required In-Reply-To: <513A118B.5020802@oracle.com> References: <513A118B.5020802@oracle.com> Message-ID: <513A1777.4010302@oracle.com> On 3/8/2013 8:27 AM, Alan Bateman wrote: > > I need a reviewer for a change to remove some crud from > java.lang.ClassLoader. The crud in question is a hook to allow > implementations of sun.misc.ClassFileTransformer be notified when > defineClass fails with a class format error. It was originally added > >10 years ago for Sun's Browser Plug-in to allow it fix up bad > JDK1.1-era class files. I have confirmed that this is no longer needed. > > As always with sun.misc classes it is useful to know if they are used > outside of the JDK. To than end, I checked the data that Mandy > collected on sun.* usage by artifacts in Maven Central. In the case > of ClassFileTransformer, we only found one usage and that was in an > old version of an artifact so it's no longer an issue. Given that > java.lang.instrument has been available since JDK5 then there really > isn't any excuse to be using this class anyway. > > The webrev with the proposed changes is here. I've left > sun.misc.ClassFileTransformer in place for now with a warning in the > javadoc. It is a definitely a candidate to remove in the future. > > http://cr.openjdk.java.net/~alanb/8009645/webrev/ > It's good to see this ancient hack go away. Thumbs up. Mandy From david.dehaven at oracle.com Fri Mar 8 17:45:06 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 8 Mar 2013 09:45:06 -0800 Subject: Define JNIEXPORT as visibility default with GCC? In-Reply-To: References: <511CAE4C.2000002@redhat.com> <4974FD20-B6DD-40F5-A7E9-B78F09E9C2A1@oracle.com> <511D5A8F.7050403@redhat.com> <511E0BD7.4040603@oracle.com> <511E667D.2000700@redhat.com> <51215FE5.1080405@oracle.com> <5121F60C.5040004@redhat.com> <51241726.2040102@oracle.com> Message-ID: <22BDEA76-2AB2-4D0E-914F-202E449BF73B@oracle.com> Those changes look fine to me. None of those typedefs make sense with JNIEXPORT since they're only used locally, and most are scoped to a single function? I agree with the __has_attribute comment. The next step would be to try setting -fvisibility=hidden and -fvisibility-inlines-hidden :) I encountered a few issues trying to get that working. -DrD- > More changes. I discovered that with JNIEXPORT defined to use the > attribute, typedefs that included JNIEXPORT would generate a gcc > -Wattribute warning > warning: visibility attribute ignored. > These new warnings are annoying, but arguably, the use of JNIEXPORT in a > typedef was a bug all along - JNIEXPORT should be all about actual symbols, > not types. > (But I couldn't find any actual spec for JNIEXPORT; could somebody please > fix that?). > So I removed all occurences of JNIEXPORT inside a typedef that caused a > -Wattribute warning. > > http://cr.openjdk.java.net/~martin/webrevs/openjdk8/JNIEXPORT/ > > Martin > > On Tue, Mar 5, 2013 at 5:45 PM, Martin Buchholz wrote: > >> Another rev of this change. >> I added the condition check for gcc > 4.2 >> (I don't much care either way) >> >> I just ran "clang" for the first time, and was surprised that clang has >> values of __GNUC__ == 4 and __GNUC_MINOR__ == 2 >> >> I think we should keep the __has_attribute check, because it seems clearly >> correct and recommended by >> http://clang.llvm.org/docs/LanguageExtensions.html#feature-checking-macros >> and with luck, __has_attribute will become a minor industry standard from >> the innovators in llvm-land. >> I really like the design of their extension mechanisms. >> >> >> >> On Wed, Feb 27, 2013 at 3:07 PM, Martin Buchholz wrote: >> >>> Here's the latest version of the proposed patch: >>> >>> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/JNIEXPORT/ >>> >>> that has been tested, but only with gcc 4.6, >>> but is also written to work with llvm. >>> >> >> From iris.clark at oracle.com Fri Mar 8 17:57:41 2013 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 8 Mar 2013 09:57:41 -0800 (PST) Subject: 8009645: ClassFileTransformer hooks in ClassLoader no longer required In-Reply-To: <513A118B.5020802@oracle.com> References: <513A118B.5020802@oracle.com> Message-ID: <70a2db64-584b-41c9-a17c-1a90a65c6bc1@default> > http://cr.openjdk.java.net/~alanb/8009645/webrev/ Wow. I remember when this code was new. So happy to see it going. The changes look great to me! Thanks, iris From coleen.phillimore at oracle.com Fri Mar 8 18:31:40 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Fri, 08 Mar 2013 13:31:40 -0500 Subject: Define JNIEXPORT as visibility default with GCC? In-Reply-To: <512FC497.9080400@oracle.com> References: <511CAE4C.2000002@redhat.com> <4974FD20-B6DD-40F5-A7E9-B78F09E9C2A1@oracle.com> <511D5A8F.7050403@redhat.com> <511E0BD7.4040603@oracle.com> <511E667D.2000700@redhat.com> <51215FE5.1080405@oracle.com> <5121F60C.5040004@redhat.com> <51241726.2040102@oracle.com> <0ED8D7F6-1541-46C0-81AE-46FA0CBFE423@oracle.com> <512FC497.9080400@oracle.com> Message-ID: <513A2E8C.8090009@oracle.com> The hotspot definitions of JNIEXPORT don't match in all the files to the JDK definition. I think a hotspot bug should be filed to fix the jni_.h definitions which now none of them match. After someone in core-libs checks this in, we'll update the hotspot files to match the final version and retest -fvisibility=hidden. I don't remember why the JDK version wasn't fixed with the original -fvisibility=hidden work. Coleen On 2/28/2013 3:56 PM, Daniel D. Daugherty wrote: > On 2/28/13 11:57 AM, David DeHaven wrote: >> Has a bug been filed for this? -DrD- > > As mentioned earlier in this thread... > > Dan > > > > On 2/19/13 5:21 PM, Daniel D. Daugherty wrote: >> I couldn't find a 'jdk' repo relevant bug for this issue so I filed: >> >> 8008509: 6588413 changed JNIEXPORT visibility for GCC on HSX, jdk's >> jni_md.h needs similar change >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008509 >> https://jbs.oracle.com/bugs/browse/JDK-8008509 >> >> Coleen did the original work on 6588413 so I added her to the "interest >> list" for the new bug. The need for an update to the jdk repo's jni_md.h >> file was raised during the code review for 6588413, but that detail >> appears >> to have been dropped. >> >> Dan From alan.bateman at oracle.com Fri Mar 8 19:59:54 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 08 Mar 2013 19:59:54 +0000 Subject: hg: jdk8/tl/jdk: 8009645: ClassFileTransformer hooks in ClassLoader no longer required Message-ID: <20130308200022.69D2248014@hg.openjdk.java.net> Changeset: 01908630df14 Author: alanb Date: 2013-03-08 19:51 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01908630df14 8009645: ClassFileTransformer hooks in ClassLoader no longer required Reviewed-by: mchung, iris ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/sun/misc/ClassFileTransformer.java From mike.duigou at oracle.com Fri Mar 8 20:26:39 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 8 Mar 2013 12:26:39 -0800 Subject: RFR : JDK-8001642 : Add Optional, OptionalDouble, OptionalInt, OptionalLong In-Reply-To: <51360B5F.8080904@oracle.com> References: <51360B5F.8080904@oracle.com> Message-ID: <4A0CACB1-BA80-4E88-B322-9C6B91D1347E@oracle.com> On Mar 5 2013, at 07:12 , Alan Bateman wrote: > Just a couple of small things. > > Will the docs build complain about the unknown taglets? (@apiNote, @implNote ...) It currently issues a warning. I have a Javadoc.gmk patch which I am pursuing separately to enable recognition of these tags. > Are you planning to include a test? I realize this will get a good workout once the streams work come in. Now added. Thanks! From lowasser at google.com Fri Mar 8 20:29:02 2013 From: lowasser at google.com (Louis Wasserman) Date: Fri, 8 Mar 2013 12:29:02 -0800 Subject: RFR : JDK-8001642 : Add Optional, OptionalDouble, OptionalInt, OptionalLong In-Reply-To: <4A0CACB1-BA80-4E88-B322-9C6B91D1347E@oracle.com> References: <51360B5F.8080904@oracle.com> <4A0CACB1-BA80-4E88-B322-9C6B91D1347E@oracle.com> Message-ID: IIRC, there have already been centithreads discussing Optional; I don't think the final decision is likely to change at this point. On Fri, Mar 8, 2013 at 12:26 PM, Mike Duigou wrote: > > On Mar 5 2013, at 07:12 , Alan Bateman wrote: > > > Just a couple of small things. > > > > Will the docs build complain about the unknown taglets? (@apiNote, > @implNote ...) > > It currently issues a warning. I have a Javadoc.gmk patch which I am > pursuing separately to enable recognition of these tags. > > > Are you planning to include a test? I realize this will get a good > workout once the streams work come in. > > Now added. > > Thanks! -- Louis Wasserman From mandy.chung at oracle.com Fri Mar 8 20:41:35 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 08 Mar 2013 12:41:35 -0800 Subject: RFR: 8002070 Remove the stack search for a resource bundle for Logger to use In-Reply-To: <5136438B.9070205@oracle.com> References: <51311CC4.5000106@oracle.com> <51335B15.9070809@oracle.com> <5136438B.9070205@oracle.com> Message-ID: <513A4CFF.50002@oracle.com> On 3/5/2013 11:12 AM, Jim Gish wrote: >> For the LoggerResourceBundleRace test then does it have to run in its >> own VM? > Because we no longer search up the stack for the bundles, this test > fails unless run in its own vm. However, to avoid this, I'll try to > change the test to set the context classloader. I discussed with Jim. In jtreg samevm mode, the testclasses are not in the classpath and thus the system classloader can't find the resource bundle. Before the fix, the test finds the resource bundle using the classloader on the stack which isn't the intent. Mandy From jim.gish at oracle.com Fri Mar 8 22:39:57 2013 From: jim.gish at oracle.com (Jim Gish) Date: Fri, 08 Mar 2013 17:39:57 -0500 Subject: RFR: 8002070 Remove the stack search for a resource bundle for Logger to use In-Reply-To: <513A4CFF.50002@oracle.com> References: <51311CC4.5000106@oracle.com> <51335B15.9070809@oracle.com> <5136438B.9070205@oracle.com> <513A4CFF.50002@oracle.com> Message-ID: <513A68BD.7090805@oracle.com> I've update the webrev with the suggested changes: http://cr.openjdk.java.net/~jgish/Bug8002070-RemoveResourceBundleStackSearch/ Thanks, Jim On 03/08/2013 03:41 PM, Mandy Chung wrote: > On 3/5/2013 11:12 AM, Jim Gish wrote: >>> For the LoggerResourceBundleRace test then does it have to run in >>> its own VM? >> Because we no longer search up the stack for the bundles, this test >> fails unless run in its own vm. However, to avoid this, I'll try to >> change the test to set the context classloader. > > I discussed with Jim. In jtreg samevm mode, the testclasses are not > in the classpath and thus the system classloader can't find the > resource bundle. Before the fix, the test finds the resource bundle > using the classloader on the stack which isn't the intent. > > Mandy -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From mandy.chung at oracle.com Fri Mar 8 22:51:48 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 08 Mar 2013 14:51:48 -0800 Subject: RFR: 8002070 Remove the stack search for a resource bundle for Logger to use In-Reply-To: <513A68BD.7090805@oracle.com> References: <51311CC4.5000106@oracle.com> <51335B15.9070809@oracle.com> <5136438B.9070205@oracle.com> <513A4CFF.50002@oracle.com> <513A68BD.7090805@oracle.com> Message-ID: <513A6B84.6080306@oracle.com> On 3/8/2013 2:39 PM, Jim Gish wrote: > I've update the webrev with the suggested changes: > http://cr.openjdk.java.net/~jgish/Bug8002070-RemoveResourceBundleStackSearch/ > > Thumbs up. Thanks for adding the comment in the test. I'd suggest to take out the statement about "stack walk search" since this may be confusing to others who read it as that code will no longer exist. Please add this bug ID to @bug. thanks Mandy > Thanks, > Jim > > > On 03/08/2013 03:41 PM, Mandy Chung wrote: >> On 3/5/2013 11:12 AM, Jim Gish wrote: >>>> For the LoggerResourceBundleRace test then does it have to run in >>>> its own VM? >>> Because we no longer search up the stack for the bundles, this test >>> fails unless run in its own vm. However, to avoid this, I'll try to >>> change the test to set the context classloader. >> >> I discussed with Jim. In jtreg samevm mode, the testclasses are not >> in the classpath and thus the system classloader can't find the >> resource bundle. Before the fix, the test finds the resource bundle >> using the classloader on the stack which isn't the intent. >> >> Mandy > > -- > Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 > Oracle Java Platform Group | Core Libraries Team > 35 Network Drive > Burlington, MA 01803 > jim.gish at oracle.com From mike.duigou at oracle.com Fri Mar 8 23:46:28 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Fri, 08 Mar 2013 23:46:28 +0000 Subject: hg: jdk8/tl/jdk: 8001667: Comparator combinators and extension methods Message-ID: <20130308234653.BB4EA48025@hg.openjdk.java.net> Changeset: e38b46041049 Author: mduigou Date: 2013-03-08 15:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e38b46041049 8001667: Comparator combinators and extension methods Reviewed-by: mduigou, briangoetz Contributed-by: henry.jen at oracle.com ! make/java/java/FILES_java.gmk ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/Comparator.java + src/share/classes/java/util/Comparators.java ! test/java/util/Collections/ReverseOrder.java + test/java/util/ComparatorsTest.java From bradford.wetmore at oracle.com Sat Mar 9 00:25:56 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Fri, 08 Mar 2013 16:25:56 -0800 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: <513A0A96.7080508@oracle.com> References: <5139E680.6000606@oracle.com> <513A0A96.7080508@oracle.com> Message-ID: <513A8194.9040002@oracle.com> I responded in another thread (wasn't aware of this one, sorry), there is an alternate to completely disabling -Werror. On 3/8/2013 7:58 AM, Chris Hegarty wrote: > On 08/03/2013 15:49, Mike Duigou wrote: >> Looks fine to me. > > Thanks Mike. > > > Do we have an issue open for restoring warnings to the new build? > > Not yet, that I am aware of. We really need the ability to set lint > options per package/subpackage. That would be nice. I agree about warning creeping problems. This is a temporary solution, we should soon be fixing the underlying hashcode/equals problems...but... 1. javac tightened hashcode/equals checks 2. new: -Werror is off in the new builds. (i.e. not failing on any lint warnings) 3. old: -Werror is on for the old builds (i.e. is failing for any lint warnings) The proposal is to turn off all errors in the old builds (remove -Werror), essentially making 3 like the 2. Warn but not fatal. We spent a lot of time cleaning up many directories, seems a shame to start allowing non-fatal warnings to come back into previously clean code because people aren't taking the time to fix new warnings as they are introduced. My suggestion was to turn off just the one warning type in 3 *in the old code only* so we can at least continue to build the old without completely disabling -Werror. The new builds will still warn, but the old builds will still fail for all but these override problems. Yes, you lose the warnings in the old, but seems better than completely shutting off erroring. (Ideally it would be nice to warn but not fail on just this one lint option, but don't see how that's possible.) Brad > -Chris. > >> >> Mike >> >> On Mar 8 2013, at 05:24 , Chris Hegarty wrote: >> >>> Since the new build does not enable -Werror when compiling any java >>> code, and disables quite a few lint options, new changes my >>> inadvertently introduce warnings without even realizing. This can >>> cause problems when building with the old build as many areas do >>> compile with -Werror set. Since the old build is on life support, >>> probably best to just completely disable -Werror, so anyone still >>> needing to use it can. >>> >>> diff -r 48b7295f02f8 make/common/shared/Defs-java.gmk >>> --- a/make/common/shared/Defs-java.gmk Thu Mar 07 10:07:13 2013 +0000 >>> +++ b/make/common/shared/Defs-java.gmk Thu Mar 07 11:10:37 2013 +0000 >>> @@ -122,9 +122,10 @@ ifeq ($(JAVAC_MAX_WARNINGS), true) >>> ifeq ($(JAVAC_MAX_WARNINGS), true) >>> JAVAC_LINT_OPTIONS += -Xlint:all >>> endif >>> -ifeq ($(JAVAC_WARNINGS_FATAL), true) >>> - JAVACFLAGS += -Werror >>> -endif >>> +# Disable fatal warnings, 8009517 >>> +#ifeq ($(JAVAC_WARNINGS_FATAL), true) >>> +# JAVACFLAGS += -Werror >>> +#endif >>> >>> # TODO: Workaround for CR 7063027. Remove -path eventually. >>> JAVAC_LINT_OPTIONS += -Xlint:-path >>> >>> -Chris. >> From brian.burkhalter at oracle.com Sat Mar 9 01:21:36 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 8 Mar 2013 17:21:36 -0800 Subject: Review: 7032154 - Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal In-Reply-To: <5139B702.8000803@mindspring.com> References: <611D45A4-8B28-408E-8914-4BCEEB4F883D@oracle.com> <3E47081F-1F08-4A61-8122-FB9209725232@oracle.com> <5D88B1AB-F038-4000-884C-9CAD0BDB9D48@oracle.com> <5139B702.8000803@mindspring.com> Message-ID: <94397EAF-6CE8-4E31-8010-1EAD7E9D30CB@oracle.com> Hello Alan, Thanks for the comments. On Mar 8, 2013, at 2:01 AM, Alan Eliasen wrote: > I notice that the solution introduces yet another version of > BigInteger to add to BigInteger, MutableBigInteger, > SignedMutableBigInteger, and whatever other proprietary classes are > lurking. That should give The Fear to anyone who has to maintain this > code. The comments for the new class don't contain a justification for > yet another class other than "A really, really simple bigint package > tailored to the needs of floating base conversion." I'm not quite sure > what that means. The algorithms are drastically inefficient for large > numbers. In point of fact there is no class introduced and the reason that it looks like there is is the result of the webrev being incomplete for which I apologize. There is a pre-existing class sun.misc.FDBigInt which would be replaced by FDBigInteger. FDBigInt used to be declared within FloatingDecimal.java but was broken out into a separate file by this changeset: changeset: 5991:17384fc6b31f user: ohrstrom date: Mon Oct 29 14:12:37 2012 +0100 summary: 8000970: break out auxiliary classes that will prevent multi-core c If the corrected current patch were applied, the class FDBigInt would be superseded by FDBigInteger. To be a bit more accurate however, FDBigInteger has approximately 792 lines of code (based on cloc) compared with about 330 for FDBigInt, i.e., a net increase of 462 lines. > The comments don't even describe the point of methods. For example, > what does multByPow52 do? Comments like "hope it fits!" don't exactly > inspire confidence either. > > Also, swearing and stuff in > the comments should be filtered out, along with typos like "Chache" etc. I concur that this should be cleaned up before final submission, if that happens. The version posted for review was intended to expose the code for examination but not expected to be the final version. > It should be noted that the multiplication algorithms are O(n^2) and > will certainly be orders of magnitude slower than the new BigInteger > algorithms for large numbers. (Which are stunningly faster than this > class could ever be.) This class is unnecessary, and adds huge > maintenance costs, and is demonstrably orders of magnitude slower for > large numbers. If it contains faster algorithms for some small number > sizes, they should be carefully merged with the pending patches for > BigInteger that have been posted by Timothy Buktu and myself, otherwise > they will just make things much slower, harder to maintain, non-portable > to open projects, and decidedly inferior. > > The algorithms for base conversions that I have developed, along with > the drastically faster multiplication and division and exponentiation > routines that Timothy Buktu and I have developed and posted, will blow > these timings out of the water for perhaps all but small number sizes. > If the new class contains algorithms are more efficient for small number > sizes, that code should be merged into BigInteger, rather than > introducing yet another limited BigInteger class and all of its > liabilities and bugs and maintenance effort. Actually as it stands today the enhanced BigInteger patch for large numbers (4837946) is completely disjoint with the patch (7032154) under discussion here. The latter patch would improve the situation for the cases it attempts to address, viz., double/float <-> String conversion, as Dmitry pointed out. If there are better algorithms from the updated BigInteger class which could be applied to these cases, then great, but that could be done later. There should be adequate time to get all these things done and the sooner this review is completed the sooner things can move along. That is not to say it should move along before it is sufficiently scrutinized and tested, however. The intervening three issues between this one and the BigInteger patch should be able to be dispatched relatively quickly, of course barring unforeseen problems. > MutableBigInteger and SignedMutableBigInteger should probably also be > eliminated. There is little that they do that couldn't be done > approximately as efficiently in BigInteger for small numbers, and vastly > faster for large numbers. This would also improve the performance of > BigDecimal by orders of magnitude for large numbers. (BigDecimal uses > O(n^2) algorithms from MutableBigInteger which makes division of large > numbers very slow.) If this is the case then there should be a follow on issue to track it. It is possible that any such issue could be addressed directly after the BigInteger patch but I would not want to promise that yet. > This new class is 1252 lines of new code, compared to, say 400 lines > of well-tested code for my multiplication improvements to BigInteger > which are orders of magnitude faster for large numbers. Timothy Buktu's > stunning FFT multiplication algorithms (added to the existing BigInteger > class) could add more lines that would turn Java into a best-of-class > language for large integer work. That work should be done first. Well you might be correct, but as mentioned, I have not been working in this area all that long and I am trying to address things in an order which my (hopefully increasing) competence best permits. Although I am sure that you have tested this rigorously I still have to deal with passing it over the usual hurdles and would like to do so with some degree of understanding. Again, it's not a matter of either-or and not a matter of months. At this point I think we are well down into the order of magnitude of some weeks of delay provided there are no surprises which is a lot less time than this has languished to date. Brian From chris.hegarty at oracle.com Sat Mar 9 08:11:39 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 09 Mar 2013 08:11:39 +0000 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: <513A8194.9040002@oracle.com> References: <5139E680.6000606@oracle.com> <513A0A96.7080508@oracle.com> <513A8194.9040002@oracle.com> Message-ID: <513AEEBB.2080900@oracle.com> > I agree about warning creeping problems. This is a temporary solution, > we should soon be fixing the underlying hashcode/equals problems...but... Your temporary solution, -overrides, is just that. It will enable the old build to complete today, but it could fail at any point in the future, as the code changes. For example, java.net is currently warning free, in the old it compiles with fatal warnings enabled. Lets say, in a moment of madness, I add a dependency from java.net.Socket to say java.awt.RenderingHints.Key ( or any class that produces warnings when compiled. I run the new build, all is fine. Push the changes. Now someone else sync's up, but need to build using the old build. If the new dependent class is not already compiled before java.net.Socket gets compiled, it will be compiled implicitly. It's warnings will cause the compile to fail, and the old build will fail. Or much simpler, anyone could write sloppy code with warnings, the new build will suppress them, and they won't notice. Push this code, and the old build will fail if is explicitly, or implicitly, compiles this code with -Werror enabled. > We > spent a lot of time cleaning up many directories, seems a shame to start > allowing non-fatal warnings to come back into previously clean code > because people aren't taking the time to fix new warnings as they are > introduced. I personally spent several weeks over the past number of years fixing warnings and reviewing warning cleanup webrevs from others. I took much pride in keeping certain areas warnings free. It is with great regret that I propose to disable fatal warnings in the old build, but I felt this the best/safest option. I heard much annoyance and frustration from others about hitting seemingly random errors with the old build recently. This is the only sure way to avoid that. > The new builds will still warn, but the > old builds will still fail for all but these override problems. Yes, > you lose the warnings in the old, but seems better than completely > shutting off erroring. I'm ok with that, if others are. To clarify, I think you are suggesting that we keep the old build as it, with -overrides, and use it periodically as a way of tracking new warnings being introduced into areas that were warning free. That is, if the old build fails because of a fatal warning, so be it. File a bug and fix the source code. Then the old build will work again. This means that at any point in time the old build cannot be guaranteed to be buildable. Everyone seems to agree, a solution needs to be found to allow us to keep certain areas warning free. This issue is too important, and too much time was spent, to allow it to regress to the state it was in a few years ago. -Chris. > > (Ideally it would be nice to warn but not fail on just this one lint > option, but don't see how that's possible.) > > Brad > > > > > >> -Chris. >> >>> >>> Mike >>> >>> On Mar 8 2013, at 05:24 , Chris Hegarty wrote: >>> >>>> Since the new build does not enable -Werror when compiling any java >>>> code, and disables quite a few lint options, new changes my >>>> inadvertently introduce warnings without even realizing. This can >>>> cause problems when building with the old build as many areas do >>>> compile with -Werror set. Since the old build is on life support, >>>> probably best to just completely disable -Werror, so anyone still >>>> needing to use it can. >>>> >>>> diff -r 48b7295f02f8 make/common/shared/Defs-java.gmk >>>> --- a/make/common/shared/Defs-java.gmk Thu Mar 07 10:07:13 2013 +0000 >>>> +++ b/make/common/shared/Defs-java.gmk Thu Mar 07 11:10:37 2013 +0000 >>>> @@ -122,9 +122,10 @@ ifeq ($(JAVAC_MAX_WARNINGS), true) >>>> ifeq ($(JAVAC_MAX_WARNINGS), true) >>>> JAVAC_LINT_OPTIONS += -Xlint:all >>>> endif >>>> -ifeq ($(JAVAC_WARNINGS_FATAL), true) >>>> - JAVACFLAGS += -Werror >>>> -endif >>>> +# Disable fatal warnings, 8009517 >>>> +#ifeq ($(JAVAC_WARNINGS_FATAL), true) >>>> +# JAVACFLAGS += -Werror >>>> +#endif >>>> >>>> # TODO: Workaround for CR 7063027. Remove -path eventually. >>>> JAVAC_LINT_OPTIONS += -Xlint:-path >>>> >>>> -Chris. >>> From weijun.wang at oracle.com Sat Mar 9 09:29:54 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Sat, 09 Mar 2013 09:29:54 +0000 Subject: hg: jdk8/tl/jdk: 8000653: SPNEGO tests fail at context.getDelegCred().getRemainingInitLifetime(mechOid) Message-ID: <20130309093019.0384148035@hg.openjdk.java.net> Changeset: 230bafd05509 Author: weijun Date: 2013-03-09 17:27 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/230bafd05509 8000653: SPNEGO tests fail at context.getDelegCred().getRemainingInitLifetime(mechOid) Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/GSSCredentialImpl.java ! src/share/classes/sun/security/jgss/spnego/SpNegoCredElement.java ! test/sun/security/krb5/auto/Context.java + test/sun/security/krb5/auto/SpnegoLifeTime.java From sundararajan.athijegannathan at oracle.com Sun Mar 10 16:01:11 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Sun, 10 Mar 2013 16:01:11 +0000 Subject: hg: jdk8/tl/nashorn: 2 new changesets Message-ID: <20130310160119.3F48E4804E@hg.openjdk.java.net> Changeset: 3d57f57acd9c Author: sundar Date: 2013-03-06 22:38 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/3d57f57acd9c 8009553: Object.create(Array.prototype) doesn't respect reset length Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/objects/Global.java + test/script/basic/JDK-8009553.js Changeset: 5759f600fcf7 Author: sundar Date: 2013-03-09 21:49 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/5759f600fcf7 8009559: clean up method handle lookup code. Reviewed-by: ahgross, jlaskey, attila, sundar ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java ! make/java.security.override ! src/jdk/internal/dynalink/beans/CheckRestrictedPackage.java - src/jdk/internal/dynalink/beans/CheckRestrictedPackageInternal.java ! src/jdk/internal/dynalink/beans/FacetIntrospector.java - src/jdk/internal/dynalink/beans/RestrictedPackageTester.java + src/jdk/internal/dynalink/beans/SafeUnreflector.java + src/jdk/internal/dynalink/beans/SafeUnreflectorImpl.java + src/jdk/internal/dynalink/beans/SandboxClassLoader.java ! src/jdk/internal/dynalink/beans/StaticClassLinker.java + src/jdk/internal/dynalink/beans/sandbox/Unreflector.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java + src/jdk/nashorn/internal/lookup/Lookup.java + src/jdk/nashorn/internal/lookup/MethodHandleFactory.java + src/jdk/nashorn/internal/lookup/MethodHandleFunctionality.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/GlobalFunctions.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/SpillProperty.java ! src/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java - src/jdk/nashorn/internal/runtime/linker/Lookup.java - src/jdk/nashorn/internal/runtime/linker/MethodHandleFactory.java - src/jdk/nashorn/internal/runtime/linker/MethodHandleFunctionality.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuards.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java + test/script/currently-failing/JDK-8006529.js - test/script/trusted/JDK-8006529.js From tbuktu at hotmail.com Sun Mar 10 20:39:43 2013 From: tbuktu at hotmail.com (Tim Buktu) Date: Sun, 10 Mar 2013 21:39:43 +0100 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) Message-ID: Hi, I have updated the patch. It now contains Alan Eliasen's fast square() and pow() implementations. Special characters have been replaced with ASCII ones. Also included is a patched MutableBigInteger which uses the fast division algorithm in BigInteger, and a patched BigDecimal which uses the fast BigInteger.pow() method. Both changes speed up BigDecimal division. BigDecimal division is still much slower than BigInteger division (except BigDecimal.divideAndRound) because it calls doRound(), setScale(), and bigMultiplyPowerTen() which are pretty slow. Maybe these methods can be made more efficient. To view the four patched files (#4 is BigIntegerTest.java) on one page, go to https://gist.github.com/tbuktu/1576025 , or get them individually at https://gist.github.com/tbuktu/1576025/raw/96e9dfd9261862223aa9ff81618f1d85045e85a5/BigInteger.java https://gist.github.com/tbuktu/1576025/raw/447db955ef74b065b03b0b45abd443cea5d7b2c6/MutableBigInteger.java https://gist.github.com/tbuktu/1576025/raw/6863a38032835b48b73cbce5aa833680c881557f/BigDecimal.java https://gist.github.com/tbuktu/1576025/raw/11977be7d001e093baa915b4370f326e30218eec/BigIntegerTest.java Semi-related: I think there is a bug in jdk/test/java/math/BigInteger/CompareToTests.java and jdk/test/java/math/BigDecimal/CompareToTests.java. It prints failures (with or without my patches) but the overall test doesn't fail. Tim From david.holmes at oracle.com Mon Mar 11 01:24:39 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 11 Mar 2013 11:24:39 +1000 Subject: RFR: 8009428 and 8009429 - Profile related fixes and clean ups In-Reply-To: <5139CB49.5000601@oracle.com> References: <51394373.4040404@oracle.com> <5139AD05.1060208@oracle.com> <5139CB49.5000601@oracle.com> Message-ID: <513D3257.2030801@oracle.com> I had overlooked the need to update the ct.sym creation tool to recognize the new syntax in the profile spec file. That process also uncovered a few bugs in the listing that needed correcting. The javadoc generation of compact profile information is not quite right, but that will be handled in a seperate bug. Updated webrevs at: http://cr.openjdk.java.net/~dholmes/8009428_8009429.v2/ --- http://cr.openjdk.java.net/~dholmes/8009428_8009429.v2/webrev.root/ No change from v1. Simply reverses the Nashorn change to $ processing. --- http://cr.openjdk.java.net/~dholmes/8009428_8009429.v2/webrev.langtools/ Updated the logic to look for FULL_JRE instead of PROFILE_4. And as a result of that needed to make the logic explicitly aware that there are 3 compact profiles plus the full JRE. --- http://cr.openjdk.java.net/~dholmes/8009428_8009429.v2/webrev.jdk/ Changes from v1: - I stopped trying to use a new wildcard syntax for included/excluded types. The only options are *.class else a full type name with $ replaced by $$. (The wildcard support would need more extensive changes to the ct.sym tool and for 4 classes it isn't worth it). - Types explicitly excluded from one profile must be explicitly included in a higher one (or the full JRE). (This happened to work by accident because we were dealing with compact3 and a full JRE). - The package sun/beans no longer exists - Fixed up include packages to capture new types ie jdk instead of jdk/internal so that we include the jdk.Supported annotation class - Removed additional redundant sub-packages Thanks for the follow up reviews. Erik's review stands as no further changes made to the actual build logic. David ----- On 8/03/2013 9:28 PM, David Holmes wrote: > On 8/03/2013 7:19 PM, Alan Bateman wrote: >> On 08/03/2013 01:48, David Holmes wrote: >>> Not sure which is best list for this given Alan will likely be the >>> only reviewer anyway :) >>> >>> Webrevs under: >>> >>> http://cr.openjdk.java.net/~dholmes/8009428_8009429/ >> As further background to others, the reverting of the $ substitution >> became possible when Nashorn removed $ from its generated classes [1]. >> >> I've looked through the changes and they look really good to me. Putting >> $< in single quotes to avoid shell expansion is the solution that I >> could not find when adding the de-beaning recipes a few months ago. It's >> great to see PROFILE_4 renamed to FULL_JRE and is also great to remove >> the redundant sub-packages from the include lists. For >> profiles-rtjar-includes then I think it makes it much more readable and >> maintainable. Two minor inconsistencies: the sub-packages of >> javax.naming are listed and com/sun/jndi/ has a trailing slash. > > Fixed - well spotted! > >> One probable side effect of removing the redundant sub-packages will be >> the javadoc. The one case to date where we didn't list sub-packages is >> java.time (because there are still changes going on there) and that the >> result is that the sub-packages of java.time don't show up in the >> profiles view. I created 8008367 a few weeks for that and I suspect that >> once these changes are pushed that the profiles view will be very >> incomplete. I don't think this should be a reason to hold off your >> changes as the profiles view isn't right now anyway. Hopefully Bhavesh >> will get to this soon. > > Now I'm a little concerned. I had not considered whether javac/javadoc > considered these to be complete lists. They have to know how to combine > the includes at a low-level with the excludes of a higher-level - and > potentially vice-versa. > >> I think Erik should review this too as it's important that the build >> changes in jdk8/tl will merge easily with changes going into jdk8/build. > > OK. > > Thanks, > David > >> -Alan. >> >> [1] http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fe5211fc3114 From Alan.Bateman at oracle.com Mon Mar 11 08:54:41 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 Mar 2013 08:54:41 +0000 Subject: RFR: 8009428 and 8009429 - Profile related fixes and clean ups In-Reply-To: <513D3257.2030801@oracle.com> References: <51394373.4040404@oracle.com> <5139AD05.1060208@oracle.com> <5139CB49.5000601@oracle.com> <513D3257.2030801@oracle.com> Message-ID: <513D9BD1.6060807@oracle.com> On 11/03/2013 01:24, David Holmes wrote: > I had overlooked the need to update the ct.sym creation tool to > recognize the new syntax in the profile spec file. That process also > uncovered a few bugs in the listing that needed correcting. > > The javadoc generation of compact profile information is not quite > right, but that will be handled in a seperate bug. > > Updated webrevs at: > > http://cr.openjdk.java.net/~dholmes/8009428_8009429.v2/ The changes to the top-level and jdk repo look good to me. As per my original comments, I'm happy to see profile-rtjar-includes.txt changed to be much easier to maintain. The assumption that jdk.** is in compact1 is okay for now but I'm sure that will need to be changed when that namespace is used more. For the intro comment in profile-rtjar-includes.txt then it might be useful to beef up the comment to explain what happens when an API package does not match one of the rules, ie: does it go into compact1, only the full JRE, or none. Also make it explicit that the form DialogCallbackHandler*.class should not be used. I suggest this for the benefit of someone needing to tweak this in the future. I have played with com.sun.tools.javac.sym.Profiles and so the changes to MakefileProfiles look okay to me but Jon should really be the reviewer for this. One thing about maxProfiles is that it should match Profile.values.length maybe maxProfiles should not be hardcoded to 4. Another thing is whether to add a test or beef up an existing test (ProfileOptionTest.java in particular). -Alan. From erik.joelsson at oracle.com Mon Mar 11 09:30:54 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 11 Mar 2013 10:30:54 +0100 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: <513A0A35.40809@oracle.com> References: <5139E680.6000606@oracle.com> <513A0A35.40809@oracle.com> Message-ID: <513DA44E.9000504@oracle.com> I have a suggestion for how to at least partly enable -Werror in the new build. The penalty is slightly longer compile time, but the difference should be negligible. We split the big java compilation in jdk in two. The first pass with -Werror and all warnings turned on, the second without. We make a list of packages that are passing -Werror and use as include list for the first and exclude list for the second. As you make more packages warning free, we add them to the list. This solution is not as fine grained as a per package configured set of warning flags, but it's much better than we have today. /Erik On 2013-03-08 16:56, Alan Bateman wrote: > On 08/03/2013 15:49, Mike Duigou wrote: >> Looks fine to me. Do we have an issue open for restoring warnings to >> the new build? >> >> Mike >> > I don't know if there is an issue for that yet but as the new build > compiles thousands of classes in a single compilation unit then it > means we will need to make significant inroads on the warnings before > more can be enabled. The approach with the old build was by area and > good progress had been made but with the new build, then it may have > to be by warning type as all areas are compiled together. > > -Alan. > From Alan.Bateman at oracle.com Mon Mar 11 13:40:26 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 Mar 2013 13:40:26 +0000 Subject: Request for review- RFE 8005716 In-Reply-To: <51394B5C.2090306@oracle.com> References: <51367A43.1060606@oracle.com> <513748D4.3080803@oracle.com> <5138C22B.5070803@oracle.com> <5138FDA7.6040108@oracle.com> <51394B5C.2090306@oracle.com> Message-ID: <513DDECA.7090003@oracle.com> On 08/03/2013 02:22, BILL PITTORE wrote: > Moved the string allocation into buildJniFunctionName as Alan > suggested. Built and tested on windows and linux. Updated the webrev: > > http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.02/ > > > bill I see this updates the method descriptions to take on board Jeremy's comment on the possibility of the library being statically linked with the main executable with or without the VM. To be complete, I think this will require an update to the UnstatisfiedLinkError description too. Thanks for moving the sizing/allocation of the function name into buildJniFunctionName as that is cleaner and safer. Is FILENAME_MAX really the right limit to impose? A minor point, but the buffer is overrsized by 1 for the shared library case, I think it should be: len = strlen(sym) + (cname != NULL ? strlen(cname)+1 : 0) + 1 Otherwise, I think the implementation looks good to me. -Alan. From erik.joelsson at oracle.com Mon Mar 11 14:20:08 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 11 Mar 2013 15:20:08 +0100 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: <513DA44E.9000504@oracle.com> References: <5139E680.6000606@oracle.com> <513A0A35.40809@oracle.com> <513DA44E.9000504@oracle.com> Message-ID: <513DE818.1000803@oracle.com> I tried implementing a PoC for this. Without sjavac, it works, except that the first pass must be run without -Werror and the second with. Since we use -implicit:none, this is fine. With sjavac I had to let it compile the full set of classes first and then run a second time (into a different output directory) with just the warning free set of packages. The overhead on my machine was 5 seconds for the second pass. This solution also works without sjavac, but then the overhead is 37 seconds on my machine. Now the question is, do we want to pursue this or not? /Erik On 2013-03-11 10:30, Erik Joelsson wrote: > I have a suggestion for how to at least partly enable -Werror in the > new build. The penalty is slightly longer compile time, but the > difference should be negligible. > > We split the big java compilation in jdk in two. The first pass with > -Werror and all warnings turned on, the second without. We make a list > of packages that are passing -Werror and use as include list for the > first and exclude list for the second. As you make more packages > warning free, we add them to the list. > > This solution is not as fine grained as a per package configured set > of warning flags, but it's much better than we have today. > > /Erik > > On 2013-03-08 16:56, Alan Bateman wrote: >> On 08/03/2013 15:49, Mike Duigou wrote: >>> Looks fine to me. Do we have an issue open for restoring warnings to >>> the new build? >>> >>> Mike >>> >> I don't know if there is an issue for that yet but as the new build >> compiles thousands of classes in a single compilation unit then it >> means we will need to make significant inroads on the warnings before >> more can be enabled. The approach with the old build was by area and >> good progress had been made but with the new build, then it may have >> to be by warning type as all areas are compiled together. >> >> -Alan. >> From chris.hegarty at oracle.com Mon Mar 11 15:00:46 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 11 Mar 2013 15:00:46 +0000 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: <513DE818.1000803@oracle.com> References: <5139E680.6000606@oracle.com> <513A0A35.40809@oracle.com> <513DA44E.9000504@oracle.com> <513DE818.1000803@oracle.com> Message-ID: <513DF19E.9040107@oracle.com> Thank you for trying this Erik. I did think of this "workaround" myself, but felt if might not be acceptable due to the performance penalty. But this information is great to have. I wonder if we should try to get all alternatives/proposals on the table, then make a decision. I know of two other possibilities. 1) Leave things are they are, and use another tool to investigate warnings. From Jon. 2) Explore supporting Package level SuppressWarnings. Then apply to the relevant packages, and enable -Werror in the build. Others? -Chris. On 11/03/2013 14:20, Erik Joelsson wrote: > I tried implementing a PoC for this. Without sjavac, it works, except > that the first pass must be run without -Werror and the second with. > Since we use -implicit:none, this is fine. > > With sjavac I had to let it compile the full set of classes first and > then run a second time (into a different output directory) with just the > warning free set of packages. The overhead on my machine was 5 seconds > for the second pass. This solution also works without sjavac, but then > the overhead is 37 seconds on my machine. > > Now the question is, do we want to pursue this or not? > > /Erik > > On 2013-03-11 10:30, Erik Joelsson wrote: >> I have a suggestion for how to at least partly enable -Werror in the >> new build. The penalty is slightly longer compile time, but the >> difference should be negligible. >> >> We split the big java compilation in jdk in two. The first pass with >> -Werror and all warnings turned on, the second without. We make a list >> of packages that are passing -Werror and use as include list for the >> first and exclude list for the second. As you make more packages >> warning free, we add them to the list. >> >> This solution is not as fine grained as a per package configured set >> of warning flags, but it's much better than we have today. >> >> /Erik >> >> On 2013-03-08 16:56, Alan Bateman wrote: >>> On 08/03/2013 15:49, Mike Duigou wrote: >>>> Looks fine to me. Do we have an issue open for restoring warnings to >>>> the new build? >>>> >>>> Mike >>>> >>> I don't know if there is an issue for that yet but as the new build >>> compiles thousands of classes in a single compilation unit then it >>> means we will need to make significant inroads on the warnings before >>> more can be enabled. The approach with the old build was by area and >>> good progress had been made but with the new build, then it may have >>> to be by warning type as all areas are compiled together. >>> >>> -Alan. >>> From bill.pittore at oracle.com Mon Mar 11 15:37:01 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Mon, 11 Mar 2013 11:37:01 -0400 Subject: Request for review- RFE 8005716 In-Reply-To: <513DDECA.7090003@oracle.com> References: <51367A43.1060606@oracle.com> <513748D4.3080803@oracle.com> <5138C22B.5070803@oracle.com> <5138FDA7.6040108@oracle.com> <51394B5C.2090306@oracle.com> <513DDECA.7090003@oracle.com> Message-ID: <513DFA1D.1000902@oracle.com> On 3/11/2013 9:40 AM, Alan Bateman wrote: > On 08/03/2013 02:22, BILL PITTORE wrote: >> Moved the string allocation into buildJniFunctionName as Alan >> suggested. Built and tested on windows and linux. Updated the webrev: >> >> http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.02/ >> >> >> bill > I see this updates the method descriptions to take on board Jeremy's > comment on the possibility of the library being statically linked with > the main executable with or without the VM. To be complete, I think > this will require an update to the UnstatisfiedLinkError description too. > > Thanks for moving the sizing/allocation of the function name into > buildJniFunctionName as that is cleaner and safer. Is FILENAME_MAX > really the right limit to impose? Maybe JVM_MAXPATHLEN is the better choice. > > A minor point, but the buffer is overrsized by 1 for the shared > library case, I think it should be: > len = strlen(sym) + (cname != NULL ? strlen(cname)+1 : 0) + 1 The +2 covered both cases; but re-wrote it to be the more explicit version above. bill > > Otherwise, I think the implementation looks good to me. > > -Alan. > > > > From vicente.romero at oracle.com Mon Mar 11 15:36:35 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Mon, 11 Mar 2013 15:36:35 +0000 Subject: hg: jdk8/tl/langtools: 6181889: Empty try/finally results in bytecodes being generated Message-ID: <20130311153638.7968E48064@hg.openjdk.java.net> Changeset: c61add6bf8ac Author: vromero Date: 2013-03-11 15:35 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c61add6bf8ac 6181889: Empty try/finally results in bytecodes being generated Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/T6181889/EmptyFinallyTest.java From robert.field at oracle.com Mon Mar 11 17:03:43 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Mon, 11 Mar 2013 17:03:43 +0000 Subject: hg: jdk8/tl/langtools: 8009742: Bad lambda name for lambda in a static initializer or ctor Message-ID: <20130311170347.DC1574806F@hg.openjdk.java.net> Changeset: d0ae21e3a382 Author: rfield Date: 2013-03-11 10:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d0ae21e3a382 8009742: Bad lambda name for lambda in a static initializer or ctor Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/SerializedLambdaInInit.java From Sergey.Bylokhov at oracle.com Mon Mar 11 17:14:32 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 11 Mar 2013 21:14:32 +0400 Subject: Status of 4500542: WeakIdentityHashMap? Message-ID: <513E10F8.7030703@oracle.com> Hello, Everybody. Does anyone know the status of 4500542? http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4500542 It was postponed? I counted at least 3 similar but slightly different internal implementations of it in the jdk. Probably additional option could be added to the WeakHashMap to force it to use == instead of equal? -- Best regards, Sergey. From brian.burkhalter at oracle.com Mon Mar 11 19:51:15 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 11 Mar 2013 12:51:15 -0700 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: References: Message-ID: Hi Tim, On Mar 10, 2013, at 1:39 PM, Tim Buktu wrote: > I have updated the patch. It now contains Alan Eliasen's fast square() > and pow() implementations. > Special characters have been replaced with ASCII ones. > > Also included is a patched MutableBigInteger which uses the fast > division algorithm in BigInteger, and a patched BigDecimal which uses > the fast BigInteger.pow() method. Both changes speed up BigDecimal division. > BigDecimal division is still much slower than BigInteger division > (except BigDecimal.divideAndRound) because it calls doRound(), > setScale(), and bigMultiplyPowerTen() which are pretty slow. Maybe these > methods can be made more efficient. > > To view the four patched files (#4 is BigIntegerTest.java) on one page, > go to > > https://gist.github.com/tbuktu/1576025 , > > or get them individually at > > https://gist.github.com/tbuktu/1576025/raw/96e9dfd9261862223aa9ff81618f1d85045e85a5/BigInteger.java > https://gist.github.com/tbuktu/1576025/raw/447db955ef74b065b03b0b45abd443cea5d7b2c6/MutableBigInteger.java > https://gist.github.com/tbuktu/1576025/raw/6863a38032835b48b73cbce5aa833680c881557f/BigDecimal.java > https://gist.github.com/tbuktu/1576025/raw/11977be7d001e093baa915b4370f326e30218eec/BigIntegerTest.java That is awesome: thank you so much! We are working towards getting this in before long as indicated in other messages. > Semi-related: I think there is a bug in > jdk/test/java/math/BigInteger/CompareToTests.java and > jdk/test/java/math/BigDecimal/CompareToTests.java. It prints failures > (with or without my patches) but the overall test doesn't fail. Thanks for the pointer: will check it out. Regards, Brian From philip.race at oracle.com Mon Mar 11 20:22:29 2013 From: philip.race at oracle.com (Phil Race) Date: Mon, 11 Mar 2013 13:22:29 -0700 Subject: [8] Review request for CR 7145406 - [macosx] Migrate Apple tests from macosx-port to 7u In-Reply-To: <513E3978.2000109@oracle.com> References: <512B3412.1090500@oracle.com> <512B7ED2.8040608@oracle.com> <512E0E16.4060708@oracle.com> <512F5553.5030105@oracle.com> <512F5FBB.7030203@oracle.com> <512F61EA.9080102@oracle.com> <512F6B44.3080808@oracle.com> <513065BB.5070707@oracle.com> <513073D7.9030108@oracle.com> <513074FA.2040804@oracle.com> <51308269.5070500@oracle.com> <51347B0B.4040709@oracle.com> <5137251A.4000607@oracle.com> <513D9DDE.3010600@oracle.com> <513E3632.20502@oracle.com> <513E3978.2000109@oracle.com> Message-ID: <513E3D05.8080209@oracle.com> On 3/11/2013 1:07 PM, Konstantin Shefov wrote: > All these tests compile and run under all OSs, not MacOS only. I find that very difficult to believe. \re\jdk\8\promoted\latest\binaries\windows-i586\bin\javac APIPresent.java APIPresent.java:31: error: package com.apple.eio does not exist import com.apple.eio.FileManager; > There are a lot of awt and swing tests that depend on > test.java.awt.regtesthelpers, they are in the openjdk repo. This is true although that is news to me, I presume this is guaranteed to be compiled automatically when you compile the main test. > Almost none of regression tests are ever run without JTREG. That's not true. I've been running and writing reg. tests for 12 years and I use jtreg less than 0.01% of the time .. as in I can't remember last time I needed to use it. That's the biggest plus we have here. You don't *need* a big horrible useless harness that obscures the real test. I object strongly to junit dependencies in any of the tests. -phil. > > Konstantin > > 11.03.2013 23:53, Phil Race ?????: >> Konstantin, >> >> First I am puzzled by the decision to send this to AWT and Swing lists. >> There are a couple of Swing tests and a large number of AWT tests >> but it seems to be also a very large number of 2D/graphics tests PLUS >> a large scattering in other areas such as >> - hotspot/managment >> - jndi >> - java.io >> - java.nio >> - threading >> - reflection >> - networking. >> >> Next, I am surprised to see jtreg tests that depend on junit. >> >> I just searched our entire regression test suite (including ones that >> are still closed for various reasons) and I didn't find *any* client >> area >> tests that have this dependency. >> >> All I found are a few core java reflection tests. >> Nor should these tests depend on the harness in "package test.java.awt" >> >> So they should all be standalone tests that can be run without any >> harness. >> >> On top of that I seriously doubt that these all even *compile* on >> anything >> besides OS X, and may not pass elsewhere either >> >> cf : 31 import com.apple.eio.FileManager; >> As it is none of this appears appropriate to put into the test >> directory. >> >> So this >> 1) First needs to be rid of harness dependencies >> 2) Needs to be made to compile on all platforms or invoked by a script >> which builds only on OS X >> 3) All tests that build on all platforms must pass on all platforms >> 4) The review needs to be send to all affected lists - which is >> pretty much all of them! >> awt, 2d, swing, hotspot, core-libs .. maybe more >> >> -phil. >> >> >> >> On 3/11/2013 2:03 AM, Konstantin Shefov wrote: >>> Please, review the fix. >>> >>> On 06-Mar-13 15:14, Konstantin Shefov wrote: >>>> http://cr.openjdk.java.net/~kshefov/7145406/webrev.02/ >>>> >>>> Changed tags to @run junit >>>> >>>> On 04-Mar-13 14:44, Sergey Bylokhov wrote: >>>>> A few options exists: >>>>> 1 Changes tag to @run junit + jtreg 4.1 >>>>> 2 Remove usage of junit from these tests. >>>>> >>>>> 01.03.2013 14:26, Alexander Scherbatiy ?????: >>>>>> On 3/1/2013 1:29 PM, Konstantin Shefov wrote: >>>>>>> >>>>>>> On 01-Mar-13 13:24, Sergey Bylokhov wrote: >>>>>>>> 01.03.2013 12:24, Konstantin Shefov wrote: >>>>>>>>> I have already ran those tests on Windows before sending this >>>>>>>>> request, all is OK 95% pass. >>>>>>>>> >>>>>>>>> I should also note that we (STT regression team) use JTREG 3.2 >>>>>>>>> for testing with option >>>>>>>>> -cpa:$JEMMY_PATH/jemmy.jar,$JUNIT_PATH/junit.jar >>>>>>>> As far as I understand, jtreg 3 doesn't contain junit.jar. >>>>>>> There is no junit.jar in JTREG 3, but it could be taken elsewhere. >>>>>>> But if it is standard to use @run junit tag, we will replace >>>>>>> jtreg we use to version 4.1. >>>>>> >>>>>> The jtreg 3 does not have fix for the issue "7113599 jtreg >>>>>> should handle GNOME_DESKTOP_SESSION_ID" which affects some L&F >>>>>> Swing tests on Unix systems. >>>>>> >>>>>> I would suggest to use the JTreg 4.1. The standard is to use >>>>>> the @run junit tag for the JTReg 4.1 (in other case the junit lib >>>>>> is not put to the test JDK classpath). >>>>>> The junit.jar has been removed from the JTReg 4.1 lib >>>>>> directory because of the licensing reasons: >>>>>> https://blogs.oracle.com/jjg/entry/jtreg_update1 >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>>>>> JTREG 3.2 is more stable than 4.1. We do not use JTREG 4.1. So >>>>>>>>> I suggest NOT to replace @run main to @run juint, and, istead >>>>>>>>> of that add jtreg option -cpa:$JUNIT_PATH/junit.jar >>>>>>>>> >>>>>>>>> On 28-Feb-13 18:35, Sergey Bylokhov wrote: >>>>>>>>>> Hi, Konstantin. >>>>>>>>>> I think yes. Please try to run these tests on windows as >>>>>>>>>> well. At least they should be compiled. >>>>>>>>>> >>>>>>>>>> 28.02.2013 17:55, Konstantin Shefov wrote: >>>>>>>>>>> I used JTREG 4.1 fcs b03, not b05. Indeed, if one uses b05, >>>>>>>>>>> one gets compilation errors. So should I replace @run main >>>>>>>>>>> to @run juint in all 150 tests? >>>>>>>>>>> >>>>>>>>>>> On 28-Feb-13 17:46, Konstantin Shefov wrote: >>>>>>>>>>>> Strange, but I used JTReg 4.1 b05 also and I had no >>>>>>>>>>>> compilation errors. JUnit is automatically added in the >>>>>>>>>>>> latest JTREG 4.1. >>>>>>>>>>>> >>>>>>>>>>>> On 28-Feb-13 17:02, Alexander Scherbatiy wrote: >>>>>>>>>>>>> On 2/27/2013 5:45 PM, Konstantin Shefov wrote: >>>>>>>>>>>>>> I replaced Thread.sleep() with toolkit.realSync() and >>>>>>>>>>>>>> made swing mwthod to run on EDT. >>>>>>>>>>>>>> >>>>>>>>>>>>>> New webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~kshefov/7145406/webrev.01 >>>>>>>>>>>>>>> test/javax/swing/JComponent/DoublePaint/TestDoublePaint.java >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Is it possible to run the test with jtreg or JUnit >>>>>>>>>>>>>>> is necessary for the test invocation? >>>>>>>>>>>>> >>>>>>>>>>>>> I run the test and got the compilation error: >>>>>>>>>>>>> TestDoublePaint.java:34: error: package junit.framework >>>>>>>>>>>>> does not exist. >>>>>>>>>>>>> It seems it is because the '@run main TestDoublePaint' >>>>>>>>>>>>> jtreg task does not put the junit jar to the test jdk >>>>>>>>>>>>> class path. >>>>>>>>>>>>> The '@run junit TestDoublePaint' task passes the test. >>>>>>>>>>>>> (I use the JTReg 4.1 b05 from >>>>>>>>>>>>> http://download.java.net/openjdk/jtreg/) >>>>>>>>>>>>> It is also interesting is it necessary to have the >>>>>>>>>>>>> main method for the junit task? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> >>>>>>>>>>>>>>> - line: 68 Thread.sleep(2000); // 2 seconds should >>>>>>>>>>>>>>> be plenty enough to catch 2 repaints >>>>>>>>>>>>>>> Is it possible to use the toolkit.realSync() >>>>>>>>>>>>>>> method here? >>>>>>>>>>>>>>> - Swing classes should be created and used on the EDT. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Konstantin >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> > From philip.race at oracle.com Mon Mar 11 20:53:44 2013 From: philip.race at oracle.com (Phil Race) Date: Mon, 11 Mar 2013 13:53:44 -0700 Subject: [8] Review request for CR 7145406 - [macosx] Migrate Apple tests from macosx-port to 7u In-Reply-To: <513E425A.4030504@oracle.com> References: <512B3412.1090500@oracle.com> <512B7ED2.8040608@oracle.com> <512E0E16.4060708@oracle.com> <512F5553.5030105@oracle.com> <512F5FBB.7030203@oracle.com> <512F61EA.9080102@oracle.com> <512F6B44.3080808@oracle.com> <513065BB.5070707@oracle.com> <513073D7.9030108@oracle.com> <513074FA.2040804@oracle.com> <51308269.5070500@oracle.com> <51347B0B.4040709@oracle.com> <5137251A.4000607@oracle.com> <513D9DDE.3010600@oracle.com> <513E3632.20502@oracle.com> <513E3978.2000109@oracle.com> <513E3D05.8080209@oracle.com> <513E425A.4030504@oracle.com> Message-ID: <513E4458.7090500@oracle.com> Konstantin, On 3/11/2013 1:45 PM, Konstantin Shefov wrote: > Phil, > > 12.03.2013 0:22, Phil Race wrote: >> On 3/11/2013 1:07 PM, Konstantin Shefov wrote: >>> All these tests compile and run under all OSs, not MacOS only. >> >> I find that very difficult to believe. >> >> \re\jdk\8\promoted\latest\binaries\windows-i586\bin\javac >> APIPresent.java >> APIPresent.java:31: error: package com.apple.eio does not exist >> import com.apple.eio.FileManager; >> > > Yes, there are actually 6 tests with com.apple.* packages, but the > total number is about 150, I can send you a pass log on windows and > linux later. > >>> There are a lot of awt and swing tests that depend on >>> test.java.awt.regtesthelpers, they are in the openjdk repo. >> >> This is true although that is news to me, I presume this is >> guaranteed to >> be compiled automatically when you compile the main test. >> > > No main test exists, JTREG tags like "@library DIRECTORY_PATH" "@build > CLASS_NAME" make this test.java.awt.regtesthelpers stuff to compile > for every single test. ' By main test, I mean whatever jtreg test imports these classes/packages. > >>> Almost none of regression tests are ever run without JTREG. >> >> That's not true. I've been running and writing reg. tests for 12 years >> and I use jtreg less than 0.01% of the time .. as in I can't remember >> last time I needed to use it. That's the biggest plus we have here. >> You don't *need* a big horrible useless harness that obscures >> the real test. I object strongly to junit dependencies in any of the >> tests. > > SQE teams run automated tests using JTREG rather often (if not > always). Even manual tests are run with JTREG. Right, its just not true that everyone works the same way. > > So do you suggest to remove junit from all these tests? All these > tests depend on junit. That is what I am suggesting. -phil. > > -Konstantin > >> >> -phil. >> >>> >>> Konstantin >>> >>> 11.03.2013 23:53, Phil Race wrote: >>>> Konstantin, >>>> >>>> First I am puzzled by the decision to send this to AWT and Swing >>>> lists. >>>> There are a couple of Swing tests and a large number of AWT tests >>>> but it seems to be also a very large number of 2D/graphics tests PLUS >>>> a large scattering in other areas such as >>>> - hotspot/managment >>>> - jndi >>>> - java.io >>>> - java.nio >>>> - threading >>>> - reflection >>>> - networking. >>>> >>>> Next, I am surprised to see jtreg tests that depend on junit. >>>> >>>> I just searched our entire regression test suite (including ones that >>>> are still closed for various reasons) and I didn't find *any* >>>> client area >>>> tests that have this dependency. >>>> >>>> All I found are a few core java reflection tests. >>>> Nor should these tests depend on the harness in "package >>>> test.java.awt" >>>> >>>> So they should all be standalone tests that can be run without any >>>> harness. >>>> >>>> On top of that I seriously doubt that these all even *compile* on >>>> anything >>>> besides OS X, and may not pass elsewhere either >>>> >>>> cf : 31 import com.apple.eio.FileManager; >>>> As it is none of this appears appropriate to put into the test >>>> directory. >>>> >>>> So this >>>> 1) First needs to be rid of harness dependencies >>>> 2) Needs to be made to compile on all platforms or invoked by a script >>>> which builds only on OS X >>>> 3) All tests that build on all platforms must pass on all platforms >>>> 4) The review needs to be send to all affected lists - which is >>>> pretty much all of them! >>>> awt, 2d, swing, hotspot, core-libs .. maybe more >>>> >>>> -phil. >>>> >>>> >>>> >>>> On 3/11/2013 2:03 AM, Konstantin Shefov wrote: >>>>> Please, review the fix. >>>>> >>>>> On 06-Mar-13 15:14, Konstantin Shefov wrote: >>>>>> http://cr.openjdk.java.net/~kshefov/7145406/webrev.02/ >>>>>> >>>>>> Changed tags to @run junit >>>>>> >>>>>> On 04-Mar-13 14:44, Sergey Bylokhov wrote: >>>>>>> A few options exists: >>>>>>> 1 Changes tag to @run junit + jtreg 4.1 >>>>>>> 2 Remove usage of junit from these tests. >>>>>>> >>>>>>> 01.03.2013 14:26, Alexander Scherbatiy ?????: >>>>>>>> On 3/1/2013 1:29 PM, Konstantin Shefov wrote: >>>>>>>>> >>>>>>>>> On 01-Mar-13 13:24, Sergey Bylokhov wrote: >>>>>>>>>> 01.03.2013 12:24, Konstantin Shefov wrote: >>>>>>>>>>> I have already ran those tests on Windows before sending >>>>>>>>>>> this request, all is OK 95% pass. >>>>>>>>>>> >>>>>>>>>>> I should also note that we (STT regression team) use JTREG >>>>>>>>>>> 3.2 for testing with option >>>>>>>>>>> -cpa:$JEMMY_PATH/jemmy.jar,$JUNIT_PATH/junit.jar >>>>>>>>>> As far as I understand, jtreg 3 doesn't contain junit.jar. >>>>>>>>> There is no junit.jar in JTREG 3, but it could be taken >>>>>>>>> elsewhere. >>>>>>>>> But if it is standard to use @run junit tag, we will replace >>>>>>>>> jtreg we use to version 4.1. >>>>>>>> >>>>>>>> The jtreg 3 does not have fix for the issue "7113599 jtreg >>>>>>>> should handle GNOME_DESKTOP_SESSION_ID" which affects some L&F >>>>>>>> Swing tests on Unix systems. >>>>>>>> >>>>>>>> I would suggest to use the JTreg 4.1. The standard is to >>>>>>>> use the @run junit tag for the JTReg 4.1 (in other case the >>>>>>>> junit lib is not put to the test JDK classpath). >>>>>>>> The junit.jar has been removed from the JTReg 4.1 lib >>>>>>>> directory because of the licensing reasons: >>>>>>>> https://blogs.oracle.com/jjg/entry/jtreg_update1 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>>>>> JTREG 3.2 is more stable than 4.1. We do not use JTREG 4.1. >>>>>>>>>>> So I suggest NOT to replace @run main to @run juint, and, >>>>>>>>>>> istead of that add jtreg option -cpa:$JUNIT_PATH/junit.jar >>>>>>>>>>> >>>>>>>>>>> On 28-Feb-13 18:35, Sergey Bylokhov wrote: >>>>>>>>>>>> Hi, Konstantin. >>>>>>>>>>>> I think yes. Please try to run these tests on windows as >>>>>>>>>>>> well. At least they should be compiled. >>>>>>>>>>>> >>>>>>>>>>>> 28.02.2013 17:55, Konstantin Shefov wrote: >>>>>>>>>>>>> I used JTREG 4.1 fcs b03, not b05. Indeed, if one uses >>>>>>>>>>>>> b05, one gets compilation errors. So should I replace @run >>>>>>>>>>>>> main to @run juint in all 150 tests? >>>>>>>>>>>>> >>>>>>>>>>>>> On 28-Feb-13 17:46, Konstantin Shefov wrote: >>>>>>>>>>>>>> Strange, but I used JTReg 4.1 b05 also and I had no >>>>>>>>>>>>>> compilation errors. JUnit is automatically added in the >>>>>>>>>>>>>> latest JTREG 4.1. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 28-Feb-13 17:02, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>> On 2/27/2013 5:45 PM, Konstantin Shefov wrote: >>>>>>>>>>>>>>>> I replaced Thread.sleep() with toolkit.realSync() and >>>>>>>>>>>>>>>> made swing mwthod to run on EDT. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> New webrev: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~kshefov/7145406/webrev.01 >>>>>>>>>>>>>>>>> test/javax/swing/JComponent/DoublePaint/TestDoublePaint.java >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - Is it possible to run the test with jtreg or >>>>>>>>>>>>>>>>> JUnit is necessary for the test invocation? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I run the test and got the compilation error: >>>>>>>>>>>>>>> TestDoublePaint.java:34: error: package junit.framework >>>>>>>>>>>>>>> does not exist. >>>>>>>>>>>>>>> It seems it is because the '@run main >>>>>>>>>>>>>>> TestDoublePaint' jtreg task does not put the junit jar >>>>>>>>>>>>>>> to the test jdk class path. >>>>>>>>>>>>>>> The '@run junit TestDoublePaint' task passes the >>>>>>>>>>>>>>> test. (I use the JTReg 4.1 b05 from >>>>>>>>>>>>>>> http://download.java.net/openjdk/jtreg/) >>>>>>>>>>>>>>> It is also interesting is it necessary to have the >>>>>>>>>>>>>>> main method for the junit task? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - line: 68 Thread.sleep(2000); // 2 seconds >>>>>>>>>>>>>>>>> should be plenty enough to catch 2 repaints >>>>>>>>>>>>>>>>> Is it possible to use the toolkit.realSync() >>>>>>>>>>>>>>>>> method here? >>>>>>>>>>>>>>>>> - Swing classes should be created and used on the EDT. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Konstantin >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From brian.goetz at oracle.com Mon Mar 11 21:55:01 2013 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 11 Mar 2013 17:55:01 -0400 Subject: Code review request: JDK-8008670 (partial java.util.stream implementation) In-Reply-To: <51267293.4060203@oracle.com> References: <51267293.4060203@oracle.com> Message-ID: <513E52B5.5060105@oracle.com> I've posted an updated webrev incorporating comments received to date: http://cr.openjdk.java.net/~briangoetz/jdk-8008670.2/webrev/ On 2/21/2013 2:16 PM, Brian Goetz wrote: > At: > http://cr.openjdk.java.net/~briangoetz/jdk-8008670/webrev/ > > there is a webrev of a subset of the implementation of java.util.stream, > for review. These are all new files. None of these are public classes; > they are internal interfaces for the Stream library, as well as some > implementation classes. This is about half the classes in the Streams > package. > > (The webrev includes changes to Map, but those are being reviewed > separately, so just ignore those.) > > We're asking people to focus their review on both the quality of API > specification for these internal APIs, and the quality of implementation > of the specified classes. It may not be obvious how some of these work > until you've seen the rest of it, but do what you can. > From ysr1729 at gmail.com Mon Mar 11 23:11:10 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Mon, 11 Mar 2013 16:11:10 -0700 Subject: Mismatch between JDK and JVM re largest byte array that VM can allocate? Message-ID: I am looking at code in (for example) ByteArrayOutputStream.java :- 96 /** 97 * Increases the capacity to ensure that it can hold at least the 98 * number of elements specified by the minimum capacity argument. 99 * 100 * @param minCapacity the desired minimum capacity 101 */ 102 private void grow(int minCapacity) { 103 // overflow-conscious code 104 int oldCapacity = buf.length; 105 int newCapacity = oldCapacity << 1; 106 if (newCapacity - minCapacity < 0) 107 newCapacity = minCapacity; 108 if (newCapacity < 0) { 109 if (minCapacity < 0) // overflow 110 throw new OutOfMemoryError(); 111 newCapacity = Integer.MAX_VALUE; 112 } 113 buf = Arrays.copyOf(buf, newCapacity); 114 } This can result in a request for an array of size Integer.MAX_VALUE (because of line 111 above), see below:- 2874 /** 2875 * Copies the specified array, truncating or padding with zeros (if necessary) 2876 * so the copy has the specified length. For all indices that are 2877 * valid in both the original array and the copy, the two arrays will 2878 * contain identical values. For any indices that are valid in the 2879 * copy but not the original, the copy will contain (byte)0. 2880 * Such indices will exist if and only if the specified length 2881 * is greater than that of the original array. 2882 * 2883 * @param original the array to be copied 2884 * @param newLength the length of the copy to be returned 2885 * @return a copy of the original array, truncated or padded with zeros 2886 * to obtain the specified length 2887 * @throws NegativeArraySizeException if newLength is negative 2888 * @throws NullPointerException if original is null 2889 * @since 1.6 2890 */ 2891 public static byte[] copyOf(byte[] original, int newLength) { 2892 byte[] copy = new byte[newLength]; 2893 System.arraycopy(original, 0, copy, 0, 2894 Math.min(original.length, newLength)); 2895 return copy; 2896 } So the call at line 2892 can cause a request for an array with Integer.MAX_VALUE entries, yet the JVM doesn't give you arrays that large; witness this code in arrayOop.cpp where this will flatten out:- // Return the maximum length of an array of BasicType. The length can passed // to typeArrayOop::object_size(scale, length, header_size) without causing an // overflow. We also need to make sure that this will not overflow a size_t on // 32 bit platforms when we convert it to a byte size. static int32_t max_array_length(BasicType type) { assert(type >= 0 && type < T_CONFLICT, "wrong type"); assert(type2aelembytes(type) != 0, "wrong type"); const size_t max_element_words_per_size_t = align_size_down((SIZE_MAX/HeapWordSize - header_size(type)), MinObjAlignment); const size_t max_elements_per_size_t = HeapWordSize * max_element_words_per_size_t / type2aelembytes(type); if ((size_t)max_jint < max_elements_per_size_t) { // It should be ok to return max_jint here, but parts of the code // (CollectedHeap, Klass::oop_oop_iterate(), and more) uses an int for // passing around the size (in words) of an object. So, we need to avoid // overflowing an int when we add the header. See CRs 4718400 and 7110613. return align_size_down(max_jint - header_size(type), MinObjAlignment); } return (int32_t)max_elements_per_size_t; } Is there any plan to fix this mismatch ? May be it's as simple(!) as checking the GC code to make sure it doesn't traffic in int's and fix the code above to return max_jint for the byte array case as well? I have a vague recollection of a bug id already for this, but it's been a while.... Thanks! -- ramki From pbenedict at apache.org Mon Mar 11 23:13:25 2013 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 11 Mar 2013 18:13:25 -0500 Subject: Code review request: JDK-8008670 (partial java.util.stream implementation) In-Reply-To: <513E52B5.5060105@oracle.com> References: <51267293.4060203@oracle.com> <513E52B5.5060105@oracle.com> Message-ID: My comments... 1) TerminalOp: When default methods are very simple (i.e., a one-liner), you are sometimes (not always) putting the body on a new line. I think you should use a consistent coding style and always start the body on the next line. 2) I find X_IN and X_OUT type parameters to be disruptive to reading. Sticking to a simple "I" and "O" would be much easier to read. 3) StreamShape: Javadoc should be formatted to be within 80 characters. 4) There are plentiful of if() statements that are not using braces. An if() should always use braces per the published Java coding conventions. Paul On Mon, Mar 11, 2013 at 4:55 PM, Brian Goetz wrote: > I've posted an updated webrev incorporating comments received to date: > > http://cr.openjdk.java.net/~briangoetz/jdk-8008670.2/webrev/ > > > > On 2/21/2013 2:16 PM, Brian Goetz wrote: > > At: > > http://cr.openjdk.java.net/~briangoetz/jdk-8008670/webrev/ > > > > there is a webrev of a subset of the implementation of java.util.stream, > > for review. These are all new files. None of these are public classes; > > they are internal interfaces for the Stream library, as well as some > > implementation classes. This is about half the classes in the Streams > > package. > > > > (The webrev includes changes to Map, but those are being reviewed > > separately, so just ignore those.) > > > > We're asking people to focus their review on both the quality of API > > specification for these internal APIs, and the quality of implementation > > of the specified classes. It may not be obvious how some of these work > > until you've seen the rest of it, but do what you can. > > > > From dan.xu at oracle.com Mon Mar 11 23:43:47 2013 From: dan.xu at oracle.com (Dan Xu) Date: Mon, 11 Mar 2013 16:43:47 -0700 Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code In-Reply-To: <513895EF.6040001@oracle.com> References: <50FE3EE5.20600@oracle.com> <5100065A.9080801@oracle.com> <51029C56.9020302@oracle.com> <5106CB48.3010102@oracle.com> <5107B89A.3050400@oracle.com> <510ACEFC.2060607@oracle.com> <510B900B.1030406@oracle.com> <510C008A.2000107@oracle.com> <510C32D2.2080508@oracle.com> <51363BCD.7070700@oracle.com> <51388AB6.4000504@oracle.com> <51389446.1000405@oracle.com> <513895EF.6040001@oracle.com> Message-ID: <513E6C33.7040700@oracle.com> Thanks for all your comments. I have updated the fix accordingly. Please see the webrev at http://cr.openjdk.java.net/~dxu/8001334/webrev.02/. For the language concern in getLastErrorString(char *buf, size_t len) function, I will log another bug and address it later. Thanks! -Dan On Thu 07 Mar 2013 05:28:15 AM PST, Alan Bateman wrote: > On 07/03/2013 13:21, Alexey Utkin wrote: >> Can I say two word about the file >> http://cr.openjdk.java.net/~dxu/8001334/webrev.01/src/windows/native/java/io/io_util_md.c.frames.html >> >> and function >> getLastErrorString(char *buf, size_t len) >> >> Here is the documentation for [FormatMessage]: >> http://msdn.microsoft.com/en-gb/library/windows/desktop/ms679351%28v=vs.85%29.aspx >> >> if you are using ASCII version of FormatMessage that is a good idea >> to have the direct reference to [FormatMessageA], not define. >> >> The second word is about the third world countries: Russia and China. >> Windows OS has localized version. The error messages on that systems >> would contains only [?] in the worst case. >> > It's good to re-examine this but just to mention that this is just > bringing over what is in os::lasterror (in > hotspot/src/os/windows/vm/os_windows.cpp). > > -Alan > From martinrb at google.com Mon Mar 11 23:57:02 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 11 Mar 2013 16:57:02 -0700 Subject: Define JNIEXPORT as visibility default with GCC? In-Reply-To: <513A2E8C.8090009@oracle.com> References: <511CAE4C.2000002@redhat.com> <4974FD20-B6DD-40F5-A7E9-B78F09E9C2A1@oracle.com> <511D5A8F.7050403@redhat.com> <511E0BD7.4040603@oracle.com> <511E667D.2000700@redhat.com> <51215FE5.1080405@oracle.com> <5121F60C.5040004@redhat.com> <51241726.2040102@oracle.com> <0ED8D7F6-1541-46C0-81AE-46FA0CBFE423@oracle.com> <512FC497.9080400@oracle.com> <513A2E8C.8090009@oracle.com> Message-ID: The latest version of my webrev is here: http://cr.openjdk.java.net/~martin/webrevs/openjdk8/JNIEXPORT/ It includes this line: Reviewed-by: coleenp, ddehaven, dcubed Ok to push? On Fri, Mar 8, 2013 at 10:31 AM, Coleen Phillmore < coleen.phillimore at oracle.com> wrote: > > The hotspot definitions of JNIEXPORT don't match in all the files to the > JDK definition. I think a hotspot bug should be filed to fix the > jni_.h definitions which now none of them match. After someone in > core-libs checks this in, we'll update the hotspot files to match the final > version and retest -fvisibility=hidden. > > I don't remember why the JDK version wasn't fixed with the original > -fvisibility=hidden work. > > Coleen > > > On 2/28/2013 3:56 PM, Daniel D. Daugherty wrote: > >> On 2/28/13 11:57 AM, David DeHaven wrote: >> >>> Has a bug been filed for this? -DrD- >>> >> >> As mentioned earlier in this thread... >> >> Dan >> >> >> >> On 2/19/13 5:21 PM, Daniel D. Daugherty wrote: >> >>> I couldn't find a 'jdk' repo relevant bug for this issue so I filed: >>> >>> 8008509: 6588413 changed JNIEXPORT visibility for GCC on HSX, jdk's >>> jni_md.h needs similar change >>> http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=8008509 >>> https://jbs.oracle.com/bugs/**browse/JDK-8008509 >>> >>> Coleen did the original work on 6588413 so I added her to the "interest >>> list" for the new bug. The need for an update to the jdk repo's jni_md.h >>> file was raised during the code review for 6588413, but that detail >>> appears >>> to have been dropped. >>> >>> Dan >>> >> > From david.holmes at oracle.com Tue Mar 12 01:25:28 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Mar 2013 11:25:28 +1000 Subject: Mismatch between JDK and JVM re largest byte array that VM can allocate? In-Reply-To: References: Message-ID: <513E8408.8060107@oracle.com> Hi Ramki, The maximum array size is a VM limitation based on the internal implementation, so I don't think the JDK code should be aware of this limitation. At least with the present code the request for a size of Integer.MAX_VALUE will fail immediately, rather than spending half an hour failing to allocate an insanely large array ;-) If huge arrays eventually make their way into Java we will have to address this, but otherwise it seems pretty low priority to me. Is this actually causing an issue or is it just an observation? Cheers, David On 12/03/2013 9:11 AM, Srinivas Ramakrishna wrote: > I am looking at code in (for example) ByteArrayOutputStream.java :- > > 96 /** > > 97 * Increases the capacity to ensure that it can hold at least the > > 98 * number of elements specified by the minimum capacity argument. > > 99 * > > 100 * @param minCapacity the desired minimum capacity > > 101 */ > > 102 private void grow(int minCapacity) { > > 103 // overflow-conscious code > > 104 int oldCapacity = buf.length; > > 105 int newCapacity = oldCapacity << 1; > > 106 if (newCapacity - minCapacity < 0) > > 107 newCapacity = minCapacity; > > 108 if (newCapacity < 0) { > > 109 if (minCapacity < 0) // overflow > > 110 throw new OutOfMemoryError(); > > 111 newCapacity = Integer.MAX_VALUE; > > 112 } > > 113 buf = Arrays.copyOf(buf, newCapacity); > > 114 } > > > This can result in a request for an array of size Integer.MAX_VALUE > (because of line 111 above), see below:- > > 2874 /** > > 2875 * Copies the specified array, truncating or padding > with zeros (if necessary) > > 2876 * so the copy has the specified length. For all indices that are > > 2877 * valid in both the original array and the copy, the > two arrays will > > 2878 * contain identical values. For any indices that are > valid in the > > 2879 * copy but not the original, the copy will contain > (byte)0. > > 2880 * Such indices will exist if and only if the specified length > > 2881 * is greater than that of the original array. > > 2882 * > > 2883 * @param original the array to be copied > > 2884 * @param newLength the length of the copy to be returned > > 2885 * @return a copy of the original array, truncated or > padded with zeros > > 2886 * to obtain the specified length > > 2887 * @throws NegativeArraySizeException if > newLength is negative > > 2888 * @throws NullPointerException if original is null > > 2889 * @since 1.6 > > 2890 */ > > 2891 public static byte[] copyOf(byte[] original, int newLength) { > > 2892 byte[] copy = new byte[newLength]; > > 2893 System.arraycopy(original, 0, copy, 0, > > 2894 Math.min(original.length, newLength)); > > 2895 return copy; > > 2896 } > > > So the call at line 2892 can cause a request for an array with > Integer.MAX_VALUE entries, yet the JVM doesn't give you arrays that > large; witness this code in arrayOop.cpp where this will flatten out:- > > // Return the maximum length of an array of BasicType. The length can passed > // to typeArrayOop::object_size(scale, length, header_size) without causing an > // overflow. We also need to make sure that this will not overflow a size_t on > // 32 bit platforms when we convert it to a byte size. > static int32_t max_array_length(BasicType type) { > assert(type >= 0 && type < T_CONFLICT, "wrong type"); > assert(type2aelembytes(type) != 0, "wrong type"); > > const size_t max_element_words_per_size_t = > align_size_down((SIZE_MAX/HeapWordSize - header_size(type)), > MinObjAlignment); > const size_t max_elements_per_size_t = > HeapWordSize * max_element_words_per_size_t / type2aelembytes(type); > if ((size_t)max_jint < max_elements_per_size_t) { > // It should be ok to return max_jint here, but parts of the code > // (CollectedHeap, Klass::oop_oop_iterate(), and more) uses an int for > // passing around the size (in words) of an object. So, we need to avoid > // overflowing an int when we add the header. See CRs 4718400 and 7110613. > return align_size_down(max_jint - header_size(type), MinObjAlignment); > } > return (int32_t)max_elements_per_size_t; > } > > > Is there any plan to fix this mismatch ? May be it's as simple(!) as > checking the GC code to make sure it doesn't traffic in int's and > fix the code above to return max_jint for the byte array case as well? > I have a vague recollection of a bug id already for this, but > it's been a while.... > > Thanks! > -- ramki > From mike.duigou at oracle.com Tue Mar 12 01:29:06 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 11 Mar 2013 18:29:06 -0700 Subject: Code review request: JDK-8008670 (partial java.util.stream implementation) In-Reply-To: <513E52B5.5060105@oracle.com> References: <51267293.4060203@oracle.com> <513E52B5.5060105@oracle.com> Message-ID: <44E0A9DD-3C4B-472A-9988-B591E5417D7F@oracle.com> Some notes: - Copyrights update. - The order of notes on files is the order that I read the files. It seems like not a bad order to review them. - package docs? Coming next? java.util.Map:: - @since 1.8 missing for defaults - should be replace with {@code} - default methods need the notice that the default implementations do not provide atomicity. (copy from putIfAbsent) - ::forEach() - Rename the parameter from block? - ::computeIfAbsent() - "and enters it into this map" -> inserts? - I wonder if compute if absent should replace the original get(key) with containsKey(key) and replace get() with containsKey() in the pseudo-code documentation. If implementations know that the map can't contain null then they can optimize to get(). Demonstrated with get() would seem to produce incorrect results with a present null value. - ::computeIfAbsent()/computeIfPresent()/compute() - "key with which the specified value is to be associated" -> derived value. - ::computeIfAbsent()/computeIfPresent()/compute() - @throws RuntimeException or Error These should be separate. java.util.Collections:: - Map.synchronizedMap needs extension to provide synchronized implementations of Map default methods. java.util.Hashtable:: - synchronized implementations of Map default methods are needed. AbstractTask:: - "that describes a portion of the input" -> describes the he portion of the input associated with the subtree rooted at this task. - setRawResult() : needs better docs. Why does getRawResult return local (which may be null)? - Are trees of abstract task always homogeneous? Perhaps an assert parent.getClass == class ? since the T can't be verified to be the same as the class. - onCompletion does not clear numChildren ForEachOps:: - BooleanProvider -> BooleanSupplier - in whatever Thread -> on whatever thread - "

There is no guarantee that additional elements.." should be before @apiNote. - Wouldn't it be nice if there as a way to template the primitive impls. :-) IntermediateOp:: - "An intermediate operation has an input type and an output type". These aren't reified or introspectable in contrast to the shape. - Perhaps defer more about statefulness to StatefulOp StatefulOp:: - Should include a sentence about how a stateful op knows when it has received it's last element. - Perhaps re-iterate wrapSink() to provide documentation about completion and when elements are written to output. ie. Sink.end() Sink:: - ::end() "If the {@code Sink} buffers any results from previous values, they should dump their contents downstream and clear any stored state." -> If the {@code Sink} is stateful it should send all of it's stored state downstream. - :: I wonder about the suggestion to clear stored state. Why is this better than just letting it be GCed? If there is value to explicit clearing we should explain why (at least partially). - ::cancellationRequested() -> :: accepting()? Cancellation sounds like an exceptional state. - ::cancellationRequested() - document default. @implNote - why does accept(T) not merit an ISE default? - ChainedReference/ChainedInt/etc : Should mention in the first sentence that they are abstract. "Abstract skeleton {@code Sink} implementation for creating chains of sinks." Tripwire:: - "Turned off for production." -> "Normally this should be turned off for production systems." Node:: - I don't find the defaults particularly helpful. I would probably prefer them to be fully abstract so that I remember to implement them. - ::forEach() - worth mentioning that the traversal order is possibly unspecified? - ::toArray() warning regarding shared array and mutation is not sufficiently dire. - ::toArray() generator is unexplained. relation between generator needs to be clear. ie. generator might not be called even for unshared. - ::copyInto() doesn't offer the ability to get some subset of node elements. count() returns long but arrays can only hold INTEGER.MAX_VALUE (less actually) elements. Either there has to be a way to get partial results or we might as well make count an int. - ::Builder - is it necessary to say that it is a flat node? - That's a lotta template code! StreamOpFlag:: - tables could be a proper HTML table. If you want me to rework it as a proper 508 compliant table, just ask. :-) On Mar 11 2013, at 14:55 , Brian Goetz wrote: > I've posted an updated webrev incorporating comments received to date: > > http://cr.openjdk.java.net/~briangoetz/jdk-8008670.2/webrev/ > > > > On 2/21/2013 2:16 PM, Brian Goetz wrote: >> At: >> http://cr.openjdk.java.net/~briangoetz/jdk-8008670/webrev/ >> >> there is a webrev of a subset of the implementation of java.util.stream, >> for review. These are all new files. None of these are public classes; >> they are internal interfaces for the Stream library, as well as some >> implementation classes. This is about half the classes in the Streams >> package. >> >> (The webrev includes changes to Map, but those are being reviewed >> separately, so just ignore those.) >> >> We're asking people to focus their review on both the quality of API >> specification for these internal APIs, and the quality of implementation >> of the specified classes. It may not be obvious how some of these work >> until you've seen the rest of it, but do what you can. >> From jonathan.gibbons at oracle.com Tue Mar 12 02:04:34 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 12 Mar 2013 02:04:34 +0000 Subject: hg: jdk8/tl/langtools: 8009843: sjavac should accept -cp as synonym for -classpath Message-ID: <20130312020439.A685648090@hg.openjdk.java.net> Changeset: fbb6e470079d Author: ohrstrom Date: 2013-03-11 19:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fbb6e470079d 8009843: sjavac should accept -cp as synonym for -classpath Reviewed-by: jjg ! src/share/classes/com/sun/tools/sjavac/Main.java From brian.goetz at oracle.com Tue Mar 12 02:12:38 2013 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 11 Mar 2013 22:12:38 -0400 Subject: Code review request: JDK-8008670 (partial java.util.stream implementation) In-Reply-To: References: <51267293.4060203@oracle.com> <513E52B5.5060105@oracle.com> Message-ID: <513E8F16.7080200@oracle.com> > 2) I find X_IN and X_OUT type parameters to be disruptive to reading. > Sticking to a simple "I" and "O" would be much easier to read. I'll answer this one because we've gotten it from a few places. This is a nice idea, and it works fine up to a certain level of complexity. But when you have a generic method of a generic class that between them have five type variables, the single-letter scheme hits the wall, and it crashes and burns. (This isn't supposition; the earlier versions of this code base stuck to the single letter scheme and people told us they couldn't keep track of which type variables are which. For example, in the interaction between AbstractPipeline and PipelineHelper, both have in and out parameters, and they're not the same, so I and O are completely confusing in that context.) But one also wants to be consistent. So when you cross the multi-letter boundary, you likely have to stay there even in many cases where one letter would do. From ysr1729 at gmail.com Tue Mar 12 05:22:20 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Mon, 11 Mar 2013 22:22:20 -0700 Subject: Mismatch between JDK and JVM re largest byte array that VM can allocate? In-Reply-To: <513E8408.8060107@oracle.com> References: <513E8408.8060107@oracle.com> Message-ID: It's causing an issue -- which can be worked around in our code -- which is how I stumbled upon this. My thinking was that perhaps the jvm limit could be communicated to the libs via a suitable jvm method. Or better still the unnecessary limitation could be removed for the 64 bit jvm and everyone's happy. Max sized byte arrays are not that uncommon in certain kinds of apps using large heaps. The unfortunate part is that the workaround might require one to stay well away from the actual limit -- to the extent of less than half of max-int minus header size. So, definitely not a show-stopper, but would be nice to fix-- and perhaps easy to in the 64 bit case which is where it matters anyway. -- Ramki ysr1729 On Mar 11, 2013, at 18:25, David Holmes wrote: > Hi Ramki, > > The maximum array size is a VM limitation based on the internal implementation, so I don't think the JDK code should be aware of this limitation. > > At least with the present code the request for a size of Integer.MAX_VALUE will fail immediately, rather than spending half an hour failing to allocate an insanely large array ;-) > > If huge arrays eventually make their way into Java we will have to address this, but otherwise it seems pretty low priority to me. > > Is this actually causing an issue or is it just an observation? > > Cheers, > David > > On 12/03/2013 9:11 AM, Srinivas Ramakrishna wrote: >> I am looking at code in (for example) ByteArrayOutputStream.java :- >> >> 96 /** >> >> 97 * Increases the capacity to ensure that it can hold at least the >> >> 98 * number of elements specified by the minimum capacity argument. >> >> 99 * >> >> 100 * @param minCapacity the desired minimum capacity >> >> 101 */ >> >> 102 private void grow(int minCapacity) { >> >> 103 // overflow-conscious code >> >> 104 int oldCapacity = buf.length; >> >> 105 int newCapacity = oldCapacity << 1; >> >> 106 if (newCapacity - minCapacity < 0) >> >> 107 newCapacity = minCapacity; >> >> 108 if (newCapacity < 0) { >> >> 109 if (minCapacity < 0) // overflow >> >> 110 throw new OutOfMemoryError(); >> >> 111 newCapacity = Integer.MAX_VALUE; >> >> 112 } >> >> 113 buf = Arrays.copyOf(buf, newCapacity); >> >> 114 } >> >> >> This can result in a request for an array of size Integer.MAX_VALUE >> (because of line 111 above), see below:- >> >> 2874 /** >> >> 2875 * Copies the specified array, truncating or padding >> with zeros (if necessary) >> >> 2876 * so the copy has the specified length. For all indices that are >> >> 2877 * valid in both the original array and the copy, the >> two arrays will >> >> 2878 * contain identical values. For any indices that are >> valid in the >> >> 2879 * copy but not the original, the copy will contain >> (byte)0. >> >> 2880 * Such indices will exist if and only if the specified length >> >> 2881 * is greater than that of the original array. >> >> 2882 * >> >> 2883 * @param original the array to be copied >> >> 2884 * @param newLength the length of the copy to be returned >> >> 2885 * @return a copy of the original array, truncated or >> padded with zeros >> >> 2886 * to obtain the specified length >> >> 2887 * @throws NegativeArraySizeException if >> newLength is negative >> >> 2888 * @throws NullPointerException if original is null >> >> 2889 * @since 1.6 >> >> 2890 */ >> >> 2891 public static byte[] copyOf(byte[] original, int newLength) { >> >> 2892 byte[] copy = new byte[newLength]; >> >> 2893 System.arraycopy(original, 0, copy, 0, >> >> 2894 Math.min(original.length, newLength)); >> >> 2895 return copy; >> >> 2896 } >> >> >> So the call at line 2892 can cause a request for an array with >> Integer.MAX_VALUE entries, yet the JVM doesn't give you arrays that >> large; witness this code in arrayOop.cpp where this will flatten out:- >> >> // Return the maximum length of an array of BasicType. The length can passed >> // to typeArrayOop::object_size(scale, length, header_size) without causing an >> // overflow. We also need to make sure that this will not overflow a size_t on >> // 32 bit platforms when we convert it to a byte size. >> static int32_t max_array_length(BasicType type) { >> assert(type >= 0 && type < T_CONFLICT, "wrong type"); >> assert(type2aelembytes(type) != 0, "wrong type"); >> >> const size_t max_element_words_per_size_t = >> align_size_down((SIZE_MAX/HeapWordSize - header_size(type)), >> MinObjAlignment); >> const size_t max_elements_per_size_t = >> HeapWordSize * max_element_words_per_size_t / type2aelembytes(type); >> if ((size_t)max_jint < max_elements_per_size_t) { >> // It should be ok to return max_jint here, but parts of the code >> // (CollectedHeap, Klass::oop_oop_iterate(), and more) uses an int for >> // passing around the size (in words) of an object. So, we need to avoid >> // overflowing an int when we add the header. See CRs 4718400 and 7110613. >> return align_size_down(max_jint - header_size(type), MinObjAlignment); >> } >> return (int32_t)max_elements_per_size_t; >> } >> >> >> Is there any plan to fix this mismatch ? May be it's as simple(!) as >> checking the GC code to make sure it doesn't traffic in int's and >> fix the code above to return max_jint for the byte array case as well? >> I have a vague recollection of a bug id already for this, but >> it's been a while.... >> >> Thanks! >> -- ramki >> From david.holmes at oracle.com Tue Mar 12 07:10:59 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Mar 2013 17:10:59 +1000 Subject: RFR: 8009428 and 8009429 - Profile related fixes and clean ups In-Reply-To: <513D9BD1.6060807@oracle.com> References: <51394373.4040404@oracle.com> <5139AD05.1060208@oracle.com> <5139CB49.5000601@oracle.com> <513D3257.2030801@oracle.com> <513D9BD1.6060807@oracle.com> Message-ID: <513ED503.6040000@oracle.com> Hi Alan, On 11/03/2013 6:54 PM, Alan Bateman wrote: > On 11/03/2013 01:24, David Holmes wrote: >> I had overlooked the need to update the ct.sym creation tool to >> recognize the new syntax in the profile spec file. That process also >> uncovered a few bugs in the listing that needed correcting. >> >> The javadoc generation of compact profile information is not quite >> right, but that will be handled in a seperate bug. >> >> Updated webrevs at: >> >> http://cr.openjdk.java.net/~dholmes/8009428_8009429.v2/ > The changes to the top-level and jdk repo look good to me. As per my > original comments, I'm happy to see profile-rtjar-includes.txt changed > to be much easier to maintain. The assumption that jdk.** is in compact1 > is okay for now but I'm sure that will need to be changed when that > namespace is used more. Yes we will change this as we need to, once other packages come into play. > For the intro comment in profile-rtjar-includes.txt then it might be > useful to beef up the comment to explain what happens when an API > package does not match one of the rules, ie: does it go into compact1, > only the full JRE, or none. Also make it explicit that the form > DialogCallbackHandler*.class should not be used. I suggest this for the > benefit of someone needing to tweak this in the future. I have updated the webrev with additional commentary. > I have played with com.sun.tools.javac.sym.Profiles and so the changes > to MakefileProfiles look okay to me but Jon should really be the > reviewer for this. One thing about maxProfiles is that it should match > Profile.values.length maybe maxProfiles should not be hardcoded to 4. Sorry but what is Profiles.values.length? Previously we inferred the number of profiles from the fact that we failed to find PROFILE_n for some value n. That can't work (easily) now hence the hard limit. > Another thing is whether to add a test or beef up an existing test > (ProfileOptionTest.java in particular). What exactly is it that you would like to test for? Thanks, David > -Alan. From peter.levart at gmail.com Tue Mar 12 07:18:29 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 12 Mar 2013 08:18:29 +0100 Subject: Code review request: JDK-8008670 (partial java.util.stream implementation) In-Reply-To: <44E0A9DD-3C4B-472A-9988-B591E5417D7F@oracle.com> References: <51267293.4060203@oracle.com> <513E52B5.5060105@oracle.com> <44E0A9DD-3C4B-472A-9988-B591E5417D7F@oracle.com> Message-ID: <513ED6C5.4000303@gmail.com> On 03/12/2013 02:29 AM, Mike Duigou wrote: > Some notes: > > - Copyrights update. > > - The order of notes on files is the order that I read the files. It seems like not a bad order to review them. > > - package docs? Coming next? > > java.util.Map:: > > - @since 1.8 missing for defaults > > - should be replace with {@code} > > - default methods need the notice that the default implementations do not provide atomicity. (copy from putIfAbsent) > > - ::forEach() - Rename the parameter from block? > > - ::computeIfAbsent() - "and enters it into this map" -> inserts? > > - I wonder if compute if absent should replace the original get(key) with containsKey(key) and replace get() with containsKey() in the pseudo-code documentation. If implementations know that the map can't contain null then they can optimize to get(). Demonstrated with get() would seem to produce incorrect results with a present null value. > > - ::computeIfAbsent()/computeIfPresent()/compute() - "key with which the specified value is to be associated" -> derived value. > > - ::computeIfAbsent()/computeIfPresent()/compute() - @throws RuntimeException or Error These should be separate. Hi, I would just like to point out to a discussion a couple of months ago: http://mail.openjdk.java.net/pipermail/lambda-dev/2013-January/007509.html ... at least Map.compute() still has this anomaly when executed against HashMap. Regards, Peter > > java.util.Collections:: > > - Map.synchronizedMap needs extension to provide synchronized implementations of Map default methods. > > java.util.Hashtable:: > > - synchronized implementations of Map default methods are needed. > > > AbstractTask:: > > - "that describes a portion of the input" -> describes the he portion of the input associated with the subtree rooted at this task. > > - setRawResult() : needs better docs. Why does getRawResult return local (which may be null)? > > - Are trees of abstract task always homogeneous? Perhaps an assert parent.getClass == class ? since the T can't be verified to be the same as the class. > > - onCompletion does not clear numChildren > > > > ForEachOps:: > > - BooleanProvider -> BooleanSupplier > > - in whatever Thread -> on whatever thread > > - "

There is no guarantee that additional elements.." should be before @apiNote. > > - Wouldn't it be nice if there as a way to template the primitive impls. :-) > > > IntermediateOp:: > > - "An intermediate operation has an input type and an output type". These aren't reified or introspectable in contrast to the shape. > > - Perhaps defer more about statefulness to StatefulOp > > > StatefulOp:: > > - Should include a sentence about how a stateful op knows when it has received it's last element. > > - Perhaps re-iterate wrapSink() to provide documentation about completion and when elements are written to output. ie. Sink.end() > > > Sink:: > > - ::end() "If the {@code Sink} buffers any results from previous values, they should dump their contents downstream and clear any stored state." -> If the {@code Sink} is stateful it should send all of it's stored state downstream. > > - :: I wonder about the suggestion to clear stored state. Why is this better than just letting it be GCed? If there is value to explicit clearing we should explain why (at least partially). > > - ::cancellationRequested() -> :: accepting()? Cancellation sounds like an exceptional state. > > - ::cancellationRequested() - document default. @implNote > > - why does accept(T) not merit an ISE default? > > - ChainedReference/ChainedInt/etc : Should mention in the first sentence that they are abstract. "Abstract skeleton {@code Sink} implementation for creating chains of sinks." > > > Tripwire:: > > - "Turned off for production." -> "Normally this should be turned off for production systems." > > > Node:: > > - I don't find the defaults particularly helpful. I would probably prefer them to be fully abstract so that I remember to implement them. > > - ::forEach() - worth mentioning that the traversal order is possibly unspecified? > > - ::toArray() warning regarding shared array and mutation is not sufficiently dire. > > - ::toArray() generator is unexplained. relation between generator needs to be clear. ie. generator might not be called even for unshared. > > - ::copyInto() doesn't offer the ability to get some subset of node elements. count() returns long but arrays can only hold INTEGER.MAX_VALUE (less actually) elements. Either there has to be a way to get partial results or we might as well make count an int. > > - ::Builder - is it necessary to say that it is a flat node? > > - That's a lotta template code! > > > > StreamOpFlag:: > > - tables could be a proper HTML table. If you want me to rework it as a proper 508 compliant table, just ask. :-) > > > On Mar 11 2013, at 14:55 , Brian Goetz wrote: > >> I've posted an updated webrev incorporating comments received to date: >> >> http://cr.openjdk.java.net/~briangoetz/jdk-8008670.2/webrev/ >> >> >> >> On 2/21/2013 2:16 PM, Brian Goetz wrote: >>> At: >>> http://cr.openjdk.java.net/~briangoetz/jdk-8008670/webrev/ >>> >>> there is a webrev of a subset of the implementation of java.util.stream, >>> for review. These are all new files. None of these are public classes; >>> they are internal interfaces for the Stream library, as well as some >>> implementation classes. This is about half the classes in the Streams >>> package. >>> >>> (The webrev includes changes to Map, but those are being reviewed >>> separately, so just ignore those.) >>> >>> We're asking people to focus their review on both the quality of API >>> specification for these internal APIs, and the quality of implementation >>> of the specified classes. It may not be obvious how some of these work >>> until you've seen the rest of it, but do what you can. >>> From Alan.Bateman at oracle.com Tue Mar 12 10:05:01 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 12 Mar 2013 10:05:01 +0000 Subject: RFR: 8009428 and 8009429 - Profile related fixes and clean ups In-Reply-To: <513ED503.6040000@oracle.com> References: <51394373.4040404@oracle.com> <5139AD05.1060208@oracle.com> <5139CB49.5000601@oracle.com> <513D3257.2030801@oracle.com> <513D9BD1.6060807@oracle.com> <513ED503.6040000@oracle.com> Message-ID: <513EFDCD.4040309@oracle.com> On 12/03/2013 07:10, David Holmes wrote: > : > >> For the intro comment in profile-rtjar-includes.txt then it might be >> useful to beef up the comment to explain what happens when an API >> package does not match one of the rules, ie: does it go into compact1, >> only the full JRE, or none. Also make it explicit that the form >> DialogCallbackHandler*.class should not be used. I suggest this for the >> benefit of someone needing to tweak this in the future. > > I have updated the webrev with additional commentary. Thanks, that will be very useful to future maintainers. > >> I have played with com.sun.tools.javac.sym.Profiles and so the changes >> to MakefileProfiles look okay to me but Jon should really be the >> reviewer for this. One thing about maxProfiles is that it should match >> Profile.values.length maybe maxProfiles should not be hardcoded to 4. > > Sorry but what is Profiles.values.length? Previously we inferred the > number of profiles from the fact that we failed to find PROFILE_n for > some value n. That can't work (easily) now hence the hard limit. I meant com.sun.tools.javac.jvm.Profile, it's an enum of the profiles so it means that the knowledge about 3 + full JRE is now in two places. > >> Another thing is whether to add a test or beef up an existing test >> (ProfileOptionTest.java in particular). > > What exactly is it that you would like to test for? I think the test should include a few cases to cover a few selected types in sub-packages to make sure they are in the right profile. -Alan. From joel.franck at oracle.com Tue Mar 12 10:18:06 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Tue, 12 Mar 2013 10:18:06 +0000 Subject: hg: jdk8/tl/langtools: 8005205: tests missing bugid for repeating annotation change Message-ID: <20130312101819.082034809E@hg.openjdk.java.net> Changeset: 7fe9b9d29095 Author: jfranck Date: 2013-03-12 11:16 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7fe9b9d29095 8005205: tests missing bugid for repeating annotation change Reviewed-by: jjg, ssides ! test/tools/javac/annotations/repeatingAnnotations/MissingContainer.java ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.java From paul.sandoz at oracle.com Tue Mar 12 10:25:19 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 12 Mar 2013 11:25:19 +0100 Subject: Code review request: JDK-8008670 (partial java.util.stream implementation) In-Reply-To: References: <51267293.4060203@oracle.com> <513E52B5.5060105@oracle.com> Message-ID: <9BCCA3C0-2838-46D6-B0E9-524854A209B7@oracle.com> On Mar 12, 2013, at 12:13 AM, Paul Benedict wrote: > 3) StreamShape: Javadoc should be formatted to be within 80 characters. > Hmm... that is linked to an old version. It should be the same as: http://hg.openjdk.java.net/lambda/lambda/jdk/raw-file/9ccdccc3c754/src/share/classes/java/util/stream/StreamShape.java Paul. From Alan.Bateman at oracle.com Tue Mar 12 12:36:08 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 12 Mar 2013 12:36:08 +0000 Subject: Request for review- RFE 8005716 In-Reply-To: <513DFA1D.1000902@oracle.com> References: <51367A43.1060606@oracle.com> <513748D4.3080803@oracle.com> <5138C22B.5070803@oracle.com> <5138FDA7.6040108@oracle.com> <51394B5C.2090306@oracle.com> <513DDECA.7090003@oracle.com> <513DFA1D.1000902@oracle.com> Message-ID: <513F2138.30102@oracle.com> On 11/03/2013 15:37, BILL PITTORE wrote: > On 3/11/2013 9:40 AM, Alan Bateman wrote: >> On 08/03/2013 02:22, BILL PITTORE wrote: >>> Moved the string allocation into buildJniFunctionName as Alan >>> suggested. Built and tested on windows and linux. Updated the webrev: >>> >>> http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.02/ >>> >>> >>> bill >> I see this updates the method descriptions to take on board Jeremy's >> comment on the possibility of the library being statically linked >> with the main executable with or without the VM. To be complete, I >> think this will require an update to the UnstatisfiedLinkError >> description too. >> >> Thanks for moving the sizing/allocation of the function name into >> buildJniFunctionName as that is cleaner and safer. Is FILENAME_MAX >> really the right limit to impose? > Maybe JVM_MAXPATHLEN is the better choice. As it's a symbol rather than a file path then it's probably not right either. I guess the question is whether a limit needs to be checked here or not. -Alan. From paul.sandoz at oracle.com Tue Mar 12 13:51:10 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 12 Mar 2013 14:51:10 +0100 Subject: Code review request: JDK-8008670 (partial java.util.stream implementation) In-Reply-To: <44E0A9DD-3C4B-472A-9988-B591E5417D7F@oracle.com> References: <51267293.4060203@oracle.com> <513E52B5.5060105@oracle.com> <44E0A9DD-3C4B-472A-9988-B591E5417D7F@oracle.com> Message-ID: On Mar 12, 2013, at 2:29 AM, Mike Duigou wrote: > Some notes: > > - Copyrights update. > Pushed to lambda repo: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/40c0a71455d7 > - The order of notes on files is the order that I read the files. It seems like not a bad order to review them. > > - package docs? Coming next? > Soonish :-) there is much left to review/spec. > java.util.Map:: > > - @since 1.8 missing for defaults > > - should be replace with {@code} > It is mostly consistent with the rest of the Map documentation. We should do a global replace in that case? > - default methods need the notice that the default implementations do not provide atomicity. (copy from putIfAbsent) > I have shuffled stuff around and used @implSpec. > - ::forEach() - Rename the parameter from block? > I updated that to use similar language as Iterator/Iterable.forEach. > - ::computeIfAbsent() - "and enters it into this map" -> inserts? > > - I wonder if compute if absent should replace the original get(key) with containsKey(key) and replace get() with containsKey() in the pseudo-code documentation. If implementations know that the map can't contain null then they can optimize to get(). Demonstrated with get() would seem to produce incorrect results with a present null value. > > - ::computeIfAbsent()/computeIfPresent()/compute() - "key with which the specified value is to be associated" -> derived value. > Perhaps the above three merit a separate discussion. Raise in a separate email thread? > - ::computeIfAbsent()/computeIfPresent()/compute() - @throws RuntimeException or Error These should be separate. > Do we really need to declare that? It would apply for every use of lambdas and it is previously stated: "If the function itself throws an (unchecked) exception, the exception is rethrown, and the current mapping is left unchanged." I have removed them. http://hg.openjdk.java.net/lambda/lambda/jdk/rev/36664688aa52 > java.util.Collections:: > > - Map.synchronizedMap needs extension to provide synchronized implementations of Map default methods. > http://hg.openjdk.java.net/lambda/lambda/jdk/rev/077efaf92c8c You know off any tests that can be reused? > java.util.Hashtable:: > > - synchronized implementations of Map default methods are needed. > Good point. I think it may help to address that and some other things together. Checked and unmodifiable lists should also be updated to be efficient for appropriate default methods. There is also the synchronized collections/lists. We need to consider the spliterator/stream/parallelStream methods, especially how the spliterator should behave. Paul. From coleen.phillimore at oracle.com Tue Mar 12 14:54:15 2013 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 12 Mar 2013 14:54:15 +0000 Subject: hg: jdk8/tl/jdk: 7154889: Non-zero padding is still not allowed in the tableswitch/lookupswitch instructions. Message-ID: <20130312145449.738A5480A7@hg.openjdk.java.net> Changeset: 334ddf3b101f Author: coleenp Date: 2013-03-12 10:35 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/334ddf3b101f 7154889: Non-zero padding is still not allowed in the tableswitch/lookupswitch instructions. Summary: Do not check that the padding bytes are zero if class file format version >=51. Reviewed-by: dholmes, coleenp, mullan, kvn Contributed-by: harold.seigel at oracle.com ! src/share/native/common/check_code.c From Alan.Bateman at oracle.com Tue Mar 12 15:19:24 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 12 Mar 2013 15:19:24 +0000 Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code In-Reply-To: <513E6C33.7040700@oracle.com> References: <50FE3EE5.20600@oracle.com> <5100065A.9080801@oracle.com> <51029C56.9020302@oracle.com> <5106CB48.3010102@oracle.com> <5107B89A.3050400@oracle.com> <510ACEFC.2060607@oracle.com> <510B900B.1030406@oracle.com> <510C008A.2000107@oracle.com> <510C32D2.2080508@oracle.com> <51363BCD.7070700@oracle.com> <51388AB6.4000504@oracle.com> <51389446.1000405@oracle.com> <513895EF.6040001@oracle.com> <513E6C33.7040700@oracle.com> Message-ID: <513F477C.9030108@oracle.com> On 11/03/2013 23:43, Dan Xu wrote: > Thanks for all your comments. I have updated the fix accordingly. > Please see the webrev at > http://cr.openjdk.java.net/~dxu/8001334/webrev.02/. > > For the language concern in getLastErrorString(char *buf, size_t len) > function, I will log another bug and address it later. Thanks! > > -Dan You've addressed all my comments but I think I may have confused you on one point when I mentioned O_APPEND. You've changed handleAppend to use fcntl(F_GETFL) and check if the flag is set but this will happen on every write in append mode and we don't want that. I think you can simply change IO_Append to be handleWrite or else have handleAppend call handleWrite. The jboolean flag isn't needed for the *nix case. -Alan. From paul.sandoz at oracle.com Tue Mar 12 15:24:00 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 12 Mar 2013 16:24:00 +0100 Subject: Code review request: JDK-8008670 (partial java.util.stream implementation) In-Reply-To: <44E0A9DD-3C4B-472A-9988-B591E5417D7F@oracle.com> References: <51267293.4060203@oracle.com> <513E52B5.5060105@oracle.com> <44E0A9DD-3C4B-472A-9988-B591E5417D7F@oracle.com> Message-ID: <6E3667B9-0D3F-4D01-B141-7CEBDDB94AE9@oracle.com> Hi Mike, On Mar 12, 2013, at 2:29 AM, Mike Duigou wrote: > AbstractTask:: > > - "that describes a portion of the input" -> describes the he portion of the input associated with the subtree rooted at this task. > > - setRawResult() : needs better docs. Why does getRawResult return local (which may be null)? > I need to look into this more closely. I recall some subtle things related to CountedCompleter.complete/onCompletion methods and short-circuiting operations in terms of the order of invocation that caused us to side step get/setRawResult with get/setLocalResult. > - Are trees of abstract task always homogeneous? Yes. > Perhaps an assert parent.getClass == class ? since the T can't be verified to be the same as the class. > > - onCompletion does not clear numChildren > Currently it is designed to clear stuff to help GC, once the task is completed it should not be reused. So we should state something about reuse. > > > ForEachOps:: > > - BooleanProvider -> BooleanSupplier > > - in whatever Thread -> on whatever thread > > - "

There is no guarantee that additional elements.." should be before @apiNote. > > - Wouldn't it be nice if there as a way to template the primitive impls. :-) > I am not sure it is worth it for 3 primitive types. There is also a cost of developing with templates, including that of the template system itself. Ideally i want a template system whereby one can implement the int version and annotate with descriptions that say how code can be substituted to produce long/double versions and we use javac with an annotation processor to generate the source as part of the compilation process. > > IntermediateOp:: > > - "An intermediate operation has an input type and an output type". These aren't reified or introspectable in contrast to the shape. > Tricky. How would we do that for say: Stream> s = ... s.flatMap(s::stream).. // List -> String ? > - Perhaps defer more about statefulness to StatefulOp > StatefulOp is a helper interface. It's not required to to implement a stateful operation, so perhaps we should clarify that point. > > StatefulOp:: > > - Should include a sentence about how a stateful op knows when it has received it's last element. > > - Perhaps re-iterate wrapSink() to provide documentation about completion and when elements are written to output. ie. Sink.end() > Not all stateful ops accumulate state and wait until sink.end() to push that accumulated state. SortedOp does that but DistinctOp and SliceOp do not, as they accumulate "side-state" to determine when elements are pushed downstream or not. > > Sink:: > > - ::end() "If the {@code Sink} buffers any results from previous values, they should dump their contents downstream and clear any stored state." -> If the {@code Sink} is stateful it should send all of it's stored state downstream. > > - :: I wonder about the suggestion to clear stored state. Why is this better than just letting it be GCed? If there is value to explicit clearing we should explain why (at least partially). > The idea being is Sink's can be resued. We don't currently do so, but we can consider an optimization later on whereby we cache a sink per fork/join thread. > - ::cancellationRequested() -> :: accepting()? Cancellation sounds like an exceptional state. > > - ::cancellationRequested() - document default. @implNote > > - why does accept(T) not merit an ISE default? > Notice that for the primitive values the corresponding accept is re-abstracted. So Sink accepts references, Sink.OfInt accepts ints etc. so the important method to implement remains abstract. > - ChainedReference/ChainedInt/etc : Should mention in the first sentence that they are abstract. "Abstract skeleton {@code Sink} implementation for creating chains of sinks." > > > Tripwire:: > > - "Turned off for production." -> "Normally this should be turned off for production systems." > > > Node:: > > - I don't find the defaults particularly helpful. I would probably prefer them to be fully abstract so that I remember to implement them. I have found them helpful since the majority of Node implementations are leaf nodes. > > - ::forEach() - worth mentioning that the traversal order is possibly unspecified? > Its a bit like that for Collection. We could say something like "in the order elements are returned by a spliterator". > - ::toArray() warning regarding shared array and mutation is not sufficiently dire. > Suggestions? > - ::toArray() generator is unexplained. relation between generator needs to be clear. ie. generator might not be called even for unshared. > OK. A copy should always be made, using and returning the generated array, if a reference cannot be returned. > - ::copyInto() doesn't offer the ability to get some subset of node elements. count() returns long but arrays can only hold INTEGER.MAX_VALUE (less actually) elements. Either there has to be a way to get partial results or we might as well make count an int. > The idea here is that we have a Node tree that reflects some parallel computation and we want to produce an array from that tree, in parallel, using F/J tasks. First we create an array from the size at the root, so it is gonna fail fast. We keep track of the offset into the array as nodes are processed down the tree. When we hit a leaf node we copy the contents of the node into that array at the correct offset. So there is no general requirement to copy a subset. I agree there is some odd inconsistency though. The idea about using a long for count() (and the same for Spliterator.estimateSize) is that at some point the JVM may support larger array sizes. > - ::Builder - is it necessary to say that it is a flat node? > I think so, a builder should not be building a Node that has children. > - That's a lotta template code! > Yes. > > > StreamOpFlag:: > > - tables could be a proper HTML table. If you want me to rework it as a proper 508 compliant table, just ask. :-) > I am asking :-) Thanks, Paul. From maurizio.cimadamore at oracle.com Tue Mar 12 16:03:21 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 12 Mar 2013 16:03:21 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20130312160338.BC5D1480AA@hg.openjdk.java.net> Changeset: 6db9a3b1a93f Author: mcimadamore Date: 2013-03-12 16:02 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6db9a3b1a93f 8008540: Constructor reference to non-reifiable array should be rejected 8008539: Spurious error when constructor reference mention an interface type 8008538: Constructor reference accepts wildcard parameterized types Summary: Overhaul of Check.checkConstructorRefType Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! test/tools/javac/lambda/MethodReference38.out + test/tools/javac/lambda/MethodReference64.java + test/tools/javac/lambda/MethodReference64.out Changeset: 5ddecb91d843 Author: mcimadamore Date: 2013-03-12 16:02 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5ddecb91d843 8009545: Graph inference: dependencies between inference variables should be set during incorporation Summary: Move all transitivity checks into the incorporation round Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! test/tools/javac/lambda/TargetType28.out From joel.franck at oracle.com Tue Mar 12 16:41:03 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Tue, 12 Mar 2013 16:41:03 +0000 Subject: hg: jdk8/tl/langtools: 7196531: Duplicate error messages on repeating annotations Message-ID: <20130312164106.305CE480B1@hg.openjdk.java.net> Changeset: f427043f8c65 Author: jfranck Date: 2013-03-12 17:39 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f427043f8c65 7196531: Duplicate error messages on repeating annotations Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Annotate.java + test/tools/javac/annotations/repeatingAnnotations/DuplicateErrors.java + test/tools/javac/annotations/repeatingAnnotations/DuplicateErrors.out ! test/tools/javac/annotations/repeatingAnnotations/NoRepeatableAnno.out ! test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.out From dan.xu at oracle.com Tue Mar 12 18:01:01 2013 From: dan.xu at oracle.com (Dan Xu) Date: Tue, 12 Mar 2013 11:01:01 -0700 Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code In-Reply-To: <513F477C.9030108@oracle.com> References: <50FE3EE5.20600@oracle.com> <5100065A.9080801@oracle.com> <51029C56.9020302@oracle.com> <5106CB48.3010102@oracle.com> <5107B89A.3050400@oracle.com> <510ACEFC.2060607@oracle.com> <510B900B.1030406@oracle.com> <510C008A.2000107@oracle.com> <510C32D2.2080508@oracle.com> <51363BCD.7070700@oracle.com> <51388AB6.4000504@oracle.com> <51389446.1000405@oracle.com> <513895EF.6040001@oracle.com> <513E6C33.7040700@oracle.com> <513F477C.9030108@oracle.com> Message-ID: <513F6D5D.4080304@oracle.com> On 03/12/2013 08:19 AM, Alan Bateman wrote: > On 11/03/2013 23:43, Dan Xu wrote: >> Thanks for all your comments. I have updated the fix accordingly. >> Please see the webrev at >> http://cr.openjdk.java.net/~dxu/8001334/webrev.02/. >> >> For the language concern in getLastErrorString(char *buf, size_t len) >> function, I will log another bug and address it later. Thanks! >> >> -Dan > You've addressed all my comments but I think I may have confused you > on one point when I mentioned O_APPEND. You've changed handleAppend to > use fcntl(F_GETFL) and check if the flag is set but this will happen > on every write in append mode and we don't want that. I think you can > simply change IO_Append to be handleWrite or else have handleAppend > call handleWrite. The jboolean flag isn't needed for the *nix case. > > -Alan. Hi Alan, Do you mean directly map IO_Append to handleWrite in io_util_md.h for the *nix case? And then where do we check the O_APPEND flag in our code? Or do we require users to open the file with O_APPEND flag? Thanks! -Dan From Alan.Bateman at oracle.com Tue Mar 12 21:22:26 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 12 Mar 2013 21:22:26 +0000 Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code In-Reply-To: <513F6D5D.4080304@oracle.com> References: <50FE3EE5.20600@oracle.com> <5100065A.9080801@oracle.com> <51029C56.9020302@oracle.com> <5106CB48.3010102@oracle.com> <5107B89A.3050400@oracle.com> <510ACEFC.2060607@oracle.com> <510B900B.1030406@oracle.com> <510C008A.2000107@oracle.com> <510C32D2.2080508@oracle.com> <51363BCD.7070700@oracle.com> <51388AB6.4000504@oracle.com> <51389446.1000405@oracle.com> <513895EF.6040001@oracle.com> <513E6C33.7040700@oracle.com> <513F477C.9030108@oracle.com> <513F6D5D.4080304@oracle.com> Message-ID: <513F9C92.8080505@oracle.com> On 12/03/2013 18:01, Dan Xu wrote: > > Hi Alan, > > Do you mean directly map IO_Append to handleWrite in io_util_md.h for > the *nix case? And then where do we check the O_APPEND flag in our > code? Or do we require users to open the file with O_APPEND flag? Thanks! Yes, either IO_Append is defined to be handleWrite or else add handleAppend that simply calls handleWrite. There's no need to check O_APPEND after the file is opened for append, not on *nix anyway. -Alan From dan.xu at oracle.com Tue Mar 12 22:19:53 2013 From: dan.xu at oracle.com (Dan Xu) Date: Tue, 12 Mar 2013 15:19:53 -0700 Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code In-Reply-To: <513F9C92.8080505@oracle.com> References: <50FE3EE5.20600@oracle.com> <5100065A.9080801@oracle.com> <51029C56.9020302@oracle.com> <5106CB48.3010102@oracle.com> <5107B89A.3050400@oracle.com> <510ACEFC.2060607@oracle.com> <510B900B.1030406@oracle.com> <510C008A.2000107@oracle.com> <510C32D2.2080508@oracle.com> <51363BCD.7070700@oracle.com> <51388AB6.4000504@oracle.com> <51389446.1000405@oracle.com> <513895EF.6040001@oracle.com> <513E6C33.7040700@oracle.com> <513F477C.9030108@oracle.com> <513F6D5D.4080304@oracle.com> <513F9C92.8080505@oracle.com> Message-ID: <513FAA09.5030700@oracle.com> I understand now. Here is the updated webrev to directly map IO_Append to handleWrite in *nix platforms, http://cr.openjdk.java.net/~dxu/8001334/webrev.03/. I checked FileOutputStream.java source code, and we do guarantee the consistency of append flag between open and write operations. Thanks! -Dan On 03/12/2013 02:22 PM, Alan Bateman wrote: > On 12/03/2013 18:01, Dan Xu wrote: >> >> Hi Alan, >> >> Do you mean directly map IO_Append to handleWrite in io_util_md.h for >> the *nix case? And then where do we check the O_APPEND flag in our >> code? Or do we require users to open the file with O_APPEND flag? >> Thanks! > Yes, either IO_Append is defined to be handleWrite or else add > handleAppend that simply calls handleWrite. There's no need to check > O_APPEND after the file is opened for append, not on *nix anyway. > > -Alan From bradford.wetmore at oracle.com Tue Mar 12 22:47:46 2013 From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com) Date: Tue, 12 Mar 2013 22:47:46 +0000 Subject: hg: jdk8/tl/jdk: 8009925: Back out AEAD CipherSuites temporarily Message-ID: <20130312224809.7E893480C5@hg.openjdk.java.net> Changeset: 6379415d8fca Author: wetmore Date: 2013-03-12 15:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6379415d8fca 8009925: Back out AEAD CipherSuites temporarily Reviewed-by: valeriep ! src/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java ! src/share/classes/sun/security/internal/spec/TlsKeyMaterialParameterSpec.java ! src/share/classes/sun/security/internal/spec/TlsKeyMaterialSpec.java ! src/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java - src/share/classes/sun/security/ssl/Authenticator.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/EngineInputRecord.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/EngineWriter.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/InputRecord.java ! src/share/classes/sun/security/ssl/JsseJce.java ! src/share/classes/sun/security/ssl/MAC.java ! src/share/classes/sun/security/ssl/OutputRecord.java ! src/share/classes/sun/security/ssl/Record.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! test/sun/security/ec/TestEC.java ! test/sun/security/pkcs11/fips/CipherTest.java ! test/sun/security/pkcs11/sslecc/CipherTest.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java - test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKeyGCM.java ! test/sun/security/ssl/sanity/ciphersuites/CipherSuitesInOrder.java ! test/sun/security/ssl/sanity/interop/CipherTest.java ! test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java From yiming.wang at oracle.com Wed Mar 13 06:28:51 2013 From: yiming.wang at oracle.com (Eric Wang) Date: Wed, 13 Mar 2013 14:28:51 +0800 Subject: [PATCH] Review Request for 8009258: TEST_BUG: java/io/pathNames/GeneralWin32.java fails intermittently In-Reply-To: <5134DC6D.5010905@oracle.com> References: <5134DAB8.1070003@oracle.com> <5134DC6D.5010905@oracle.com> Message-ID: <51401CA3.30407@oracle.com> Hi, Please review the code change, I have updated the test to make sure test only access files and directories created by itself. http://cr.openjdk.java.net/~ewang/8009258/webrev.01/ Here is the execution result: http://cr.openjdk.java.net/~ewang/8009258/GeneralWin32.jtr Thanks, Eric On 2013/3/5 1:39, Alan Bateman wrote: > On 04/03/2013 17:32, Eric Wang wrote: >> Hi, >> >> Please help to review fix below for bug 8009258 >> , >> TEST_BUG:java/io/pathNames/GeneralWin32.java fails intermittently. >> http://cr.openjdk.java.net/~ewang/8009258/webrev.00/ >> >> The File.canRead() method should not be used to check read permission >> of a directory. >> >> Thanks, >> Eric > I wonder if it would be better to change this test so that it doesn't > even attempt to poke around in these directories. I suggest this > because there may be other activity going on at the same time. See > also 8004096 where the test is running in agentvm mode and is straying > into the directory used by another agent VM. > > -Alan From alexey.utkin at oracle.com Wed Mar 13 09:29:18 2013 From: alexey.utkin at oracle.com (alexey.utkin at oracle.com) Date: Wed, 13 Mar 2013 09:29:18 +0000 Subject: hg: jdk8/tl/jdk: 7190897: (fs) Files.isWritable method returns false when the path is writable (win) Message-ID: <20130313093002.3D7E4480E4@hg.openjdk.java.net> Changeset: e497a050e059 Author: uta Date: 2013-03-13 13:22 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e497a050e059 7190897: (fs) Files.isWritable method returns false when the path is writable (win) Summary: The [GetEffectiveRightsFromAcl] based implementation was changed to the [AccessCheck] based. Reviewed-by: alanb ! src/windows/classes/sun/nio/fs/WindowsConstants.java ! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java ! src/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java ! src/windows/classes/sun/nio/fs/WindowsSecurity.java ! src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c From Alan.Bateman at oracle.com Wed Mar 13 10:39:57 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Mar 2013 10:39:57 +0000 Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code In-Reply-To: <513FAA09.5030700@oracle.com> References: <50FE3EE5.20600@oracle.com> <5100065A.9080801@oracle.com> <51029C56.9020302@oracle.com> <5106CB48.3010102@oracle.com> <5107B89A.3050400@oracle.com> <510ACEFC.2060607@oracle.com> <510B900B.1030406@oracle.com> <510C008A.2000107@oracle.com> <510C32D2.2080508@oracle.com> <51363BCD.7070700@oracle.com> <51388AB6.4000504@oracle.com> <51389446.1000405@oracle.com> <513895EF.6040001@oracle.com> <513E6C33.7040700@oracle.com> <513F477C.9030108@oracle.com> <513F6D5D.4080304@oracle.com> <513F9C92.8080505@oracle.com> <513FAA09.5030700@oracle.com> Message-ID: <5140577D.2070900@oracle.com> On 12/03/2013 22:19, Dan Xu wrote: > I understand now. Here is the updated webrev to directly map IO_Append > to handleWrite in *nix platforms, > http://cr.openjdk.java.net/~dxu/8001334/webrev.03/. > > I checked FileOutputStream.java source code, and we do guarantee the > consistency of append flag between open and write operations. Thanks! > > -Dan Thanks for sorting that one out. I've checked that part of the new webrev and it looks good to me now. -Alan. From alexey.utkin at oracle.com Wed Mar 13 11:10:34 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Wed, 13 Mar 2013 15:10:34 +0400 Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code In-Reply-To: <513E6C33.7040700@oracle.com> References: <50FE3EE5.20600@oracle.com> <5100065A.9080801@oracle.com> <51029C56.9020302@oracle.com> <5106CB48.3010102@oracle.com> <5107B89A.3050400@oracle.com> <510ACEFC.2060607@oracle.com> <510B900B.1030406@oracle.com> <510C008A.2000107@oracle.com> <510C32D2.2080508@oracle.com> <51363BCD.7070700@oracle.com> <51388AB6.4000504@oracle.com> <51389446.1000405@oracle.com> <513895EF.6040001@oracle.com> <513E6C33.7040700@oracle.com> Message-ID: <51405EAA.2080301@oracle.com> On 12.03.2013 3:43, Dan Xu wrote: > Thanks for all your comments. I have updated the fix accordingly. > Please see the webrev at > http://cr.openjdk.java.net/~dxu/8001334/webrev.02/. > > For the language concern in getLastErrorString(char *buf, size_t len) > function, I will log another bug and address it later. Thanks! Ok. That is a common place for Windows platform: you got a problem each time you are using ASCII API with Java. I spent some time while resolving that kind of problems in Java deployment. -uta > > -Dan > > > On Thu 07 Mar 2013 05:28:15 AM PST, Alan Bateman wrote: >> On 07/03/2013 13:21, Alexey Utkin wrote: >>> Can I say two word about the file >>> http://cr.openjdk.java.net/~dxu/8001334/webrev.01/src/windows/native/java/io/io_util_md.c.frames.html >>> >>> >>> and function >>> getLastErrorString(char *buf, size_t len) >>> >>> Here is the documentation for [FormatMessage]: >>> http://msdn.microsoft.com/en-gb/library/windows/desktop/ms679351%28v=vs.85%29.aspx >>> >>> >>> if you are using ASCII version of FormatMessage that is a good idea >>> to have the direct reference to [FormatMessageA], not define. >>> >>> The second word is about the third world countries: Russia and China. >>> Windows OS has localized version. The error messages on that systems >>> would contains only [?] in the worst case. >>> >> It's good to re-examine this but just to mention that this is just >> bringing over what is in os::lasterror (in >> hotspot/src/os/windows/vm/os_windows.cpp). >> >> -Alan >> > From weijun.wang at oracle.com Wed Mar 13 11:18:35 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 13 Mar 2013 19:18:35 +0800 Subject: Code review request: 8009977: A test library to launch multiple Java processes (using krb5 as an example) Message-ID: <5140608B.9000700@oracle.com> http://cr.openjdk.java.net/~weijun/8009977/webrev.00 /** * This is a test library that makes writing a Java test that spawns multiple * Java processes easily. * * Usage: * * Proc.create("Clazz") // The class to launch * .args("x") // with args * .env("env", "value") // and an environment variable * .prop("key","value") // and a system property * .perm(perm) // with granted permissions * .start(); // and start * * * The controller can call inheritIO to share its I/O to the process. * Otherwise, it can send data into a proc's stdin with write/println, and * read its stdout with readLine, and stderr is redirected to a file. .... Thanks Max From Alan.Bateman at oracle.com Wed Mar 13 11:40:19 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Mar 2013 11:40:19 +0000 Subject: Code review request: 8009977: A test library to launch multiple Java processes (using krb5 as an example) In-Reply-To: <5140608B.9000700@oracle.com> References: <5140608B.9000700@oracle.com> Message-ID: <514065A3.1050701@oracle.com> Max, Does this overlap with the testlibrary for supporting muli-process tests that Katja Kantserova added recently? -Alan. On 13/03/2013 11:18, Weijun Wang wrote: > http://cr.openjdk.java.net/~weijun/8009977/webrev.00 > > /** > * This is a test library that makes writing a Java test that spawns > multiple > * Java processes easily. > * > * Usage: > * > * Proc.create("Clazz") // The class to launch > * .args("x") // with args > * .env("env", "value") // and an environment variable > * .prop("key","value") // and a system property > * .perm(perm) // with granted permissions > * .start(); // and start > * > * > * The controller can call inheritIO to share its I/O to the process. > * Otherwise, it can send data into a proc's stdin with write/println, > and > * read its stdout with readLine, and stderr is redirected to a file. > .... > > Thanks > Max > From dan.xu at oracle.com Wed Mar 13 12:41:45 2013 From: dan.xu at oracle.com (Dan Xu) Date: Wed, 13 Mar 2013 05:41:45 -0700 Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code In-Reply-To: <5140577D.2070900@oracle.com> References: <50FE3EE5.20600@oracle.com> <5100065A.9080801@oracle.com> <51029C56.9020302@oracle.com> <5106CB48.3010102@oracle.com> <5107B89A.3050400@oracle.com> <510ACEFC.2060607@oracle.com> <510B900B.1030406@oracle.com> <510C008A.2000107@oracle.com> <510C32D2.2080508@oracle.com> <51363BCD.7070700@oracle.com> <51388AB6.4000504@oracle.com> <51389446.1000405@oracle.com> <513895EF.6040001@oracle.com> <513E6C33.7040700@oracle.com> <513F477C.9030108@oracle.com> <513F6D5D.4080304@oracle.com> <513F9C92.8080505@oracle.com> <513FAA09.5030700@oracle.com> <5140577D.2070900@oracle.com> Message-ID: <51407409.6050101@oracle.com> Thank you for the review. I will push it today. -Dan On 03/13/2013 03:39 AM, Alan Bateman wrote: > On 12/03/2013 22:19, Dan Xu wrote: >> I understand now. Here is the updated webrev to directly map >> IO_Append to handleWrite in *nix platforms, >> http://cr.openjdk.java.net/~dxu/8001334/webrev.03/. >> >> I checked FileOutputStream.java source code, and we do guarantee the >> consistency of append flag between open and write operations. Thanks! >> >> -Dan > Thanks for sorting that one out. I've checked that part of the new > webrev and it looks good to me now. > > -Alan. From dan.xu at oracle.com Wed Mar 13 12:46:46 2013 From: dan.xu at oracle.com (Dan Xu) Date: Wed, 13 Mar 2013 05:46:46 -0700 Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code In-Reply-To: <51405EAA.2080301@oracle.com> References: <50FE3EE5.20600@oracle.com> <5100065A.9080801@oracle.com> <51029C56.9020302@oracle.com> <5106CB48.3010102@oracle.com> <5107B89A.3050400@oracle.com> <510ACEFC.2060607@oracle.com> <510B900B.1030406@oracle.com> <510C008A.2000107@oracle.com> <510C32D2.2080508@oracle.com> <51363BCD.7070700@oracle.com> <51388AB6.4000504@oracle.com> <51389446.1000405@oracle.com> <513895EF.6040001@oracle.com> <513E6C33.7040700@oracle.com> <51405EAA.2080301@oracle.com> Message-ID: <51407536.6090305@oracle.com> Thank you for your suggestions. Do you have any old bug in java deployment for my reference? In addition, I wonder whether the same language problem exists when calling strerror() function. Thanks! -Dan On 03/13/2013 04:10 AM, Alexey Utkin wrote: > On 12.03.2013 3:43, Dan Xu wrote: >> Thanks for all your comments. I have updated the fix accordingly. >> Please see the webrev at >> http://cr.openjdk.java.net/~dxu/8001334/webrev.02/. >> >> For the language concern in getLastErrorString(char *buf, size_t len) >> function, I will log another bug and address it later. Thanks! > Ok. That is a common place for Windows platform: you got a problem > each time you are using ASCII API with Java. I spent some time while > resolving that kind of problems in Java deployment. > > -uta >> >> -Dan >> >> >> On Thu 07 Mar 2013 05:28:15 AM PST, Alan Bateman wrote: >>> On 07/03/2013 13:21, Alexey Utkin wrote: >>>> Can I say two word about the file >>>> http://cr.openjdk.java.net/~dxu/8001334/webrev.01/src/windows/native/java/io/io_util_md.c.frames.html >>>> >>>> >>>> and function >>>> getLastErrorString(char *buf, size_t len) >>>> >>>> Here is the documentation for [FormatMessage]: >>>> http://msdn.microsoft.com/en-gb/library/windows/desktop/ms679351%28v=vs.85%29.aspx >>>> >>>> >>>> if you are using ASCII version of FormatMessage that is a good idea >>>> to have the direct reference to [FormatMessageA], not define. >>>> >>>> The second word is about the third world countries: Russia and China. >>>> Windows OS has localized version. The error messages on that systems >>>> would contains only [?] in the worst case. >>>> >>> It's good to re-examine this but just to mention that this is just >>> bringing over what is in os::lasterror (in >>> hotspot/src/os/windows/vm/os_windows.cpp). >>> >>> -Alan >>> >> > From jim.gish at oracle.com Wed Mar 13 15:28:01 2013 From: jim.gish at oracle.com (Jim Gish) Date: Wed, 13 Mar 2013 11:28:01 -0400 Subject: RFR: 8002070 Remove the stack search for a resource bundle for Logger to use In-Reply-To: <513A6B84.6080306@oracle.com> References: <51311CC4.5000106@oracle.com> <51335B15.9070809@oracle.com> <5136438B.9070205@oracle.com> <513A4CFF.50002@oracle.com> <513A68BD.7090805@oracle.com> <513A6B84.6080306@oracle.com> Message-ID: <51409B01.70702@oracle.com> Mandy, The CCC request has been approved. Please push the changeset at http://cr.openjdk.java.net/~jgish/Bug8002070-RemoveResourceBundleStackSearch.patch/ Thanks, Jim On 03/08/2013 05:51 PM, Mandy Chung wrote: > On 3/8/2013 2:39 PM, Jim Gish wrote: >> I've update the webrev with the suggested changes: >> http://cr.openjdk.java.net/~jgish/Bug8002070-RemoveResourceBundleStackSearch/ >> >> > > Thumbs up. Thanks for adding the comment in the test. I'd suggest to > take out the statement about "stack walk search" since this may be > confusing to others who read it as that code will no longer exist. > Please add this bug ID to @bug. > > thanks > Mandy > >> Thanks, >> Jim >> >> >> On 03/08/2013 03:41 PM, Mandy Chung wrote: >>> On 3/5/2013 11:12 AM, Jim Gish wrote: >>>>> For the LoggerResourceBundleRace test then does it have to run in >>>>> its own VM? >>>> Because we no longer search up the stack for the bundles, this test >>>> fails unless run in its own vm. However, to avoid this, I'll try >>>> to change the test to set the context classloader. >>> >>> I discussed with Jim. In jtreg samevm mode, the testclasses are not >>> in the classpath and thus the system classloader can't find the >>> resource bundle. Before the fix, the test finds the resource bundle >>> using the classloader on the stack which isn't the intent. >>> >>> Mandy >> >> -- >> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 >> Oracle Java Platform Group | Core Libraries Team >> 35 Network Drive >> Burlington, MA 01803 >> jim.gish at oracle.com -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From mandy.chung at oracle.com Wed Mar 13 15:40:55 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 13 Mar 2013 08:40:55 -0700 Subject: RFR: 8002070 Remove the stack search for a resource bundle for Logger to use In-Reply-To: <51409B01.70702@oracle.com> References: <51311CC4.5000106@oracle.com> <51335B15.9070809@oracle.com> <5136438B.9070205@oracle.com> <513A4CFF.50002@oracle.com> <513A68BD.7090805@oracle.com> <513A6B84.6080306@oracle.com> <51409B01.70702@oracle.com> Message-ID: <51409E07.7030603@oracle.com> Great, thanks! I'll push it for you. Mandy On 3/13/2013 8:28 AM, Jim Gish wrote: > Mandy, > > The CCC request has been approved. Please push the changeset at > http://cr.openjdk.java.net/~jgish/Bug8002070-RemoveResourceBundleStackSearch.patch/ > > > > Thanks, > Jim > > On 03/08/2013 05:51 PM, Mandy Chung wrote: >> On 3/8/2013 2:39 PM, Jim Gish wrote: >>> I've update the webrev with the suggested changes: >>> http://cr.openjdk.java.net/~jgish/Bug8002070-RemoveResourceBundleStackSearch/ >>> >>> >> >> Thumbs up. Thanks for adding the comment in the test. I'd suggest >> to take out the statement about "stack walk search" since this may be >> confusing to others who read it as that code will no longer exist. >> Please add this bug ID to @bug. >> >> thanks >> Mandy >> >>> Thanks, >>> Jim >>> >>> >>> On 03/08/2013 03:41 PM, Mandy Chung wrote: >>>> On 3/5/2013 11:12 AM, Jim Gish wrote: >>>>>> For the LoggerResourceBundleRace test then does it have to run in >>>>>> its own VM? >>>>> Because we no longer search up the stack for the bundles, this >>>>> test fails unless run in its own vm. However, to avoid this, I'll >>>>> try to change the test to set the context classloader. >>>> >>>> I discussed with Jim. In jtreg samevm mode, the testclasses are >>>> not in the classpath and thus the system classloader can't find the >>>> resource bundle. Before the fix, the test finds the resource >>>> bundle using the classloader on the stack which isn't the intent. >>>> >>>> Mandy >>> >>> -- >>> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 >>> Oracle Java Platform Group | Core Libraries Team >>> 35 Network Drive >>> Burlington, MA 01803 >>> jim.gish at oracle.com > > -- > Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 > Oracle Java Platform Group | Core Libraries Team > 35 Network Drive > Burlington, MA 01803 > jim.gish at oracle.com From alan.bateman at oracle.com Wed Mar 13 18:02:17 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 13 Mar 2013 18:02:17 +0000 Subject: hg: jdk8/tl/jdk: 8009751: (se) Selector spin when select, close and interestOps(0) invoked at same time (lnx) Message-ID: <20130313180229.95508480F6@hg.openjdk.java.net> Changeset: e33cbbe21419 Author: alanb Date: 2013-03-13 17:58 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e33cbbe21419 8009751: (se) Selector spin when select, close and interestOps(0) invoked at same time (lnx) Reviewed-by: zhouyx, chegar, robm ! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java From mandy.chung at oracle.com Wed Mar 13 20:23:59 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 13 Mar 2013 13:23:59 -0700 Subject: Review Request for 8005428: Update jdeps to read the same profile information as by javac Message-ID: <5140E05F.3070809@oracle.com> This fix removes the temporary workaround for jdeps to print the profile information. The profiles information is embedded in ct.sym generated during the jdk build. jdeps will read ct.sym and parse the annotation to determine which profile a class belongs to. I have extended the test to test the profile information. Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8005428/webrev.00/ Thanks Mandy From mandy.chung at oracle.com Wed Mar 13 20:41:55 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 13 Mar 2013 20:41:55 +0000 Subject: hg: jdk8/tl/jdk: 8002070: Remove the stack search for a resource bundle for Logger to use Message-ID: <20130313204217.902A648100@hg.openjdk.java.net> Changeset: 94335b6ffb32 Author: jgish Date: 2013-03-13 11:24 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/94335b6ffb32 8002070: Remove the stack search for a resource bundle for Logger to use Summary: The fragile, vulnerable, stack crawling has been eliminated from findResourceBundle(String) Reviewed-by: mchung, alanb ! src/share/classes/java/util/logging/Logger.java ! test/java/util/logging/LoggerResourceBundleRace.java From joel.franck at oracle.com Wed Mar 13 21:04:41 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Wed, 13 Mar 2013 21:04:41 +0000 Subject: hg: jdk8/tl/langtools: 8006547: Repeating annotations: No Target on container annotation with all targets on base annotation gives compiler error Message-ID: <20130313210446.1ED5948102@hg.openjdk.java.net> Changeset: eb0198033c5c Author: jfranck Date: 2013-03-13 22:03 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/eb0198033c5c 8006547: Repeating annotations: No Target on container annotation with all targets on base annotation gives compiler error Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/annotations/repeatingAnnotations/DefaultTarget.java + test/tools/javac/annotations/repeatingAnnotations/DefaultTargetTypeParameter.java + test/tools/javac/annotations/repeatingAnnotations/DefaultTargetTypeParameter.out + test/tools/javac/annotations/repeatingAnnotations/DefaultTargetTypeUse.java + test/tools/javac/annotations/repeatingAnnotations/DefaultTargetTypeUse.out + test/tools/javac/annotations/repeatingAnnotations/NoTargetOnContainer.java + test/tools/javac/annotations/repeatingAnnotations/NoTargetOnContainer2.java From bhavesh.x.patel at oracle.com Wed Mar 13 21:47:41 2013 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Wed, 13 Mar 2013 21:47:41 +0000 Subject: hg: jdk8/tl/langtools: 8009684: Default top left frame should be "All Packages" in the generated javadoc documentation Message-ID: <20130313214744.A7D3448104@hg.openjdk.java.net> Changeset: e0ef84e33167 Author: bpatel Date: 2013-03-13 14:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e0ef84e33167 8009684: Default top left frame should be "All Packages" in the generated javadoc documentation Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java ! test/com/sun/javadoc/testProfiles/TestProfiles.java From dan.xu at oracle.com Wed Mar 13 22:00:40 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Wed, 13 Mar 2013 22:00:40 +0000 Subject: hg: jdk8/tl/jdk: 8001334: Remove use of JVM_* functions from java.io code Message-ID: <20130313220052.0F6B248106@hg.openjdk.java.net> Changeset: ef0c60b93a17 Author: dxu Date: 2013-03-13 14:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ef0c60b93a17 8001334: Remove use of JVM_* functions from java.io code Summary: Replace JVM_* functions with direct system calls in java io area Reviewed-by: alanb, uta, martin ! make/java/nio/Makefile ! makefiles/CompileNativeLibraries.gmk ! src/share/native/java/io/ObjectOutputStream.c ! src/share/native/java/io/io_util.c ! src/share/native/java/io/io_util.h ! src/solaris/native/common/jdk_util_md.h ! src/solaris/native/java/io/FileDescriptor_md.c ! src/solaris/native/java/io/UnixFileSystem_md.c ! src/solaris/native/java/io/io_util_md.c ! src/solaris/native/java/io/io_util_md.h ! src/windows/native/common/jdk_util_md.h ! src/windows/native/java/io/io_util_md.c ! src/windows/native/java/io/io_util_md.h From rob.mckenna at oracle.com Thu Mar 14 00:21:29 2013 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Thu, 14 Mar 2013 00:21:29 +0000 Subject: hg: jdk8/tl/jdk: 8009650: HttpClient available() check throws SocketException when connection has been closed Message-ID: <20130314002140.CE65748113@hg.openjdk.java.net> Changeset: f5c85c0a9af0 Author: robm Date: 2013-03-14 00:21 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f5c85c0a9af0 8009650: HttpClient available() check throws SocketException when connection has been closed Reviewed-by: chegar, khazra, dsamersoff Contributed-by: sdouglas at redhat.com ! src/share/classes/sun/net/www/http/HttpClient.java + test/sun/net/www/http/HttpClient/IsAvailable.java From jonathan.gibbons at oracle.com Thu Mar 14 01:43:03 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 13 Mar 2013 18:43:03 -0700 Subject: RFR: 8009428 and 8009429 - Profile related fixes and clean ups In-Reply-To: <513D3257.2030801@oracle.com> References: <51394373.4040404@oracle.com> <5139AD05.1060208@oracle.com> <5139CB49.5000601@oracle.com> <513D3257.2030801@oracle.com> Message-ID: <51412B27.2070907@oracle.com> The langtools changes look OK to me. -- Jon On 03/10/2013 06:24 PM, David Holmes wrote: > I had overlooked the need to update the ct.sym creation tool to > recognize the new syntax in the profile spec file. That process also > uncovered a few bugs in the listing that needed correcting. > > The javadoc generation of compact profile information is not quite > right, but that will be handled in a seperate bug. > > Updated webrevs at: > > http://cr.openjdk.java.net/~dholmes/8009428_8009429.v2/ > > --- > > http://cr.openjdk.java.net/~dholmes/8009428_8009429.v2/webrev.root/ > > No change from v1. Simply reverses the Nashorn change to $ processing. > > --- > > http://cr.openjdk.java.net/~dholmes/8009428_8009429.v2/webrev.langtools/ > > Updated the logic to look for FULL_JRE instead of PROFILE_4. And as a > result of that needed to make the logic explicitly aware that there > are 3 compact profiles plus the full JRE. > > --- > > http://cr.openjdk.java.net/~dholmes/8009428_8009429.v2/webrev.jdk/ > > Changes from v1: > > - I stopped trying to use a new wildcard syntax for included/excluded > types. The only options are *.class else a full type name with $ > replaced by $$. (The wildcard support would need more extensive > changes to the ct.sym tool and for 4 classes it isn't worth it). > > - Types explicitly excluded from one profile must be explicitly > included in a higher one (or the full JRE). (This happened to work by > accident because we were dealing with compact3 and a full JRE). > > - The package sun/beans no longer exists > > - Fixed up include packages to capture new types ie jdk instead of > jdk/internal so that we include the jdk.Supported annotation class > > - Removed additional redundant sub-packages > > Thanks for the follow up reviews. Erik's review stands as no further > changes made to the actual build logic. > > David > ----- > > On 8/03/2013 9:28 PM, David Holmes wrote: >> On 8/03/2013 7:19 PM, Alan Bateman wrote: >>> On 08/03/2013 01:48, David Holmes wrote: >>>> Not sure which is best list for this given Alan will likely be the >>>> only reviewer anyway :) >>>> >>>> Webrevs under: >>>> >>>> http://cr.openjdk.java.net/~dholmes/8009428_8009429/ >>> As further background to others, the reverting of the $ substitution >>> became possible when Nashorn removed $ from its generated classes [1]. >>> >>> I've looked through the changes and they look really good to me. >>> Putting >>> $< in single quotes to avoid shell expansion is the solution that I >>> could not find when adding the de-beaning recipes a few months ago. >>> It's >>> great to see PROFILE_4 renamed to FULL_JRE and is also great to remove >>> the redundant sub-packages from the include lists. For >>> profiles-rtjar-includes then I think it makes it much more readable and >>> maintainable. Two minor inconsistencies: the sub-packages of >>> javax.naming are listed and com/sun/jndi/ has a trailing slash. >> >> Fixed - well spotted! >> >>> One probable side effect of removing the redundant sub-packages will be >>> the javadoc. The one case to date where we didn't list sub-packages is >>> java.time (because there are still changes going on there) and that the >>> result is that the sub-packages of java.time don't show up in the >>> profiles view. I created 8008367 a few weeks for that and I suspect >>> that >>> once these changes are pushed that the profiles view will be very >>> incomplete. I don't think this should be a reason to hold off your >>> changes as the profiles view isn't right now anyway. Hopefully Bhavesh >>> will get to this soon. >> >> Now I'm a little concerned. I had not considered whether javac/javadoc >> considered these to be complete lists. They have to know how to combine >> the includes at a low-level with the excludes of a higher-level - and >> potentially vice-versa. >> >>> I think Erik should review this too as it's important that the build >>> changes in jdk8/tl will merge easily with changes going into >>> jdk8/build. >> >> OK. >> >> Thanks, >> David >> >>> -Alan. >>> >>> [1] http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fe5211fc3114 From gnu.andrew at redhat.com Thu Mar 14 02:19:45 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 Mar 2013 22:19:45 -0400 (EDT) Subject: [JSR310 M7 Review request] 8007572: Replace existing jdk timezone data at /lib/zi with JSR310's tzdb. In-Reply-To: <5114CABE.3070809@oracle.com> Message-ID: <1163719046.18271878.1363227585008.JavaMail.root@redhat.com> ----- Original Message ----- > The build part of this review looks good to me. > Judging by this changeset, I gather javazic is no longer being run. If so, why is the source code being retained in the tree? It means that a build of OpenJDK against itself now fails. The new build system currently finds the javazic source code and tries to compile it, but fails because ZoneInfoFile.java has changed and Gen.java can no longer compile against it. Deleting the javazic source code fixes the build. Any reason not to commit this? http://cr.openjdk.java.net/~andrew/build/javazic/webrev.01/ > /Erik > > On 2013-02-07 19:31, Xueming Shen wrote: > > Hi, > > > > 8007572: Replace existing jdk timezone data at /lib/zi > > with > > JSR310's tzdb. > > > > Webrev: > > http://cr.openjdk.java.net/~sherman/8007572/ > > > > Note: > > JDK/JRE has been using the time zone data at /lib/zi for > > j.u.TimeZone since JDK 1.4.0 [1]. JSR310 has introduced in its own > > time zone data file/format lib/tzdb.jar to provide the > > time > > zone data support for its new java.time date-time classes. > > > > So we now have two different time zone data files in different > > formats > > (though from the same time zone data source, Olson tz data, now the > > IANA > > Time Zone Datebase) to support two sets of date-time APIs > > (java.util > > date-time classes and java.time date-time classes) in one JDK/JRE, > > which > > definitely will add the maintenance burden going forward, given the > > fact > > that we will have to update/distribute the latest tzdb data in > > JDK/JRE > > periodically [2]. > > > > Also the current way the time-zone data is being > > distributed/installed > > (at /lib.zi, as individual file for each time zone) has > > been > > a footprint concern for some configurations, especially the small > > embedded > > environment. The JEP151 [3] was originally submitted to propose to > > store > > the time-zone data more efficiently into a single compressed file. > > The > > JEP 151 has been withdrawn since, with the assumption that JDK 8 > > may > > replace the "zi" data with the much smaller JSR310 tzdb data file. > > > > As indicated in JEP151, current installed "zi" directory probably > > takes > > up 1M of disk-space with the 0.5k default file-system-block-size. > > Even > > with the proposed "store in one single compressed file" approach, > > it will > > still take about 250K space for all tzdb data in "zi" directory. > > JSR310 > > tzdb data file however is much smaller. It is around 40K for > > compressed > > and 100k uncompressed, for the same tz data. > > > > The proposed change is to share the JSR310 time zone data tzdb.jar > > with j.u.TimeZone by converting the JSR310 tzdb data completely > > (bits > > to bits compatible) at runtime into the internal data structure > > that > > j.u.TimeZone needs for its time zone data functionality/needs. > > > > Thanks! > > -Sherman > > > > [1] https://jbs.oracle.com/bugs/browse/JDK-4230123 > > [2] > > http://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html > > [3] http://openjdk.java.net/jeps/151 > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From xueming.shen at oracle.com Thu Mar 14 02:51:45 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 13 Mar 2013 19:51:45 -0700 Subject: [JSR310 M7 Review request] 8007572: Replace existing jdk timezone data at /lib/zi with JSR310's tzdb. In-Reply-To: <1163719046.18271878.1363227585008.JavaMail.root@redhat.com> References: <1163719046.18271878.1363227585008.JavaMail.root@redhat.com> Message-ID: <51413B41.4010305@oracle.com> This should have been addessed via JDK-8008348 *The leftover jdk/make/tools/javazic causes build problems with hs25-b19 control job* -Sherman On 3/13/13 7:19 PM, Andrew Hughes wrote: > ----- Original Message ----- >> The build part of this review looks good to me. >> > Judging by this changeset, I gather javazic is no longer being run. > If so, why is the source code being retained in the tree? It means > that a build of OpenJDK against itself now fails. The new > build system currently finds the javazic source code and tries to compile it, > but fails because ZoneInfoFile.java has changed and Gen.java can no longer > compile against it. Deleting the javazic source code fixes the > build. > > Any reason not to commit this? > > http://cr.openjdk.java.net/~andrew/build/javazic/webrev.01/ > >> /Erik >> >> On 2013-02-07 19:31, Xueming Shen wrote: >>> Hi, >>> >>> 8007572: Replace existing jdk timezone data at /lib/zi >>> with >>> JSR310's tzdb. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sherman/8007572/ >>> >>> Note: >>> JDK/JRE has been using the time zone data at /lib/zi for >>> j.u.TimeZone since JDK 1.4.0 [1]. JSR310 has introduced in its own >>> time zone data file/format lib/tzdb.jar to provide the >>> time >>> zone data support for its new java.time date-time classes. >>> >>> So we now have two different time zone data files in different >>> formats >>> (though from the same time zone data source, Olson tz data, now the >>> IANA >>> Time Zone Datebase) to support two sets of date-time APIs >>> (java.util >>> date-time classes and java.time date-time classes) in one JDK/JRE, >>> which >>> definitely will add the maintenance burden going forward, given the >>> fact >>> that we will have to update/distribute the latest tzdb data in >>> JDK/JRE >>> periodically [2]. >>> >>> Also the current way the time-zone data is being >>> distributed/installed >>> (at /lib.zi, as individual file for each time zone) has >>> been >>> a footprint concern for some configurations, especially the small >>> embedded >>> environment. The JEP151 [3] was originally submitted to propose to >>> store >>> the time-zone data more efficiently into a single compressed file. >>> The >>> JEP 151 has been withdrawn since, with the assumption that JDK 8 >>> may >>> replace the "zi" data with the much smaller JSR310 tzdb data file. >>> >>> As indicated in JEP151, current installed "zi" directory probably >>> takes >>> up 1M of disk-space with the 0.5k default file-system-block-size. >>> Even >>> with the proposed "store in one single compressed file" approach, >>> it will >>> still take about 250K space for all tzdb data in "zi" directory. >>> JSR310 >>> tzdb data file however is much smaller. It is around 40K for >>> compressed >>> and 100k uncompressed, for the same tz data. >>> >>> The proposed change is to share the JSR310 time zone data tzdb.jar >>> with j.u.TimeZone by converting the JSR310 tzdb data completely >>> (bits >>> to bits compatible) at runtime into the internal data structure >>> that >>> j.u.TimeZone needs for its time zone data functionality/needs. >>> >>> Thanks! >>> -Sherman >>> >>> [1] https://jbs.oracle.com/bugs/browse/JDK-4230123 >>> [2] >>> http://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html >>> [3] http://openjdk.java.net/jeps/151 From yiming.wang at oracle.com Thu Mar 14 03:07:28 2013 From: yiming.wang at oracle.com (Eric Wang) Date: Thu, 14 Mar 2013 11:07:28 +0800 Subject: [PATCH] Review Request for 8009258: TEST_BUG: java/io/pathNames/GeneralWin32.java fails intermittently In-Reply-To: <51401CA3.30407@oracle.com> References: <5134DAB8.1070003@oracle.com> <5134DC6D.5010905@oracle.com> <51401CA3.30407@oracle.com> Message-ID: <51413EF0.5040006@oracle.com> Including more reviewer... Thanks, Eric On 2013/3/13 14:28, Eric Wang wrote: > Hi, > > Please review the code change, I have updated the test to make sure > test only access files and directories created by itself. > http://cr.openjdk.java.net/~ewang/8009258/webrev.01/ > > Here is the execution result: > http://cr.openjdk.java.net/~ewang/8009258/GeneralWin32.jtr > > Thanks, > Eric > On 2013/3/5 1:39, Alan Bateman wrote: >> On 04/03/2013 17:32, Eric Wang wrote: >>> Hi, >>> >>> Please help to review fix below for bug 8009258 >>> , >>> TEST_BUG:java/io/pathNames/GeneralWin32.java fails intermittently. >>> http://cr.openjdk.java.net/~ewang/8009258/webrev.00/ >>> >>> The File.canRead() method should not be used to check read >>> permission of a directory. >>> >>> Thanks, >>> Eric >> I wonder if it would be better to change this test so that it doesn't >> even attempt to poke around in these directories. I suggest this >> because there may be other activity going on at the same time. See >> also 8004096 where the test is running in agentvm mode and is >> straying into the directory used by another agent VM. >> >> -Alan > From david.holmes at oracle.com Thu Mar 14 04:26:28 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Mar 2013 14:26:28 +1000 Subject: [JSR310 M7 Review request] 8007572: Replace existing jdk timezone data at /lib/zi with JSR310's tzdb. In-Reply-To: <51413B41.4010305@oracle.com> References: <1163719046.18271878.1363227585008.JavaMail.root@redhat.com> <51413B41.4010305@oracle.com> Message-ID: <51415174.5010309@oracle.com> On 14/03/2013 12:51 PM, Xueming Shen wrote: > This should have been addessed via > > JDK-8008348 *The leftover jdk/make/tools/javazic causes build problems > with hs25-b19 control job* Which is still in the tl repo and unlikely to reach jdk8/jdk8 till b82 promotion next week. David > -Sherman > > On 3/13/13 7:19 PM, Andrew Hughes wrote: >> ----- Original Message ----- >>> The build part of this review looks good to me. >>> >> Judging by this changeset, I gather javazic is no longer being run. >> If so, why is the source code being retained in the tree? It means >> that a build of OpenJDK against itself now fails. The new >> build system currently finds the javazic source code and tries to >> compile it, >> but fails because ZoneInfoFile.java has changed and Gen.java can no >> longer >> compile against it. Deleting the javazic source code fixes the >> build. >> >> Any reason not to commit this? >> >> http://cr.openjdk.java.net/~andrew/build/javazic/webrev.01/ >> >>> /Erik >>> >>> On 2013-02-07 19:31, Xueming Shen wrote: >>>> Hi, >>>> >>>> 8007572: Replace existing jdk timezone data at /lib/zi >>>> with >>>> JSR310's tzdb. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sherman/8007572/ >>>> >>>> Note: >>>> JDK/JRE has been using the time zone data at /lib/zi for >>>> j.u.TimeZone since JDK 1.4.0 [1]. JSR310 has introduced in its own >>>> time zone data file/format lib/tzdb.jar to provide the >>>> time >>>> zone data support for its new java.time date-time classes. >>>> >>>> So we now have two different time zone data files in different >>>> formats >>>> (though from the same time zone data source, Olson tz data, now the >>>> IANA >>>> Time Zone Datebase) to support two sets of date-time APIs >>>> (java.util >>>> date-time classes and java.time date-time classes) in one JDK/JRE, >>>> which >>>> definitely will add the maintenance burden going forward, given the >>>> fact >>>> that we will have to update/distribute the latest tzdb data in >>>> JDK/JRE >>>> periodically [2]. >>>> >>>> Also the current way the time-zone data is being >>>> distributed/installed >>>> (at /lib.zi, as individual file for each time zone) has >>>> been >>>> a footprint concern for some configurations, especially the small >>>> embedded >>>> environment. The JEP151 [3] was originally submitted to propose to >>>> store >>>> the time-zone data more efficiently into a single compressed file. >>>> The >>>> JEP 151 has been withdrawn since, with the assumption that JDK 8 >>>> may >>>> replace the "zi" data with the much smaller JSR310 tzdb data file. >>>> >>>> As indicated in JEP151, current installed "zi" directory probably >>>> takes >>>> up 1M of disk-space with the 0.5k default file-system-block-size. >>>> Even >>>> with the proposed "store in one single compressed file" approach, >>>> it will >>>> still take about 250K space for all tzdb data in "zi" directory. >>>> JSR310 >>>> tzdb data file however is much smaller. It is around 40K for >>>> compressed >>>> and 100k uncompressed, for the same tz data. >>>> >>>> The proposed change is to share the JSR310 time zone data tzdb.jar >>>> with j.u.TimeZone by converting the JSR310 tzdb data completely >>>> (bits >>>> to bits compatible) at runtime into the internal data structure >>>> that >>>> j.u.TimeZone needs for its time zone data functionality/needs. >>>> >>>> Thanks! >>>> -Sherman >>>> >>>> [1] https://jbs.oracle.com/bugs/browse/JDK-4230123 >>>> [2] >>>> http://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html >>>> >>>> [3] http://openjdk.java.net/jeps/151 > From david.holmes at oracle.com Thu Mar 14 05:36:19 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Mar 2013 15:36:19 +1000 Subject: RFR: 8009428 and 8009429 - Profile related fixes and clean ups In-Reply-To: <513EFDCD.4040309@oracle.com> References: <51394373.4040404@oracle.com> <5139AD05.1060208@oracle.com> <5139CB49.5000601@oracle.com> <513D3257.2030801@oracle.com> <513D9BD1.6060807@oracle.com> <513ED503.6040000@oracle.com> <513EFDCD.4040309@oracle.com> Message-ID: <514161D3.9050601@oracle.com> Hi Alan, On 12/03/2013 8:05 PM, Alan Bateman wrote: > On 12/03/2013 07:10, David Holmes wrote: >> : >> >>> For the intro comment in profile-rtjar-includes.txt then it might be >>> useful to beef up the comment to explain what happens when an API >>> package does not match one of the rules, ie: does it go into compact1, >>> only the full JRE, or none. Also make it explicit that the form >>> DialogCallbackHandler*.class should not be used. I suggest this for the >>> benefit of someone needing to tweak this in the future. >> >> I have updated the webrev with additional commentary. > Thanks, that will be very useful to future maintainers. > >> >>> I have played with com.sun.tools.javac.sym.Profiles and so the changes >>> to MakefileProfiles look okay to me but Jon should really be the >>> reviewer for this. One thing about maxProfiles is that it should match >>> Profile.values.length maybe maxProfiles should not be hardcoded to 4. >> >> Sorry but what is Profiles.values.length? Previously we inferred the >> number of profiles from the fact that we failed to find PROFILE_n for >> some value n. That can't work (easily) now hence the hard limit. > I meant com.sun.tools.javac.jvm.Profile, it's an enum of the profiles so > it means that the knowledge about 3 + full JRE is now in two places. I decided not to do this because it turns out that "4" is hardwired within the internal debugging code of this class anyway. I'll file a RFE to clean this up in conjunction with the additional testing you mention below. Thanks, David > >> >>> Another thing is whether to add a test or beef up an existing test >>> (ProfileOptionTest.java in particular). >> >> What exactly is it that you would like to test for? > I think the test should include a few cases to cover a few selected > types in sub-packages to make sure they are in the right profile. > > -Alan. > > From david.holmes at oracle.com Thu Mar 14 05:51:31 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Thu, 14 Mar 2013 05:51:31 +0000 Subject: hg: jdk8/tl: 8009428: Revert changes to $ substitution performed as part of nashorn integration Message-ID: <20130314055131.A82AC48123@hg.openjdk.java.net> Changeset: 19a59a13b3ef Author: dholmes Date: 2013-03-14 01:41 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/19a59a13b3ef 8009428: Revert changes to $ substitution performed as part of nashorn integration Reviewed-by: alanb, erikj ! common/makefiles/MakeBase.gmk From david.holmes at oracle.com Thu Mar 14 05:52:29 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Thu, 14 Mar 2013 05:52:29 +0000 Subject: hg: jdk8/tl/jdk: 8009429: Miscellaneous profiles cleanup; ... Message-ID: <20130314055240.BC8A448125@hg.openjdk.java.net> Changeset: 41289b4a1819 Author: dholmes Date: 2013-03-14 01:47 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/41289b4a1819 8009429: Miscellaneous profiles cleanup 8009428: Revert changes to $ substitution performed as part of nashorn integration Reviewed-by: alanb, erikj ! makefiles/CreateJars.gmk ! makefiles/ProfileNames.gmk ! makefiles/Profiles.gmk ! makefiles/profile-includes.txt ! makefiles/profile-rtjar-includes.txt From david.holmes at oracle.com Thu Mar 14 05:52:11 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Thu, 14 Mar 2013 05:52:11 +0000 Subject: hg: jdk8/tl/langtools: 8009429: Miscellaneous profiles cleanup Message-ID: <20130314055216.9BF6A48124@hg.openjdk.java.net> Changeset: 82dc1e827c2a Author: dholmes Date: 2013-03-14 01:45 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/82dc1e827c2a 8009429: Miscellaneous profiles cleanup Reviewed-by: jjg, alanb ! src/share/classes/com/sun/tools/javac/sym/Profiles.java From david.holmes at oracle.com Thu Mar 14 05:58:12 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Mar 2013 15:58:12 +1000 Subject: tl forest update In-Reply-To: <20130314055131.A82AC48123@hg.openjdk.java.net> References: <20130314055131.A82AC48123@hg.openjdk.java.net> Message-ID: <514166F4.1090107@oracle.com> Sorry for the wide distribution but you all see the push messages anyway. I've just pushed a coordinated set of changes to the top-level, langtools and jdk repos in the tl forest. If you use tl you will need to ensure that you update all of these repos to ensure they are in sync. Thanks, David From Alan.Bateman at oracle.com Thu Mar 14 06:47:09 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Mar 2013 06:47:09 +0000 Subject: [JSR310 M7 Review request] 8007572: Replace existing jdk timezone data at /lib/zi with JSR310's tzdb. In-Reply-To: <51413B41.4010305@oracle.com> References: <1163719046.18271878.1363227585008.JavaMail.root@redhat.com> <51413B41.4010305@oracle.com> Message-ID: <5141726D.2090107@oracle.com> On 14/03/2013 02:51, Xueming Shen wrote: > This should have been addessed via > > JDK-8008348 *The leftover jdk/make/tools/javazic causes build problems > with hs25-b19 control job* > > Right, this was fixed several weeks ago with: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/43726ed11fb3 There are a lot of changes backed up in jdk8/tl due to several issues. Lana Steuck will be integrating them into jdk8/jdk8 soon. -Alan. From vicente.romero at oracle.com Thu Mar 14 08:31:30 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Thu, 14 Mar 2013 08:31:30 +0000 Subject: hg: jdk8/tl/langtools: 8008582: jtreg failures after conversion of shell tests to Java Message-ID: <20130314083137.5398D4812A@hg.openjdk.java.net> Changeset: 2e21ecd7a5ad Author: vromero Date: 2013-03-14 08:30 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2e21ecd7a5ad 8008582: jtreg failures after conversion of shell tests to Java Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/util/ArrayUtils.java ! test/tools/javac/4846262/CheckEBCDICLocaleTest.java ! test/tools/javac/ClassPathTest/ClassPathTest.java ! test/tools/javac/ProtectedInnerClass/ProtectedInnerClassesTest.java ! test/tools/javac/lib/ToolBox.java ! test/tools/javac/links/LinksTest.java ! test/tools/javac/newlines/NewLineTest.java ! test/tools/javah/6257087/T6257087.java ! test/tools/javah/constMacroTest/ConstMacroTest.java ! test/tools/javap/stackmap/StackmapTest.java From sundararajan.athijegannathan at oracle.com Thu Mar 14 14:03:38 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 14 Mar 2013 19:33:38 +0530 Subject: Please review fix for JDK-8010083: Fix ASM doc comments to avoid javadoc errors Message-ID: <5141D8BA.6060107@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8010083/ Thanks -Sundar From hannes.wallnoefer at oracle.com Thu Mar 14 14:47:44 2013 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 14 Mar 2013 15:47:44 +0100 Subject: Please review fix for JDK-8010083: Fix ASM doc comments to avoid javadoc errors In-Reply-To: <5141D8BA.6060107@oracle.com> References: <5141D8BA.6060107@oracle.com> Message-ID: <5141E310.8000305@oracle.com> Looks good to me. (Note that I'm not a core-libs reviewer though.) Hannes Am 2013-03-14 15:03, schrieb A. Sundararajan: > Please review http://cr.openjdk.java.net/~sundar/8010083/ > > Thanks > -Sundar From Alan.Bateman at oracle.com Thu Mar 14 15:20:38 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Mar 2013 15:20:38 +0000 Subject: Review Request for 8005428: Update jdeps to read the same profile information as by javac In-Reply-To: <5140E05F.3070809@oracle.com> References: <5140E05F.3070809@oracle.com> Message-ID: <5141EAC6.1080907@oracle.com> On 13/03/2013 20:23, Mandy Chung wrote: > This fix removes the temporary workaround for jdeps to print the > profile information. The profiles information is embedded in ct.sym > generated during the jdk build. jdeps will read ct.sym and parse the > annotation to determine which profile a class belongs to. I have > extended the test to test the profile information. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8005428/webrev.00/ I went through the webrev and it looks good to me (educational too as I only had a superficial understanding of the ct.sym before this). In initProfiles then this might be less code to get the right path: Path home = Paths.get(System.getProperty("java.home")); if (home.endsWith("jre")) home = home.getParent(); Path ctsym = home.resolve("lib").resolve("ct.sym"); For consistency then the constants with the annotation types should probably be uppercase. You've moved profiles.properties into the test tree to be used by the test. I think that is okay for the types that are tested but one thing to mention is that these properties file is out of date in a few places now. -Alan. From Alan.Bateman at oracle.com Thu Mar 14 15:29:49 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Mar 2013 15:29:49 +0000 Subject: Please review fix for JDK-8010083: Fix ASM doc comments to avoid javadoc errors In-Reply-To: <5141D8BA.6060107@oracle.com> References: <5141D8BA.6060107@oracle.com> Message-ID: <5141ECED.4000909@oracle.com> On 14/03/2013 14:03, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8010083/ > > Thanks > -Sundar This looks okay to me but do we want to be changing the ASM source? It has a few compiler warnings too. Maybe R?mi or someone closer to ASM could get the issues fixed upstream (if they aren't already) so that we are not out of sync. -Alan From gnu.andrew at redhat.com Thu Mar 14 16:09:13 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 14 Mar 2013 12:09:13 -0400 (EDT) Subject: Please review fix for JDK-8010083: Fix ASM doc comments to avoid javadoc errors In-Reply-To: <5141ECED.4000909@oracle.com> Message-ID: <1856342910.18861247.1363277353923.JavaMail.root@redhat.com> ----- Original Message ----- > On 14/03/2013 14:03, A. Sundararajan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8010083/ > > > > Thanks > > -Sundar > This looks okay to me but do we want to be changing the ASM source? > It > has a few compiler warnings too. Maybe R?mi or someone closer to ASM > could get the issues fixed upstream (if they aren't already) so that > we > are not out of sync. > I'd concur with that statement. Making local changes to upstream code can become a headache in the long run. So speaks the maintainer of a project that does just that with OpenJDK... ;) > -Alan > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Thu Mar 14 16:10:14 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 14 Mar 2013 12:10:14 -0400 (EDT) Subject: [JSR310 M7 Review request] 8007572: Replace existing jdk timezone data at /lib/zi with JSR310's tzdb. In-Reply-To: <51415174.5010309@oracle.com> Message-ID: <155408043.18863217.1363277414103.JavaMail.root@redhat.com> ----- Original Message ----- > On 14/03/2013 12:51 PM, Xueming Shen wrote: > > This should have been addessed via > > > > JDK-8008348 *The leftover jdk/make/tools/javazic causes build > > problems > > with hs25-b19 control job* > > > > Which is still in the tl repo and unlikely to reach jdk8/jdk8 till > b82 > promotion next week. > Yep, that's exactly why I'm seeing it. This is in an IcedTea build using the latest build drop, b80. Glad it's been caught and dealt with :) > David > > > -Sherman > > > > On 3/13/13 7:19 PM, Andrew Hughes wrote: > >> ----- Original Message ----- > >>> The build part of this review looks good to me. > >>> > >> Judging by this changeset, I gather javazic is no longer being > >> run. > >> If so, why is the source code being retained in the tree? It > >> means > >> that a build of OpenJDK against itself now fails. The new > >> build system currently finds the javazic source code and tries to > >> compile it, > >> but fails because ZoneInfoFile.java has changed and Gen.java can > >> no > >> longer > >> compile against it. Deleting the javazic source code fixes the > >> build. > >> > >> Any reason not to commit this? > >> > >> http://cr.openjdk.java.net/~andrew/build/javazic/webrev.01/ > >> > >>> /Erik > >>> > >>> On 2013-02-07 19:31, Xueming Shen wrote: > >>>> Hi, > >>>> > >>>> 8007572: Replace existing jdk timezone data at > >>>> /lib/zi > >>>> with > >>>> JSR310's tzdb. > >>>> > >>>> Webrev: > >>>> http://cr.openjdk.java.net/~sherman/8007572/ > >>>> > >>>> Note: > >>>> JDK/JRE has been using the time zone data at /lib/zi > >>>> for > >>>> j.u.TimeZone since JDK 1.4.0 [1]. JSR310 has introduced in its > >>>> own > >>>> time zone data file/format lib/tzdb.jar to provide > >>>> the > >>>> time > >>>> zone data support for its new java.time date-time classes. > >>>> > >>>> So we now have two different time zone data files in different > >>>> formats > >>>> (though from the same time zone data source, Olson tz data, now > >>>> the > >>>> IANA > >>>> Time Zone Datebase) to support two sets of date-time APIs > >>>> (java.util > >>>> date-time classes and java.time date-time classes) in one > >>>> JDK/JRE, > >>>> which > >>>> definitely will add the maintenance burden going forward, given > >>>> the > >>>> fact > >>>> that we will have to update/distribute the latest tzdb data in > >>>> JDK/JRE > >>>> periodically [2]. > >>>> > >>>> Also the current way the time-zone data is being > >>>> distributed/installed > >>>> (at /lib.zi, as individual file for each time zone) > >>>> has > >>>> been > >>>> a footprint concern for some configurations, especially the > >>>> small > >>>> embedded > >>>> environment. The JEP151 [3] was originally submitted to propose > >>>> to > >>>> store > >>>> the time-zone data more efficiently into a single compressed > >>>> file. > >>>> The > >>>> JEP 151 has been withdrawn since, with the assumption that JDK 8 > >>>> may > >>>> replace the "zi" data with the much smaller JSR310 tzdb data > >>>> file. > >>>> > >>>> As indicated in JEP151, current installed "zi" directory > >>>> probably > >>>> takes > >>>> up 1M of disk-space with the 0.5k default > >>>> file-system-block-size. > >>>> Even > >>>> with the proposed "store in one single compressed file" > >>>> approach, > >>>> it will > >>>> still take about 250K space for all tzdb data in "zi" directory. > >>>> JSR310 > >>>> tzdb data file however is much smaller. It is around 40K for > >>>> compressed > >>>> and 100k uncompressed, for the same tz data. > >>>> > >>>> The proposed change is to share the JSR310 time zone data > >>>> tzdb.jar > >>>> with j.u.TimeZone by converting the JSR310 tzdb data completely > >>>> (bits > >>>> to bits compatible) at runtime into the internal data structure > >>>> that > >>>> j.u.TimeZone needs for its time zone data functionality/needs. > >>>> > >>>> Thanks! > >>>> -Sherman > >>>> > >>>> [1] https://jbs.oracle.com/bugs/browse/JDK-4230123 > >>>> [2] > >>>> http://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html > >>>> > >>>> [3] http://openjdk.java.net/jeps/151 > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From mandy.chung at oracle.com Thu Mar 14 16:56:16 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 14 Mar 2013 09:56:16 -0700 Subject: Review Request for 8005428: Update jdeps to read the same profile information as by javac In-Reply-To: <5141EAC6.1080907@oracle.com> References: <5140E05F.3070809@oracle.com> <5141EAC6.1080907@oracle.com> Message-ID: <51420130.5000509@oracle.com> On 3/14/13 8:20 AM, Alan Bateman wrote: > On 13/03/2013 20:23, Mandy Chung wrote: >> This fix removes the temporary workaround for jdeps to print the >> profile information. The profiles information is embedded in ct.sym >> generated during the jdk build. jdeps will read ct.sym and parse the >> annotation to determine which profile a class belongs to. I have >> extended the test to test the profile information. >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8005428/webrev.00/ > I went through the webrev and it looks good to me (educational too as > I only had a superficial understanding of the ct.sym before this). Thanks for the review. Updated webrev: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8005428/webrev.01/ > > In initProfiles then this might be less code to get the right path: > > Path home = Paths.get(System.getProperty("java.home")); > if (home.endsWith("jre")) > home = home.getParent(); > Path ctsym = home.resolve("lib").resolve("ct.sym"); > > For consistency then the constants with the annotation types should > probably be uppercase. > I have made these changes. > You've moved profiles.properties into the test tree to be used by the > test. I think that is okay for the types that are tested but one thing > to mention is that these properties file is out of date in a few > places now. > Yes I didn't bother to update it as it's only used by the test. I added a comment to avoid any confusion. Thanks Mandy From alan.bateman at oracle.com Thu Mar 14 16:55:54 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 14 Mar 2013 16:55:54 +0000 Subject: hg: jdk8/tl/jdk: 8005716: Enhance JNI specification to allow support of static JNI libraries in Embedded JREs Message-ID: <20130314165617.BB6D74814D@hg.openjdk.java.net> Changeset: f010eb1e696f Author: alanb Date: 2013-03-14 16:03 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f010eb1e696f 8005716: Enhance JNI specification to allow support of static JNI libraries in Embedded JREs Reviewed-by: dlong, alanb, mduigou Contributed-by: bill.pittore at oracle.com, bob.vandette at oracle.com ! make/java/java/mapfile-vers ! makefiles/mapfiles/libjava/mapfile-vers ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/Runtime.java ! src/share/classes/java/lang/System.java ! src/share/javavm/export/jni.h ! src/share/native/common/jni_util.h ! src/share/native/java/lang/ClassLoader.c ! src/solaris/native/common/jni_util_md.c ! src/windows/native/common/jni_util_md.c From alan.bateman at oracle.com Thu Mar 14 17:01:28 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 14 Mar 2013 17:01:28 +0000 Subject: hg: jdk8/tl/jdk: 7183800: TEST_BUG: Update tests to run on Ubuntu 12.04 (localhost is 127.0.1.1) Message-ID: <20130314170139.BAE4D4814E@hg.openjdk.java.net> Changeset: ca9469a15792 Author: alanb Date: 2013-03-14 16:59 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ca9469a15792 7183800: TEST_BUG: Update tests to run on Ubuntu 12.04 (localhost is 127.0.1.1) Reviewed-by: alanb, chegar Contributed-by: yiming.wang at oracle.com ! test/java/nio/channels/DatagramChannel/Connect.java ! test/java/nio/channels/DatagramChannel/ConnectedSend.java ! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/Launcher.java ! test/javax/management/remote/mandatory/connection/RMIConnectionIdTest.java From Alan.Bateman at oracle.com Thu Mar 14 17:04:05 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Mar 2013 17:04:05 +0000 Subject: Review Request for 8005428: Update jdeps to read the same profile information as by javac In-Reply-To: <51420130.5000509@oracle.com> References: <5140E05F.3070809@oracle.com> <5141EAC6.1080907@oracle.com> <51420130.5000509@oracle.com> Message-ID: <51420305.2020205@oracle.com> On 14/03/2013 16:56, Mandy Chung wrote: > > Thanks for the review. Updated webrev: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8005428/webrev.01/ This looks good to me. -Alan From joe.darcy at oracle.com Thu Mar 14 17:14:04 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 14 Mar 2013 10:14:04 -0700 Subject: @Supported design issues In-Reply-To: <51293038.7090503@oracle.com> References: <51266B7C.3040804@oracle.com>, <5126D516.1040005@oracle.com>, , <5127C4D4.5090800@oracle.com>, <20130222150427.1712@eggemoggin.niobe.net> <51293038.7090503@oracle.com> Message-ID: <5142055C.3060408@oracle.com> FYI, I've submitted a JEP reviewed by Alan Bateman on "Capturing support and stability information about JDK classes in source and class files." -Joe From chris.hegarty at oracle.com Thu Mar 14 17:21:16 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 14 Mar 2013 17:21:16 +0000 Subject: RFR 8005696: Add CompletableFuture - JEP 155 Message-ID: <5142070C.6000709@oracle.com> As part of JEP 155 (Concurrency Updates) we are proposing to add CompletableFuture. A Future that may be explicitly completed (setting its value and status), and may include dependent functions and actions that trigger upon its completion. Specdiff: http://cr.openjdk.java.net/~chegar/8005696/specdiff/java/util/concurrent/package-summary.html Webrev: http://cr.openjdk.java.net/~chegar/8005696/webrev.00/webrev/ CompletableFuture, as usual, is coming from Doug Lea, with assistance from members of the former JCP JSR-166 Expert Group. I have already informally reviewed this. This is an official call for review before finalizing the API for inclusion in jdk8. Note: I still need to make some additions to the test for better coverage, but these should not be a blocker for this review. -Chris. From mandy.chung at oracle.com Thu Mar 14 17:35:31 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 14 Mar 2013 17:35:31 +0000 Subject: hg: jdk8/tl/langtools: 8005428: Update jdeps to read the same profile information as by javac Message-ID: <20130314173533.D94FC48150@hg.openjdk.java.net> Changeset: fd3fdaff0257 Author: mchung Date: 2013-03-14 10:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fd3fdaff0257 8005428: Update jdeps to read the same profile information as by javac Reviewed-by: alanb ! make/netbeans/langtools/nbproject/project.xml ! src/share/classes/com/sun/tools/jdeps/Analyzer.java ! src/share/classes/com/sun/tools/jdeps/ClassFileReader.java ! src/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/share/classes/com/sun/tools/jdeps/PlatformClassPath.java + src/share/classes/com/sun/tools/jdeps/Profiles.java ! src/share/classes/com/sun/tools/jdeps/resources/jdeps.properties - src/share/classes/com/sun/tools/jdeps/resources/jdk.properties ! test/tools/jdeps/Basic.java ! test/tools/jdeps/p/Foo.java + test/tools/jdeps/profiles.properties From naoto.sato at oracle.com Thu Mar 14 18:30:25 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 14 Mar 2013 18:30:25 +0000 Subject: hg: jdk8/tl/jdk: 8008576: Calendar mismatch using Host LocaleProviderAdapter Message-ID: <20130314183045.3F77648151@hg.openjdk.java.net> Changeset: d79503c4c56f Author: naoto Date: 2013-03-14 11:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d79503c4c56f 8008576: Calendar mismatch using Host LocaleProviderAdapter Reviewed-by: okutsu ! make/java/java/FILES_java.gmk ! src/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/sun/util/locale/LanguageTag.java ! src/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java + src/share/classes/sun/util/locale/provider/CalendarProviderImpl.java ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java + src/share/classes/sun/util/spi/CalendarProvider.java ! src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java ! src/windows/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c From martinrb at google.com Fri Mar 15 03:25:51 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 14 Mar 2013 20:25:51 -0700 Subject: RFR 8005696: Add CompletableFuture - JEP 155 In-Reply-To: <5142070C.6000709@oracle.com> References: <5142070C.6000709@oracle.com> Message-ID: Doing a mini-audit of these methods, here is a change to what seems to be the intent: Index: ./java/util/concurrent/CompletableFuture.java =================================================================== RCS file: /export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/CompletableFuture.java,v retrieving revision 1.55 diff -u -U 7 -r1.55 CompletableFuture.java --- ./java/util/concurrent/CompletableFuture.java 16 Feb 2013 21:25:55 -0000 1.55 +++ ./java/util/concurrent/CompletableFuture.java 15 Mar 2013 03:23:26 -0000 @@ -1683,35 +1683,35 @@ */ public CompletableFuture thenAccept(Consumer block) { return doThenAccept(block, null); } /** * Creates and returns a CompletableFuture that is asynchronously - * completed using the {@link ForkJoinPool#commonPool()} with this - * CompletableFuture's result when it completes. If this - * CompletableFuture completes exceptionally, then the returned - * CompletableFuture also does so, with a CompletionException holding - * this exception as its cause. + * completed after performing the given action using the {@link + * ForkJoinPool#commonPool()} with this CompletableFuture's result + * when it completes. If this CompletableFuture completes + * exceptionally, then the returned CompletableFuture also does so, + * with a CompletionException holding this exception as its cause. * * @param block the action to perform before completing the * returned CompletableFuture * @return the new CompletableFuture */ public CompletableFuture thenAcceptAsync(Consumer block) { return doThenAccept(block, ForkJoinPool.commonPool()); } /** * Creates and returns a CompletableFuture that is asynchronously - * completed using the given executor with this - * CompletableFuture's result when it completes. If this - * CompletableFuture completes exceptionally, then the returned - * CompletableFuture also does so, with a CompletionException holding - * this exception as its cause. + * completed after performing the given action using the given + * executor with this CompletableFuture's result when it completes. + * If this CompletableFuture completes exceptionally, then the + * returned CompletableFuture also does so, with a CompletionException + * holding this exception as its cause. * * @param block the action to perform before completing the * returned CompletableFuture * @param executor the executor to use for asynchronous execution * @return the new CompletableFuture */ public CompletableFuture thenAcceptAsync(Consumer block, On Thu, Mar 14, 2013 at 10:21 AM, Chris Hegarty wrote: > As part of JEP 155 (Concurrency Updates) we are proposing to add > CompletableFuture. A Future that may be explicitly completed (setting its > value and status), and may include dependent functions and actions that > trigger upon its completion. > > Specdiff: > > http://cr.openjdk.java.net/~**chegar/8005696/specdiff/java/** > util/concurrent/package-**summary.html > Webrev: > http://cr.openjdk.java.net/~**chegar/8005696/webrev.00/**webrev/ > > CompletableFuture, as usual, is coming from Doug Lea, with assistance from > members of the former JCP JSR-166 Expert Group. I have already informally > reviewed this. This is an official call for review before finalizing the > API for inclusion in jdk8. > > Note: > I still need to make some additions to the test for better coverage, but > these should not be a blocker for this review. > > -Chris. > From christian.thalinger at oracle.com Fri Mar 15 03:31:55 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 14 Mar 2013 20:31:55 -0700 Subject: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK Message-ID: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com> [This is the HotSpot part of JEP 176] http://cr.openjdk.java.net/~twisti/7198429 7198429: need checked categorization of caller-sensitive methods in the JDK Reviewed-by: More information in JEP 176: http://openjdk.java.net/jeps/176 src/share/vm/ci/ciMethod.cpp src/share/vm/ci/ciMethod.hpp src/share/vm/classfile/classFileParser.cpp src/share/vm/classfile/classFileParser.hpp src/share/vm/classfile/javaClasses.hpp src/share/vm/classfile/systemDictionary.hpp src/share/vm/classfile/vmSymbols.hpp src/share/vm/oops/method.cpp src/share/vm/oops/method.hpp src/share/vm/opto/library_call.cpp src/share/vm/prims/jvm.cpp src/share/vm/prims/methodHandles.cpp src/share/vm/prims/unsafe.cpp src/share/vm/runtime/vframe.cpp src/share/vm/runtime/vframe.hpp From robert.field at oracle.com Fri Mar 15 05:55:20 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Fri, 15 Mar 2013 05:55:20 +0000 Subject: hg: jdk8/tl/langtools: 8010010: NPE generating serializedLambdaName for nested lambda Message-ID: <20130315055525.7183448174@hg.openjdk.java.net> Changeset: fbbf5376e7e4 Author: rfield Date: 2013-03-14 22:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fbbf5376e7e4 8010010: NPE generating serializedLambdaName for nested lambda Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/LambdaLambdaSerialized.java From vicente.romero at oracle.com Fri Mar 15 09:03:49 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 15 Mar 2013 09:03:49 +0000 Subject: hg: jdk8/tl/langtools: 5053846: javac: MethodRef entries are duplicated in the constant pool Message-ID: <20130315090356.3245148179@hg.openjdk.java.net> Changeset: fa24eba012bd Author: vromero Date: 2013-03-15 09:02 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fa24eba012bd 5053846: javac: MethodRef entries are duplicated in the constant pool Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/T5053846/MethodRefDupInConstantPoolTest.java From alexey.utkin at oracle.com Fri Mar 15 09:20:34 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Fri, 15 Mar 2013 13:20:34 +0400 Subject: Review request: JDK-8006193 (process) Clean-up java.lang.ProcessImpl.finalize, does not need to be public. Message-ID: <5142E7E2.1080502@oracle.com> Bug description: https://jbs.oracle.com/bugs/browse/JDK-8006193 http://bugs.sun.com/view_bug.do?bug_id=8006193 Here is the suggested trivial fix: http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8006193/ Summary: Makes [FindBug] code analyzer happy. - public void finalize() { + protected void finalize() { Regards, -uta From Alan.Bateman at oracle.com Fri Mar 15 09:56:30 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Mar 2013 09:56:30 +0000 Subject: Review request: JDK-8006193 (process) Clean-up java.lang.ProcessImpl.finalize, does not need to be public. In-Reply-To: <5142E7E2.1080502@oracle.com> References: <5142E7E2.1080502@oracle.com> Message-ID: <5142F04E.7050201@oracle.com> On 15/03/2013 09:20, Alexey Utkin wrote: > > > Summary: > Makes [FindBug] code analyzer happy. > - public void finalize() { > + protected void finalize() { This looks fine to me, it's a package-private class so there's no issue. -Alan. From dl at cs.oswego.edu Fri Mar 15 12:00:43 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 15 Mar 2013 08:00:43 -0400 Subject: RFR 8005696: Add CompletableFuture - JEP 155 In-Reply-To: References: <5142070C.6000709@oracle.com> Message-ID: <51430D6B.4060601@cs.oswego.edu> On 03/14/13 23:25, Martin Buchholz wrote: > Doing a mini-audit of these methods, here is a change to what seems to be the > intent: Yes, thanks! This keeps the exception specs consistent across similar methods. -Doug > > Index: ./java/util/concurrent/CompletableFuture.java > =================================================================== > RCS file: > /export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/CompletableFuture.java,v > retrieving revision 1.55 > diff -u -U 7 -r1.55 CompletableFuture.java > --- ./java/util/concurrent/CompletableFuture.java16 Feb 2013 21:25:55 -00001.55 > +++ ./java/util/concurrent/CompletableFuture.java15 Mar 2013 03:23:26 -0000 > @@ -1683,35 +1683,35 @@ > */ > public CompletableFuture thenAccept(Consumer block) { > return doThenAccept(block, null); > } > /** > * Creates and returns a CompletableFuture that is asynchronously > - * completed using the {@link ForkJoinPool#commonPool()} with this > - * CompletableFuture's result when it completes. If this > - * CompletableFuture completes exceptionally, then the returned > - * CompletableFuture also does so, with a CompletionException holding > - * this exception as its cause. > + * completed after performing the given action using the {@link > + * ForkJoinPool#commonPool()} with this CompletableFuture's result > + * when it completes. If this CompletableFuture completes > + * exceptionally, then the returned CompletableFuture also does so, > + * with a CompletionException holding this exception as its cause. > * > * @param block the action to perform before completing the > * returned CompletableFuture > * @return the new CompletableFuture > */ > public CompletableFuture thenAcceptAsync(Consumer block) { > return doThenAccept(block, ForkJoinPool.commonPool()); > } > /** > * Creates and returns a CompletableFuture that is asynchronously > - * completed using the given executor with this > - * CompletableFuture's result when it completes. If this > - * CompletableFuture completes exceptionally, then the returned > - * CompletableFuture also does so, with a CompletionException holding > - * this exception as its cause. > + * completed after performing the given action using the given > + * executor with this CompletableFuture's result when it completes. > + * If this CompletableFuture completes exceptionally, then the > + * returned CompletableFuture also does so, with a CompletionException > + * holding this exception as its cause. > * > * @param block the action to perform before completing the > * returned CompletableFuture > * @param executor the executor to use for asynchronous execution > * @return the new CompletableFuture > */ > public CompletableFuture thenAcceptAsync(Consumer block, > > > > On Thu, Mar 14, 2013 at 10:21 AM, Chris Hegarty > wrote: > > As part of JEP 155 (Concurrency Updates) we are proposing to add > CompletableFuture. A Future that may be explicitly completed (setting its > value and status), and may include dependent functions and actions that > trigger upon its completion. > > Specdiff: > > http://cr.openjdk.java.net/~__chegar/8005696/specdiff/java/__util/concurrent/package-__summary.html > > Webrev: > http://cr.openjdk.java.net/~__chegar/8005696/webrev.00/__webrev/ > > > CompletableFuture, as usual, is coming from Doug Lea, with assistance from > members of the former JCP JSR-166 Expert Group. I have already informally > reviewed this. This is an official call for review before finalizing the API > for inclusion in jdk8. > > Note: > I still need to make some additions to the test for better coverage, but > these should not be a blocker for this review. > > -Chris. > > From joel.franck at oracle.com Fri Mar 15 12:41:20 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Fri, 15 Mar 2013 12:41:20 +0000 Subject: hg: jdk8/tl/langtools: 8007767: TargetAnnoCombo.java need to be updated to add a new test mode Message-ID: <20130315124125.EF12E4817E@hg.openjdk.java.net> Changeset: 195b71850b56 Author: mnunez Date: 2013-03-15 13:39 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/195b71850b56 8007767: TargetAnnoCombo.java need to be updated to add a new test mode Reviewed-by: jjg, strarup ! test/tools/javac/annotations/repeatingAnnotations/combo/Helper.java ! test/tools/javac/annotations/repeatingAnnotations/combo/TargetAnnoCombo.java - test/tools/javac/annotations/repeatingAnnotations/combo/TestCaseGenerator.java From chris.hegarty at oracle.com Fri Mar 15 13:43:38 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 15 Mar 2013 13:43:38 +0000 Subject: RFR 8005696: Add CompletableFuture - JEP 155 In-Reply-To: <51430D6B.4060601@cs.oswego.edu> References: <5142070C.6000709@oracle.com> <51430D6B.4060601@cs.oswego.edu> Message-ID: <5143258A.9020906@oracle.com> On 15/03/2013 12:00, Doug Lea wrote: > On 03/14/13 23:25, Martin Buchholz wrote: >> Doing a mini-audit of these methods, here is a change to what seems to >> be the >> intent: > > Yes, thanks! This keeps the exception specs consistent across similar > methods. Now that I reread these method descriptions, I think thenAcceptBothXXX suffer the same problem: diff -u -U 7 CompletableFuture.java_FROM_WEBREV.00 CompletableFuture.java --- CompletableFuture.java_FROM_WEBREV.00 Fri Mar 15 11:43:32 2013 +++ CompletableFuture.java Fri Mar 15 13:39:09 2013 @@ -412,14 +412,15 @@ /* ------------- Async tasks -------------- */ /** * A tagging interface identifying asynchronous tasks produced by * {@code async} methods. This may be useful for monitoring, * debugging, and tracking asynchronous activities. + * @since 1.8 */ public static interface AsynchronousCompletionTask { } /** Base class can act as either FJ or plain Runnable */ abstract static class Async extends ForkJoinTask implements Runnable, AsynchronousCompletionTask { @@ -2008,19 +2009,19 @@ helpPostComplete(); other.helpPostComplete(); return dst; } /** * Creates and returns a CompletableFuture that is completed with - * the results of this and the other given CompletableFuture if - * both complete. If this and/or the other CompletableFuture - * complete exceptionally, then the returned CompletableFuture - * also does so, with a CompletionException holding one of these - * exceptions as its cause. + * the result of the given function of this and the other given + * CompletableFuture if both complete. If this and/or the other + * CompletableFuture complete exceptionally, then the returned + * CompletableFuture also does so, with a CompletionException + * holding one of these exceptions as its cause. * * @param other the other CompletableFuture * @param block the action to perform before completing the * returned CompletableFuture * @return the new CompletableFuture */ public CompletableFuture thenAcceptBoth @@ -2028,19 +2029,19 @@ BiConsumer block) { return doThenBiAccept(other, block, null); } /** * Creates and returns a CompletableFuture that is completed * asynchronously using the {@link ForkJoinPool#commonPool()} with - * the results of this and the other given CompletableFuture when - * both complete. If this and/or the other CompletableFuture - * complete exceptionally, then the returned CompletableFuture - * also does so, with a CompletionException holding one of these - * exceptions as its cause. + * the result of the given function of this and the other given + * CompletableFuture if both complete. If this and/or the other + * CompletableFuture complete exceptionally, then the returned + * CompletableFuture also does so, with a CompletionException + * holding one of these exceptions as its cause. * * @param other the other CompletableFuture * @param block the action to perform before completing the * returned CompletableFuture * @return the new CompletableFuture */ public CompletableFuture thenAcceptBothAsync @@ -2047,19 +2048,19 @@ (CompletableFuture other, BiConsumer block) { return doThenBiAccept(other, block, ForkJoinPool.commonPool()); } /** * Creates and returns a CompletableFuture that is completed - * asynchronously using the given executor with the results of - * this and the other given CompletableFuture when both complete. - * If this and/or the other CompletableFuture complete exceptionally, - * then the returned CompletableFuture also does so, with a - * CompletionException holding one of these exceptions as its cause. + * asynchronously using the given executor with the results of the + * given function of this and the other given CompletableFuture if + * both complete. If this and/or the other CompletableFuture complete + * exceptionally, then the returned CompletableFuture also does so, + * with a CompletionException holding one of these exceptions as its cause. * * @param other the other CompletableFuture * @param block the action to perform before completing the * returned CompletableFuture * @param executor the executor to use for asynchronous execution * @return the new CompletableFuture */ -Chris. > > -Doug > > >> >> Index: ./java/util/concurrent/CompletableFuture.java >> =================================================================== >> RCS file: >> /export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/CompletableFuture.java,v >> >> retrieving revision 1.55 >> diff -u -U 7 -r1.55 CompletableFuture.java >> --- ./java/util/concurrent/CompletableFuture.java16 Feb 2013 21:25:55 >> -00001.55 >> +++ ./java/util/concurrent/CompletableFuture.java15 Mar 2013 03:23:26 >> -0000 >> @@ -1683,35 +1683,35 @@ >> */ >> public CompletableFuture thenAccept(Consumer block) { >> return doThenAccept(block, null); >> } >> /** >> * Creates and returns a CompletableFuture that is asynchronously >> - * completed using the {@link ForkJoinPool#commonPool()} with this >> - * CompletableFuture's result when it completes. If this >> - * CompletableFuture completes exceptionally, then the returned >> - * CompletableFuture also does so, with a CompletionException holding >> - * this exception as its cause. >> + * completed after performing the given action using the {@link >> + * ForkJoinPool#commonPool()} with this CompletableFuture's result >> + * when it completes. If this CompletableFuture completes >> + * exceptionally, then the returned CompletableFuture also does so, >> + * with a CompletionException holding this exception as its cause. >> * >> * @param block the action to perform before completing the >> * returned CompletableFuture >> * @return the new CompletableFuture >> */ >> public CompletableFuture thenAcceptAsync(Consumer >> block) { >> return doThenAccept(block, ForkJoinPool.commonPool()); >> } >> /** >> * Creates and returns a CompletableFuture that is asynchronously >> - * completed using the given executor with this >> - * CompletableFuture's result when it completes. If this >> - * CompletableFuture completes exceptionally, then the returned >> - * CompletableFuture also does so, with a CompletionException holding >> - * this exception as its cause. >> + * completed after performing the given action using the given >> + * executor with this CompletableFuture's result when it completes. >> + * If this CompletableFuture completes exceptionally, then the >> + * returned CompletableFuture also does so, with a CompletionException >> + * holding this exception as its cause. >> * >> * @param block the action to perform before completing the >> * returned CompletableFuture >> * @param executor the executor to use for asynchronous execution >> * @return the new CompletableFuture >> */ >> public CompletableFuture thenAcceptAsync(Consumer block, >> >> >> >> On Thu, Mar 14, 2013 at 10:21 AM, Chris Hegarty > > wrote: >> >> As part of JEP 155 (Concurrency Updates) we are proposing to add >> CompletableFuture. A Future that may be explicitly completed (setting its >> value and status), and may include dependent functions and actions that >> trigger upon its completion. >> >> Specdiff: >> >> http://cr.openjdk.java.net/~__chegar/8005696/specdiff/java/__util/concurrent/package-__summary.html >> >> >> >> Webrev: >> http://cr.openjdk.java.net/~__chegar/8005696/webrev.00/__webrev/ >> >> >> CompletableFuture, as usual, is coming from Doug Lea, with assistance >> from >> members of the former JCP JSR-166 Expert Group. I have already informally >> reviewed this. This is an official call for review before finalizing >> the API >> for inclusion in jdk8. >> >> Note: >> I still need to make some additions to the test for better coverage, but >> these should not be a blocker for this review. >> >> -Chris. >> >> > From sundararajan.athijegannathan at oracle.com Fri Mar 15 14:01:26 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Fri, 15 Mar 2013 14:01:26 +0000 Subject: hg: jdk8/tl/jdk: 8010136: Make jrunscript's init.js to work on nashorn Message-ID: <20130315140149.457B248180@hg.openjdk.java.net> Changeset: 46ad8dfabd5f Author: sundar Date: 2013-03-15 19:30 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46ad8dfabd5f 8010136: Make jrunscript's init.js to work on nashorn Reviewed-by: lagergren, hannesw ! src/share/classes/com/sun/tools/script/shell/init.js From kumar.x.srinivasan at oracle.com Fri Mar 15 14:31:06 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 15 Mar 2013 07:31:06 -0700 Subject: Please review fix for JDK-8010083: Fix ASM doc comments to avoid javadoc errors In-Reply-To: <1856342910.18861247.1363277353923.JavaMail.root@redhat.com> References: <1856342910.18861247.1363277353923.JavaMail.root@redhat.com> Message-ID: <514330AA.9040903@oracle.com> I concur too, I will chat with the Objectweb folks and see what needs to be done. Kumar > ----- Original Message ----- >> On 14/03/2013 14:03, A. Sundararajan wrote: >>> Please review http://cr.openjdk.java.net/~sundar/8010083/ >>> >>> Thanks >>> -Sundar >> This looks okay to me but do we want to be changing the ASM source? >> It >> has a few compiler warnings too. Maybe R?mi or someone closer to ASM >> could get the issues fixed upstream (if they aren't already) so that >> we >> are not out of sync. >> > I'd concur with that statement. Making local changes to upstream code > can become a headache in the long run. So speaks the maintainer of > a project that does just that with OpenJDK... ;) > >> -Alan >> From mark.reinhold at oracle.com Fri Mar 15 21:12:49 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 15 Mar 2013 14:12:49 -0700 Subject: @Supported design issues In-Reply-To: <5134EED7.3040900@oracle.com> References: <51266B7C.3040804@oracle.com>, <20130228113121.144747@eggemoggin.niobe.net>, <5134EED7.3040900@oracle.com> Message-ID: <20130315141249.582558@eggemoggin.niobe.net> 2013/3/4 2:58 -0800, joe.darcy at oracle.com: > On 02/28/2013 11:31 AM, mark.reinhold at oracle.com wrote: >> 2013/2/23 5:10 -0800, joe.darcy at oracle.com: >>> Having Supported take a boolean value both allows the explicit statement >>> that an item is not supported as well as providing a possible transition >>> path from Supported(true) to Supported(false) to removed. >> >> Okay. In that scenario what's the role of the existing @Deprecated >> annotation? > > @Deprecated generally applies to all clients of an API. I don't think > people tend to associate potential removal of an API with deprecation > because we haven't (yet) removed any deprecated Java SE APIs from the > platform since to date we have placed a higher value on preserving > binary compatibility. I'm continually surprised by developers I meet at conferences who (sometimes angrily) demand that deprecated APIs be removed, so I think the reality is a mixed bag -- not that it matters a great deal either way. What I'm trying to understand is, for a JDK API that's @Supported(true) in one or more releases, what's the recommended protocol for removing it? Perhaps something like this? @Supported(true) @Supported(true) @Deprecated @Supported(false) (Time flows downward.) Or does @Supported(false) happen when @Deprecated is applied? Or will usage vary? > The deprecated-in-JDK-7 and JDK-specific apt API was removed in JDK 8, > but that is the only removal of a deprecated API from the JDK I'm aware > of offhand. I suspect that's correct. > The jdk.Supported annotation is mostly a statement to users outside of > the JDK itself. Understood. >> ... >> >> I'm still wondering whether marking a package "@Supported(true)" means >> that I can use "@Supported(false)" on some of its member types. That >> would be convenient for cases such as the JMX OSMBeanFactory class that >> Alan mentioned. > > If a package has a mixture of supported and non-supported types, I would > say it should either *not* have a @jdk.Supported annotation itself, or > if the types in the package were predominately one value or another, > then the package annotation should match the prevailing value of the types. > > Since types have a more concrete existence then packages, I regard the > jdk.Supported information on package-info files to have a higher mixture > of informative versus normative sentiment compared to the annotation on > types. If we're going to go to the trouble of defining an annotation for this, and then sprinkle that annotation throughout our code, shouldn't we give it as precise a meaning as possible? It'd be a shame for @Supported (or whatever it turns out to be) to have no more authoritative value than, say, the @since javadoc tag. >>> ... >> >> What I don't understand is how doing all this with an annotation would >> be any harder to circumvent than what we have today. Are you proposing >> to do something stronger than issue a compiler warning when people try >> to use an unsupported API? > > The ct.sym mechanism we have today is compile-time only and the > mechanism and all its warnings can be circumvented by adding a single > option to javac; the option is described on stackoverflow, amongst other > places. Therefore, it is fairly easy for someone to claim "but I didn't > know" in regards to the status of a JDK-specific API. Well, sure. > Since any jdk.Supported annotations applied to types are more localized > and more specific ("*this* type is or is not supported / stable / etc.") > it is both easier for JDK developers to made incremental changes to the > JDK code base and is it also easier for users of those types to see what > is going on since any inspection of the types can reveal the annotation > value. Agreed, but I was trying to understand how the annotation-based system would be harder to "cirvumvent", at either compile time or run time. >> ... >> >> Even if we think we only need two explicit levels today, a design that >> admits expansion is preferable to one that forever limits us to just two >> values. An annotation that takes an enum, to which we can add values >> over time, would be more future-proof. > > Technically, it would be possible to evolve a boolean-valued annotation > to one that included a non-boolean value as well by adding a new method > that had a default to the annotation type. For example > > // Version 1 > @interfaced Supported { > boolean value() default true; > } > > // Version 2 > @interface Supported { > boolean value() default true; > Stability stability() default STABLE; > } Yuck. > However, if what we eventually want to capture is "stability level" > rather than supported-ness than having a single stability value from the > start would of course be preferable. > > That said, it terms of the exercise of going over the inventory of > existing types, I think it can be helpful to at first be constrained to > making a binary supported / not-supported determination to avoid the > temptation to overuse a middle-of-the-road value like EVOLVING. > > Types that don't fit well into supported / not-supported classification > can help drive what other distinctions are useful to make. Agreed. >>>> - The retention policy of the annotation is RUNTIME. Is that really >>>> what we want? I'd have expected CLASS. >>> >>> CLASS is not very helpful (and certainly not a helpful default). A >>> CLASS-retention annotation can be reliably used at the compile-time of >>> other code. For the use case of Supported, I think it is more helpful to >>> allow runtime querying of the property. >> >> What run-time use cases do you have in mind? > > Allowing class loaders and other run-time tools to query the annotation > value and take some action, like log a warning or potentially refuse to > link. Okay, that sounds plausible. > ... > > As an aside, going forward I think we should make greater use of the > "jdk.*" namespace for JDK-specific types. The JDK codebase has outlasted > Sun Microsystems (R.I.P.) and therefore the natural lifetime of > "com.sun.*." APIs. The JDK has also outlasted both of Sun Microsystems' > ticker symbols (SUNW, and JAVA); as I understand their conventions, > ticker symbols are a preferred component of Solaris package names. The > "jdk" name will be appropriate as long as the JDK is around. I have long supported this position -- jdk.* is the place to be for new non-Platform, non-proprietary APIs. >> I did just notice that the annotation's source file is in the langtools >> repo rather than the jdk repo. What's the rationale for that? I think >> most JDK developers would expect to find it in the jdk repo. > > As covered in other responses, while the jdk repo is the natural home, > langtools was for bootstrapping reasons. Hmm. Okay. - Mark From joe.darcy at oracle.com Sat Mar 16 01:16:36 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 15 Mar 2013 18:16:36 -0700 Subject: @Supported design issues In-Reply-To: <20130315141249.582558@eggemoggin.niobe.net> References: <51266B7C.3040804@oracle.com>, <20130228113121.144747@eggemoggin.niobe.net>, <5134EED7.3040900@oracle.com> <20130315141249.582558@eggemoggin.niobe.net> Message-ID: <5143C7F4.8080006@oracle.com> On 03/15/2013 02:12 PM, mark.reinhold at oracle.com wrote: > 2013/3/4 2:58 -0800, joe.darcy at oracle.com: >> On 02/28/2013 11:31 AM, mark.reinhold at oracle.com wrote: >>> 2013/2/23 5:10 -0800, joe.darcy at oracle.com: >>>> Having Supported take a boolean value both allows the explicit statement >>>> that an item is not supported as well as providing a possible transition >>>> path from Supported(true) to Supported(false) to removed. >>> Okay. In that scenario what's the role of the existing @Deprecated >>> annotation? >> @Deprecated generally applies to all clients of an API. I don't think >> people tend to associate potential removal of an API with deprecation >> because we haven't (yet) removed any deprecated Java SE APIs from the >> platform since to date we have placed a higher value on preserving >> binary compatibility. > I'm continually surprised by developers I meet at conferences who > (sometimes angrily) demand that deprecated APIs be removed, so I think > the reality is a mixed bag -- not that it matters a great deal either > way. > > What I'm trying to understand is, for a JDK API that's @Supported(true) > in one or more releases, what's the recommended protocol for removing > it? Perhaps something like this? > > @Supported(true) > @Supported(true) @Deprecated > @Supported(false) > > > (Time flows downward.) > > Or does @Supported(false) happen when @Deprecated is applied? > > Or will usage vary? The general threshold we've been using to apply @Deprecated is that a API must be actively harmful rather than just ill-advised. However, a few methods have been deprecated in Java SE 8 because they are slated for removal in 9 as part of modularization. I would favor a shorter sequence of either @Supported(true) @Supported(false) @Deprecated or even just @Supported(true) @Supported(false) since using the API may not be harmful per se, other than risky in the sense the API is going away in the future. Using deprecation for the apt API was appropriate since that was the only documentation convention and warning-producing mechanism in place at the time. Deprecating the listener methods in pack200 in Java SE 8 is appropriate since they are Java SE API elements and not (JDK - Java SE) API elements. However, if we have a sufficiently rich supported/stable annotation, we might not need to combine usage of that annotation with @Deprecated. [snip] > >>> ... >>> >>> I'm still wondering whether marking a package "@Supported(true)" means >>> that I can use "@Supported(false)" on some of its member types. That >>> would be convenient for cases such as the JMX OSMBeanFactory class that >>> Alan mentioned. >> If a package has a mixture of supported and non-supported types, I would >> say it should either *not* have a @jdk.Supported annotation itself, or >> if the types in the package were predominately one value or another, >> then the package annotation should match the prevailing value of the types. >> >> Since types have a more concrete existence then packages, I regard the >> jdk.Supported information on package-info files to have a higher mixture >> of informative versus normative sentiment compared to the annotation on >> types. > If we're going to go to the trouble of defining an annotation for this, > and then sprinkle that annotation throughout our code, shouldn't we give > it as precise a meaning as possible? It'd be a shame for @Supported (or > whatever it turns out to be) to have no more authoritative value than, > say, the @since javadoc tag. The main point I was making here is that package-info information has a less concrete existence than information about types, because, for example, it is possible to configure a build so that multiple package-info files exist for the same package (the jdk docs build gives a warning about this situation for some XML-processing code). > >>>> ... >>> What I don't understand is how doing all this with an annotation would >>> be any harder to circumvent than what we have today. Are you proposing >>> to do something stronger than issue a compiler warning when people try >>> to use an unsupported API? >> The ct.sym mechanism we have today is compile-time only and the >> mechanism and all its warnings can be circumvented by adding a single >> option to javac; the option is described on stackoverflow, amongst other >> places. Therefore, it is fairly easy for someone to claim "but I didn't >> know" in regards to the status of a JDK-specific API. > Well, sure. > >> Since any jdk.Supported annotations applied to types are more localized >> and more specific ("*this* type is or is not supported / stable / etc.") >> it is both easier for JDK developers to made incremental changes to the >> JDK code base and is it also easier for users of those types to see what >> is going on since any inspection of the types can reveal the annotation >> value. > Agreed, but I was trying to understand how the annotation-based system > would be harder to "cirvumvent", at either compile time or run time. It is harder to plead ignorance of the supported status of the API since any inspection of it can reveal the annotation whereas a single change in the javac command line can silence all ct.sym warnings. Cheers, -Joe From sadhak001 at gmail.com Sat Mar 16 16:28:30 2013 From: sadhak001 at gmail.com (Mani Sarkar) Date: Sat, 16 Mar 2013 16:28:30 +0000 Subject: JTReg JCK tests failing on MacOS & Ubuntu Message-ID: Hi, I have come across these issues when running the JCK tests using jtreg. I'm advised that these tests require access and also more configuration. *jck7compiler (logs: http://bit.ly/13NkHTG)* *Error: Unable to access jarfile /java/re/jck/7/promoted/latest/binaries/JCK-compiler-7/lib/jtjck.jar* *Missing file: /Users/openjdk/sources/jdk8_tl/jdk/test/../build/macosx-i586/testoutput/jck7compiler/JTreport/text/summary.txt * *EXIT CODE: 1* *make[2]: *** [_generic_jck_tests] Error 1* *make[1]: *** [jck7compiler] Error 2* *make: *** [jck7compiler] Error 2* *jck7devtools **(logs: http://bit.ly/Y4P4zI)* *Error: Unable to access jarfile /java/re/jck/7/promoted/latest/binaries/JCK-devtools-7/lib/jtjck.jar* *Missing file: /Users/**openjdk** /sources/jdk8_tl/jdk/test/../build/macosx-i586/testoutput/jck7devtools/JTreport/text/summary.txt * *EXIT CODE: 1* *make[2]: *** [_generic_jck_tests] Error 1* *make[1]: *** [jck7devtools] Error 2* *make: *** [jck7devtools] Error 2* *jck7runtime (logs: http://bit.ly/WAFCa5)* *Error: Unable to access jarfile /java/re/jck/7/promoted/latest/binaries/JCK-runtime-7/lib/jtjck.jar* *Missing file: /Users/**openjdk** /sources/jdk8_tl/jdk/test/../build/macosx-i586/testoutput/jck7runtime/JTreport/text/summary.txt * *EXIT CODE: 1* *make[2]: *** [_generic_jck_tests] Error 1* *make[1]: *** [jck7runtime] Error 2* *make: *** [jck7runtime] Error 2* * * Can I please suggest to make these error messages a bit more verbose and human-friendly as an improvement. If the tests are restricted to a certain group / class of users it would help to mention that in the error message and suggestions if they might help. I'll take my experience away to update my documentation of these tests. * * Thanks. * * Regards, mani -- *Twitter:* @theNeomatrix369 *Blog:* http://neomatrix369.wordpress.com *JUG activity:* LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project:* https://github.com/MutabilityDetector *Come to Devoxx UK 2013:* http://www.devoxx.com/display/UK13/Home *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From Alan.Bateman at oracle.com Sat Mar 16 20:15:36 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 16 Mar 2013 20:15:36 +0000 Subject: JTReg JCK tests failing on MacOS & Ubuntu In-Reply-To: References: Message-ID: <5144D2E8.1080708@oracle.com> On 16/03/2013 16:28, Mani Sarkar wrote: > Hi, > > I have come across these issues when running the JCK tests using jtreg. I'm > advised that these tests require access and also more configuration. > > : > > Can I please suggest to make these error messages a bit more verbose and > human-friendly as an improvement. If the tests are restricted to a certain > group / class of users it would help to mention that in the error message > and suggestions if they might help. > > I'll take my experience away to update my documentation of these tests. > I'm not sure that these make targets are actually used. I think they were added as an experiment to try out running the (non-open) JCK in Oracle's internal build+test system. It's possible they could be removed as part of the ongoing effort to re-work this make file. To my knowledge, these make targets were never documented and I can only assume you just happen to spot them in the test/Makefile. If you are looking to run the jdk tests via the make file then the jdk* make targets should be used. -Alan. From daniel.latremoliere at gmail.com Sat Mar 16 21:10:31 2013 From: daniel.latremoliere at gmail.com (=?ISO-8859-1?Q?Daniel_Latr=E9moli=E8re?=) Date: Sat, 16 Mar 2013 22:10:31 +0100 Subject: @Supported design issues In-Reply-To: <20130315141249.582558@eggemoggin.niobe.net> References: <51266B7C.3040804@oracle.com>, <20130228113121.144747@eggemoggin.niobe.net>, <5134EED7.3040900@oracle.com> <20130315141249.582558@eggemoggin.niobe.net> Message-ID: <5144DFC7.6090306@gmail.com> > I'm continually surprised by developers I meet at conferences who > (sometimes angrily) demand that deprecated APIs be removed, so I think > the reality is a mixed bag -- not that it matters a great deal either > way. Just a personal opinion as a developer. Java APIs are very big and removing deprecated APIs can reduce this size. It will help solving this question: "what can be the name of the currently needed class/method in all these APIs?", which is very important, particularly for new Java developers, frequently lost in these numerous APIs. Readability is the biggest design feature of Java, then I think there is some logic if developers ask for removal of deprecated API, because it will improve readability of APIs. From lana.steuck at oracle.com Sun Mar 17 05:57:41 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 17 Mar 2013 05:57:41 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20130317055750.9B76A481E9@hg.openjdk.java.net> Changeset: c88bb21560cc Author: katleman Date: 2013-03-07 11:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c88bb21560cc Added tag jdk8-b80 for changeset b0224010e2f0 ! .hgtags Changeset: d8d8032d02d7 Author: katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/d8d8032d02d7 Added tag jdk8-b81 for changeset c88bb21560cc ! .hgtags From lana.steuck at oracle.com Sun Mar 17 05:57:37 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 17 Mar 2013 05:57:37 +0000 Subject: hg: jdk8/tl/corba: 11 new changesets Message-ID: <20130317055749.2EB07481E8@hg.openjdk.java.net> Changeset: 2a00aeeb466b Author: katleman Date: 2013-03-07 11:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/2a00aeeb466b Added tag jdk8-b80 for changeset 5f3d4a6bdd02 ! .hgtags Changeset: 0ac9424678e7 Author: katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/0ac9424678e7 Added tag jdk8-b81 for changeset 2a00aeeb466b ! .hgtags Changeset: 05386b4610e9 Author: lana Date: 2013-03-12 16:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/05386b4610e9 Merge Changeset: 3c73273667ae Author: coffeys Date: 2012-10-30 17:06 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/3c73273667ae 8000631: Restrict access to class constructor Reviewed-by: alanb, ahgross ! make/com/sun/corba/minclude/com_sun_corba_se_impl_orbutil.jmk ! src/share/classes/com/sun/corba/se/impl/corba/AnyImpl.java ! src/share/classes/com/sun/corba/se/impl/encoding/CDRInputStream_1_0.java ! src/share/classes/com/sun/corba/se/impl/encoding/CDROutputStream_1_0.java ! src/share/classes/com/sun/corba/se/impl/io/FVDCodeBaseImpl.java ! src/share/classes/com/sun/corba/se/impl/io/ValueHandlerImpl.java ! src/share/classes/com/sun/corba/se/impl/io/ValueUtility.java ! src/share/classes/com/sun/corba/se/impl/javax/rmi/CORBA/Util.java ! src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3_1.java ! src/share/classes/com/sun/corba/se/impl/orbutil/ORBUtility.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3_1.java ! src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdFactory.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3_1.java + src/share/classes/sun/corba/JavaCorbaAccess.java + src/share/classes/sun/corba/SharedSecrets.java Changeset: 80882eae6279 Author: ngmr Date: 2012-10-30 17:15 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/80882eae6279 8000540: Improve IIOP type reuse management Reviewed-by: alanb, ahgross, coffeys ! src/share/classes/com/sun/corba/se/impl/io/ObjectStreamClass.java Changeset: 0ca1fc7c5f44 Author: mbankal Date: 2012-12-17 07:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/0ca1fc7c5f44 7141694: Improving CORBA internals Reviewed-by: coffeys, ahgross ! src/share/classes/com/sun/corba/se/spi/orb/ORB.java Changeset: f4f39d873b9a Author: coffeys Date: 2012-11-06 15:50 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/f4f39d873b9a 7201066: Change modifiers on unused fields Reviewed-by: alanb, skoivu ! src/share/classes/com/sun/corba/se/impl/activation/ServerMain.java ! src/share/classes/com/sun/corba/se/impl/io/ObjectStreamClass.java ! src/share/classes/com/sun/corba/se/impl/orbutil/ObjectStreamClass_1_3_1.java Changeset: 59bff16bc0bf Author: ewendeli Date: 2013-02-19 21:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/59bff16bc0bf Merge - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3_1.java Changeset: 996bd5fd0941 Author: ewendeli Date: 2013-02-25 07:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/996bd5fd0941 Merge - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3_1.java Changeset: 7341134e52ff Author: lana Date: 2013-03-12 18:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/7341134e52ff Merge - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3_1.java Changeset: 48e1bc77004d Author: lana Date: 2013-03-14 19:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/48e1bc77004d Merge From lana.steuck at oracle.com Sun Mar 17 05:57:37 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 17 Mar 2013 05:57:37 +0000 Subject: hg: jdk8/tl: 10 new changesets Message-ID: <20130317055738.4ED1E481E7@hg.openjdk.java.net> Changeset: 907a926d3c96 Author: erikj Date: 2013-03-04 16:45 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/907a926d3c96 8004352: build-infra: Limit JOBS on large machines Reviewed-by: mduigou ! common/autoconf/build-performance.m4 ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/help.m4 ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/spec.gmk.in ! common/makefiles/JavaCompilation.gmk ! common/makefiles/Main.gmk Changeset: cd7f2c7e2a0e Author: katleman Date: 2013-03-07 11:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/cd7f2c7e2a0e Added tag jdk8-b80 for changeset 907a926d3c96 ! .hgtags Changeset: 52741ab7c601 Author: erikj Date: 2013-03-06 10:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/52741ab7c601 8008073: build-infra: Need --with-dxsdk option? And awt/sound -I option additions? Reviewed-by: tbell ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 ! common/autoconf/toolchain_windows.m4 Changeset: 235854886494 Author: katleman Date: 2013-03-11 13:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/235854886494 Merge Changeset: 145dbc56f931 Author: tbell Date: 2013-03-12 22:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/145dbc56f931 8009819: build-infra: RE jdk8 build forest fails for windows since addition of --with-dxsdk Reviewed-by: katleman ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain_windows.m4 Changeset: 0dc28db6525f Author: katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/0dc28db6525f Added tag jdk8-b81 for changeset 145dbc56f931 ! .hgtags Changeset: 980ccff2d4f5 Author: lana Date: 2013-03-12 16:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/980ccff2d4f5 Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/makefiles/Main.gmk Changeset: 22b9a31a92eb Author: lana Date: 2013-03-13 23:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/22b9a31a92eb Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: a69761ae281b Author: lana Date: 2013-03-14 19:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/a69761ae281b Merge Changeset: 4984ac509993 Author: lana Date: 2013-03-15 23:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/4984ac509993 Merge From lana.steuck at oracle.com Sun Mar 17 05:57:36 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 17 Mar 2013 05:57:36 +0000 Subject: hg: jdk8/tl/jaxp: 7 new changesets Message-ID: <20130317055802.134E6481EA@hg.openjdk.java.net> Changeset: ef3495555a4c Author: katleman Date: 2013-03-07 11:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/ef3495555a4c Added tag jdk8-b80 for changeset 4873a0499bc3 ! .hgtags Changeset: 94000590f01f Author: katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/94000590f01f Added tag jdk8-b81 for changeset ef3495555a4c ! .hgtags Changeset: f4898ff0aff1 Author: joehw Date: 2012-12-12 15:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/f4898ff0aff1 8001235: Improve JAXP HTTP handling Reviewed-by: lancea, skoivu ! src/com/sun/org/apache/xpath/internal/functions/FuncSystemProperty.java Changeset: 3206516132e8 Author: ewendeli Date: 2013-02-19 21:45 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/3206516132e8 Merge Changeset: 46ce56a4e40f Author: ewendeli Date: 2013-02-25 07:22 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/46ce56a4e40f Merge Changeset: 8a0cb78fefbc Author: lana Date: 2013-03-12 18:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/8a0cb78fefbc Merge Changeset: d5a58291f09a Author: lana Date: 2013-03-14 19:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d5a58291f09a Merge From lana.steuck at oracle.com Sun Mar 17 05:57:54 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 17 Mar 2013 05:57:54 +0000 Subject: hg: jdk8/tl/langtools: 5 new changesets Message-ID: <20130317055811.0DCBC481EB@hg.openjdk.java.net> Changeset: ed69d087fdfd Author: katleman Date: 2013-03-07 11:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ed69d087fdfd Added tag jdk8-b80 for changeset a8227c617684 ! .hgtags Changeset: 58289451d9ed Author: katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/58289451d9ed Added tag jdk8-b81 for changeset ed69d087fdfd ! .hgtags Changeset: 39f8eb897ec6 Author: lana Date: 2013-03-12 16:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/39f8eb897ec6 Merge - test/tools/apt/Basics/NullAPF.java - test/tools/apt/Basics/apt.sh - test/tools/apt/verifyVariables.sh - test/tools/javac/4846262/Test.java - test/tools/javac/4846262/Test.out - test/tools/javac/4846262/Test.sh - test/tools/javac/6302184/T6302184.sh - test/tools/javac/ClassPathTest/ClassPathTest.sh - test/tools/javac/ClassPathTest/ClassPathTest1.java - test/tools/javac/ClassPathTest/ClassPathTest2.java - test/tools/javac/ClassPathTest/ClassPathTest3.java - test/tools/javac/ClassPathTest/bar/pkg/ClassPathTestAux2.java - test/tools/javac/ClassPathTest/foo/pkg/ClassPathTestAux1.java - test/tools/javac/ClassPathTest/pkg/ClassPathTestAux3.java - test/tools/javac/ExtDirs/ExtDirTest_1.java - test/tools/javac/ExtDirs/ExtDirTest_2.java - test/tools/javac/ExtDirs/ExtDirTest_3.java - test/tools/javac/ExtDirs/ExtDirs.sh - test/tools/javac/MethodParameters.java - test/tools/javac/MissingInclude.java - test/tools/javac/MissingInclude.sh - test/tools/javac/ProtectedInnerClass/ProtectedInnerClass.sh - test/tools/javac/ProtectedInnerClass/ProtectedInnerClass_2.java - test/tools/javac/ProtectedInnerClass/p1/ProtectedInnerClass1.java - test/tools/javac/ProtectedInnerClass/p2/ProtectedInnerClass2.java - test/tools/javac/ProtectedInnerClass/p2/ProtectedInnerClass3.java - test/tools/javac/T5090006/T5090006.java - test/tools/javac/T5090006/compiler.sh - test/tools/javac/constDebug/ConstDebug.java - test/tools/javac/constDebug/ConstDebug.sh - test/tools/javac/fatalErrors/NoJavaLang.java - test/tools/javac/fatalErrors/NoJavaLang.out - test/tools/javac/fatalErrors/NoJavaLang.sh - test/tools/javac/generics/diamond/T6939780.java - test/tools/javac/generics/diamond/T6939780.out - test/tools/javac/innerClassFile/Driver.sh - test/tools/javac/innerClassFile/x/B.java - test/tools/javac/innerClassFile/x/C.java - test/tools/javac/innerClassFile/y/Main.java - test/tools/javac/innerClassFile/y/R1.java - test/tools/javac/innerClassFile/y/R2.java - test/tools/javac/innerClassFile/y/R3.java - test/tools/javac/javazip/A.java - test/tools/javac/javazip/Test.sh - test/tools/javac/javazip/bad/B.java - test/tools/javac/javazip/good/B.java - test/tools/javac/links/T.java - test/tools/javac/links/b/B.java - test/tools/javac/links/links.sh - test/tools/javac/newlines/Newlines.sh - test/tools/javac/stackmap/T4955930.java - test/tools/javac/stackmap/T4955930.sh - test/tools/javac/unicode/SupplementaryJavaID6.sh - test/tools/javah/6257087/foo.java - test/tools/javah/6257087/foo.sh - test/tools/javah/6257087/foo_bar.h - test/tools/javah/ConstMacroTest.sh - test/tools/javah/MissingParamClassException.java - test/tools/javah/MissingParamClassTest.sh - test/tools/javah/ParamClassTest.java - test/tools/javah/SubClassConsts.java - test/tools/javah/SubClassConsts.out - test/tools/javah/SubClassConsts.win - test/tools/javah/SuperClassConsts.java - test/tools/javap/NotPackagePrivateInterface.java - test/tools/javap/PublicInterfaceTest.sh - test/tools/javap/pathsep.sh - test/tools/javap/stackmap/T6271292.java - test/tools/javap/stackmap/T6271292.out - test/tools/javap/stackmap/T6271292.sh Changeset: 825da6847791 Author: lana Date: 2013-03-14 19:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/825da6847791 Merge Changeset: a3049f4a7987 Author: lana Date: 2013-03-15 23:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a3049f4a7987 Merge From lana.steuck at oracle.com Sun Mar 17 05:58:56 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 17 Mar 2013 05:58:56 +0000 Subject: hg: jdk8/tl/hotspot: 72 new changesets Message-ID: <20130317060119.D3613481EC@hg.openjdk.java.net> Changeset: be1fbee20765 Author: amurillo Date: 2013-02-22 10:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/be1fbee20765 8008692: new hotspot build - hs25-b21 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 1b0dc9f87e75 Author: mgerdin Date: 2013-02-19 18:45 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1b0dc9f87e75 8006753: fix failed for JDK-8002415 White box testing API for HotSpot Summary: Modify WhiteBoxAPI to use interface classes from test/testlibrary instead, add ClassFileInstaller to resolve the boot class path issue Reviewed-by: ctornqvi, dsamersoff, coleenp, kvn ! make/Makefile ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/vm.make - make/bsd/makefiles/wb.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/vm.make - make/linux/makefiles/wb.make ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/vm.make - make/solaris/makefiles/wb.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/defs.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/product.make - make/windows/makefiles/wb.make - src/share/tools/whitebox/sun/hotspot/WhiteBox.java - src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java ! src/share/vm/runtime/arguments.cpp ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java ! test/compiler/whitebox/SetDontInlineMethodTest.java ! test/runtime/NMT/AllocTestType.java ! test/runtime/NMT/PrintNMTStatistics.java ! test/runtime/NMT/SummarySanityCheck.java ! test/sanity/WBApi.java ! test/serviceability/ParserTest.java + test/testlibrary/ClassFileInstaller.java + test/testlibrary/whitebox/sun/hotspot/WhiteBox.java + test/testlibrary/whitebox/sun/hotspot/parser/DiagnosticCommand.java Changeset: 4c1d8002ffb1 Author: hseigel Date: 2013-02-20 07:16 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4c1d8002ffb1 8004495: [parfait] False positive Buffer overflow in hotspot/src/os/linux/vm/os_linux.cpp Summary: Delete the questionable source code because it is for no-longer supported versions of Linux. Reviewed-by: mikael, coleenp ! src/os/linux/vm/os_linux.cpp Changeset: b861c8af2510 Author: hseigel Date: 2013-02-20 07:42 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b861c8af2510 Merge - make/bsd/makefiles/wb.make - make/linux/makefiles/wb.make - make/solaris/makefiles/wb.make - make/windows/makefiles/wb.make - src/share/tools/whitebox/sun/hotspot/WhiteBox.java - src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java Changeset: b6d5b3e50379 Author: dcubed Date: 2013-02-20 19:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b6d5b3e50379 6799919: Recursive calls to report_vm_out_of_memory are handled incorrectly Summary: report_vm_out_of_memory() should allow VMError.report_and_die() to handle multiple out of native memory errors. Reviewed-by: dcubed, dholmes, coleenp, acorn Contributed-by: ron.durbin at oracle.com ! src/share/vm/utilities/debug.cpp Changeset: fc64254f5579 Author: zgu Date: 2013-02-21 07:50 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fc64254f5579 8008071: Crashed in promote_malloc_records() with Kitchensink after 19 days Summary: Added NULL pointer check for arena size record Reviewed-by: sspitsyn, dholmes ! src/share/vm/services/memSnapshot.cpp Changeset: 5ed317b25e23 Author: sla Date: 2013-02-22 10:03 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5ed317b25e23 7165259: Remove BugSpot Reviewed-by: coleenp, mgronlun ! agent/make/Makefile - agent/make/bugspot.bat ! agent/make/marks_notes.html ! agent/src/os/win32/windbg/sawindbg.cpp - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/JavaLineNumberInfo.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/Main.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PCFinder.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PackageScanner.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/RegisterPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTraceEntry.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTracePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/ThreadListPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/VariablePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/AddressTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/DoubleTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/EnumTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FieldTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FloatTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/LongTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/ObjectTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/BreakpointEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CIntegerAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CStringAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/Event.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ExceptionEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/JNIHandleAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ServiceabilityAgentJVMDIModule.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PMap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java ! agent/src/share/classes/sun/jvm/hotspot/tools/Tool.java ! agent/src/share/classes/sun/jvm/hotspot/ui/SAPanel.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js - agent/src/share/native/jvmdi/sa.cpp - agent/src/share/native/jvmdi/sa.dsp - agent/src/share/native/jvmdi/sa.dsw - agent/src/share/native/jvmdi/sa.hpp ! make/sa.files Changeset: f16e75e0cf11 Author: coleenp Date: 2013-02-22 08:36 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f16e75e0cf11 8000797: NPG: is_pseudo_string_at() doesn't work Summary: Zero Symbol* for constant pool strings to indicate pseudo_strings (objects that aren't strings). Clean up JVM_CONSTANT_Object and unused flags. Reviewed-by: sspitsyn, jrose ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/ClassConstants.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/utilities/constantTag.cpp ! src/share/vm/utilities/constantTag.hpp Changeset: 94478a033036 Author: sspitsyn Date: 2013-02-22 10:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/94478a033036 Merge - agent/make/bugspot.bat - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/JavaLineNumberInfo.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/Main.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PCFinder.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PackageScanner.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/RegisterPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTraceEntry.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTracePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/ThreadListPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/VariablePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/AddressTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/DoubleTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/EnumTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FieldTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FloatTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/LongTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/ObjectTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/BreakpointEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CIntegerAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CStringAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/Event.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ExceptionEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/JNIHandleAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ServiceabilityAgentJVMDIModule.java - agent/src/share/native/jvmdi/sa.cpp - agent/src/share/native/jvmdi/sa.dsp - agent/src/share/native/jvmdi/sa.dsw - agent/src/share/native/jvmdi/sa.hpp - make/bsd/makefiles/wb.make - make/linux/makefiles/wb.make - make/solaris/makefiles/wb.make - make/windows/makefiles/wb.make - src/share/tools/whitebox/sun/hotspot/WhiteBox.java - src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java ! src/share/vm/runtime/arguments.cpp Changeset: ec2eddfed950 Author: rbackman Date: 2013-02-26 14:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ec2eddfed950 8008340: [sampling] assert(upper->pc_offset() >= pc_offset) failed: sanity Reviewed-by: kvn, sla ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp Changeset: 77f9b6d0126e Author: sspitsyn Date: 2013-02-27 12:20 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/77f9b6d0126e Merge - agent/make/bugspot.bat - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/JavaLineNumberInfo.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/Main.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PCFinder.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PackageScanner.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/RegisterPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTraceEntry.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTracePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/ThreadListPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/VariablePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/AddressTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/DoubleTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/EnumTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FieldTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FloatTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/LongTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/ObjectTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/BreakpointEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CIntegerAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CStringAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/Event.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ExceptionEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/JNIHandleAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ServiceabilityAgentJVMDIModule.java - agent/src/share/native/jvmdi/sa.cpp - agent/src/share/native/jvmdi/sa.dsp - agent/src/share/native/jvmdi/sa.dsw - agent/src/share/native/jvmdi/sa.hpp - make/bsd/makefiles/wb.make - make/linux/makefiles/wb.make - make/solaris/makefiles/wb.make - make/windows/makefiles/wb.make - src/share/tools/whitebox/sun/hotspot/WhiteBox.java - src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java Changeset: 0598674c0056 Author: jwilhelm Date: 2013-02-21 11:16 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0598674c0056 8008314: Unimplemented() Atomic::load breaks the applications Summary: jlong atomics isn't fully implemented om all 32-bit platforms so we try to avoid it. In this case the atomic add wasn't needed. Reviewed-by: dholmes, dlong ! src/share/vm/runtime/atomic.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp Changeset: 96c885895d22 Author: johnc Date: 2013-02-22 11:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/96c885895d22 8007221: G1: concurrent phase durations do not state the time units ("secs") Summary: Add timer units to concurrent marking phases where the units were missing. Reviewed-by: jmasa, ysr ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp Changeset: 9a8ee5301f33 Author: brutisso Date: 2013-02-26 11:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9a8ee5301f33 Merge Changeset: f1fb03a251e9 Author: poonam Date: 2013-02-21 23:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f1fb03a251e9 8008546: Wrong G1ConfidencePercent results in GUARANTEE(VARIANCE() > -1.0) FAILED Reviewed-by: brutisso, johnc Contributed-by: vladimir.kempik at oracle.com ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: fd32b88a87e9 Author: poonam Date: 2013-02-23 17:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fd32b88a87e9 Merge Changeset: 9289a00709b5 Author: poonam Date: 2013-02-26 08:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9289a00709b5 Merge Changeset: b685ca4f4fb9 Author: ehelin Date: 2013-02-20 16:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b685ca4f4fb9 8008536: Add HotSpot support for printing class loader statistics for JMap Reviewed-by: sla, brutisso + agent/src/share/classes/sun/jvm/hotspot/tools/ClassLoaderStats.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JMap.java - agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java Changeset: 3d3379aab292 Author: ehelin Date: 2013-02-26 22:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3d3379aab292 Merge - agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java Changeset: 9a094d29af19 Author: ehelin Date: 2013-02-06 07:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9a094d29af19 8004924: NPG: jmap -heap output should contain ClassMetaspaceSize value Reviewed-by: stefank, mgerdin ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java + test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java Changeset: b5e03c8ead49 Author: brutisso Date: 2013-02-28 09:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b5e03c8ead49 Merge - agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java Changeset: 6931f425c517 Author: roland Date: 2013-02-25 14:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6931f425c517 8007294: ReduceFieldZeroing doesn't check for dependent load and can lead to incorrect execution Summary: InitializeNode::can_capture_store() must check that the captured store doesn't overwrite a memory location that is loaded before the store. Reviewed-by: kvn ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/phaseX.cpp + test/compiler/8007294/Test8007294.java Changeset: 706c919d3b56 Author: roland Date: 2013-02-26 12:18 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/706c919d3b56 8007722: C2: "assert(tp->base() != Type::AnyPtr) failed: not a bare pointer" at machnode.cpp:376 Summary: GetAndSetP's MachNode should capture bottom type. Reviewed-by: kvn ! src/share/vm/adlc/formssel.cpp + test/compiler/8007722/Test8007722.java Changeset: a00ed9736260 Author: drchase Date: 2013-02-26 15:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a00ed9736260 8007776: Test6852078.java timeouts Summary: if more than 100 seconds and more than 100 iterations have both passed, then exit is allowed. Reviewed-by: kvn ! test/compiler/6852078/Test6852078.java Changeset: 133bf557ef77 Author: iignatyev Date: 2013-02-27 05:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/133bf557ef77 8007439: C2: adding successful message of inlining Reviewed-by: kvn, vlivanov ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/parse.hpp Changeset: b02157cd249f Author: vlivanov Date: 2013-02-27 08:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b02157cd249f Merge Changeset: 338da89b2592 Author: vlivanov Date: 2013-02-28 15:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/338da89b2592 Merge Changeset: df5396524152 Author: amurillo Date: 2013-03-01 04:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/df5396524152 Merge - agent/make/bugspot.bat - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/JavaLineNumberInfo.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/Main.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PCFinder.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PackageScanner.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/RegisterPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTraceEntry.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTracePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/ThreadListPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/VariablePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/AddressTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/DoubleTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/EnumTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FieldTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FloatTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/LongTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/ObjectTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/BreakpointEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CIntegerAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CStringAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/Event.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ExceptionEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/JNIHandleAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ServiceabilityAgentJVMDIModule.java - agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java - agent/src/share/native/jvmdi/sa.cpp - agent/src/share/native/jvmdi/sa.dsp - agent/src/share/native/jvmdi/sa.dsw - agent/src/share/native/jvmdi/sa.hpp - make/bsd/makefiles/wb.make - make/linux/makefiles/wb.make - make/solaris/makefiles/wb.make - make/windows/makefiles/wb.make - src/share/tools/whitebox/sun/hotspot/WhiteBox.java - src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java Changeset: 4a198b201f3c Author: amurillo Date: 2013-03-01 04:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4a198b201f3c Added tag hs25-b21 for changeset df5396524152 ! .hgtags Changeset: fbda7e1dee9a Author: katleman Date: 2013-03-07 11:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fbda7e1dee9a Added tag jdk8-b80 for changeset 4a198b201f3c ! .hgtags Changeset: 7f482030ff64 Author: amurillo Date: 2013-03-01 04:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7f482030ff64 8009226: new hotspot build - hs25-b22 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 1f9994892f89 Author: stefank Date: 2013-02-21 17:22 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1f9994892f89 8008549: NPG: SystemDictionary::find(...) unnecessarily keeps class loaders alive Summary: SystemDictionary::find(...) should not create and register ClassLoaderData objects for class loaders. Reviewed-by: coleenp, acorn Contributed-by: Stefan Karlsson , Erik Helin ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/classLoaderData.inline.hpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/systemDictionary.cpp Changeset: 3c9db54c2660 Author: mikael Date: 2013-02-26 08:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3c9db54c2660 8008081: Print outs do not have matching arguments Summary: Corrected formatted prints to have matching arguments, removed dead print_frame_layout function Reviewed-by: sla, dholmes ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/prims/jvmtiEnter.xsl ! src/share/vm/services/memReporter.cpp ! src/share/vm/utilities/numberSeq.cpp Changeset: 05f2fc6b4ea7 Author: dholmes Date: 2013-02-27 04:58 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/05f2fc6b4ea7 Merge Changeset: 96bd4772ec62 Author: kevinw Date: 2013-02-27 14:02 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/96bd4772ec62 8008807: SA: jstack crash when target has mismatched bitness (Linux) Reviewed-by: rbackman, sla, poonam ! agent/src/os/linux/LinuxDebuggerLocal.c Changeset: 698b615a1cde Author: kevinw Date: 2013-02-27 16:40 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/698b615a1cde Merge Changeset: 651919d134f7 Author: kevinw Date: 2013-02-27 22:40 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/651919d134f7 7178741: SA: jstack -m produce UnalignedAddressException in output (Linux) Reviewed-by: poonam, sla ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/x86/LinuxX86CFrame.java Changeset: 5ee250974db9 Author: dcubed Date: 2013-02-27 15:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5ee250974db9 8007476: assert(the_owner != NULL) failed: Did not find owning Java thread for lock word address Summary: Make deadlock detection a little more robust in the case of being unable to find the JavaThread associated with an object lock. Reviewed-by: sla, acorn ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/threadService.cpp Changeset: a140cd925462 Author: dcubed Date: 2013-02-28 05:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a140cd925462 Merge Changeset: 63e54c37ac64 Author: simonis Date: 2013-02-27 09:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/63e54c37ac64 8008959: Fix non-PCH build on Linux, Windows and MacOS X Summary: Fix the build without precompiled headers by either including the missing ".inline.hpp" files into the appropriate files or by turning inline-functions declared in header files into ordinary functions in ".cpp" files. Reviewed-by: coleenp, stefank, dholmes ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.hpp ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/os_windows.inline.hpp ! src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp ! src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp ! src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp ! src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp ! src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp ! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp ! src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp ! src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp ! src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp ! src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp ! src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp ! src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/oops/symbol.hpp Changeset: a506ac816f14 Author: coleenp Date: 2013-02-27 07:35 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a506ac816f14 Merge Changeset: 143973ced9ab Author: coleenp Date: 2013-02-28 18:37 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/143973ced9ab Merge Changeset: 3e83d69c19db Author: dcubed Date: 2013-03-01 15:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3e83d69c19db Merge Changeset: a252e688abcf Author: jmasa Date: 2013-02-01 17:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a252e688abcf 7189971: Implement CMSWaitDuration for non-incremental mode of CMS Reviewed-by: jmasa, johnc, ysr Contributed-by: michal at frajt.eu ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/runtime/globals.hpp Changeset: 0624b9d81255 Author: ehelin Date: 2013-03-04 13:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0624b9d81255 8004172: Update jstat counter names to reflect metaspace changes Reviewed-by: stefank, jmasa ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp Changeset: 27714220e50e Author: johnc Date: 2013-03-04 12:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/27714220e50e 8007036: G1: Too many old regions added to last mixed GC Summary: Stop adding old regions to collection set when the remaining reclaimable bytes reaches, or goes below, G1HeapWastePercent. Changes were also reviewed by Vitaly Davidovich . Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: d778bb46a9a5 Author: erikj Date: 2013-03-04 22:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d778bb46a9a5 8008451: Make mac builds on 10.8 work on 10.7 Reviewed-by: jcoomes, ohair ! make/bsd/makefiles/gcc.make Changeset: c71e15057f1d Author: stefank Date: 2013-03-07 14:29 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c71e15057f1d Merge Changeset: 7369298bec7e Author: collins Date: 2013-02-27 20:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7369298bec7e 7115383: TEST_BUG: some jtreg tests fail because they explicitly specify -server option Summary: Small changes to hotspot tests to remove "-server" and replace with ${TESTVMOPTS} Reviewed-by: kvn ! test/compiler/6431242/Test.java ! test/compiler/6589834/Test_ia32.java ! test/compiler/6636138/Test1.java ! test/compiler/6636138/Test2.java ! test/compiler/6795161/Test.java ! test/compiler/6946040/TestCharShortByteSwap.java ! test/compiler/7068051/Test7068051.sh ! test/compiler/8000805/Test8000805.java Changeset: 5cf033ff06c4 Author: bpittore Date: 2013-03-01 14:06 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5cf033ff06c4 Merge Changeset: af5ac43f06e9 Author: jprovino Date: 2013-03-07 10:46 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/af5ac43f06e9 Merge Changeset: 0b8f9c8d2617 Author: jiangli Date: 2013-03-07 10:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0b8f9c8d2617 Merge Changeset: 40b7c6b800ab Author: morris Date: 2013-03-01 14:26 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/40b7c6b800ab 8008327: [parfait] Unitialized variable in hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m Summary: Fix unitialized variable and return value. Reviewed-by: kvn ! agent/src/os/bsd/MacosxDebuggerLocal.m Changeset: bf06968a8a00 Author: morris Date: 2013-03-04 13:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bf06968a8a00 8008559: [parfait] Path through non-void function '_ZN2os15thread_cpu_timeEP6Thread' returns an undefined value Summary: safety checks for non-Apple thread time functions Reviewed-by: kvn ! src/os/bsd/vm/os_bsd.cpp Changeset: c40fbf634c90 Author: morris Date: 2013-03-05 04:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c40fbf634c90 8008574: [parfait] Null pointer deference in hotspot/src/share/vm/runtime/frame.cpp Summary: fix null pointer Reviewed-by: kvn ! src/share/vm/runtime/frame.cpp Changeset: 571076d3c79d Author: shade Date: 2013-03-05 04:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/571076d3c79d 8009120: Fuzz instruction scheduling in HotSpot compilers Reviewed-by: kvn, vlivanov ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/lcm.cpp Changeset: 4f553e24b3b5 Author: vlivanov Date: 2013-03-05 08:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4f553e24b3b5 Merge Changeset: 872b3feace55 Author: morris Date: 2013-03-05 18:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/872b3feace55 8008750: [partfait] Null pointer deference in hotspot/src/share/vm/oops/instanceKlass.hpp Summary: fix null pointer Reviewed-by: kvn, coleenp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: 8651f608fea4 Author: roland Date: 2013-03-06 10:28 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8651f608fea4 8009460: C2compiler crash in machnode::in_regmask(unsigned int) Summary: 7121140 may not correctly break the Allocate -> MemBarStoreStore link Reviewed-by: kvn ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/macro.cpp Changeset: ff55877839bc Author: kvn Date: 2013-03-06 12:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ff55877839bc 8009472: Print additional information for 8004640 failure Summary: dump nodes and types in 8004640 case. Reviewed-by: roland ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/memnode.cpp Changeset: bdb602473679 Author: morris Date: 2013-03-07 14:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bdb602473679 Merge ! src/os/bsd/vm/os_bsd.cpp Changeset: b5bd25d55994 Author: morris Date: 2013-03-07 18:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b5bd25d55994 Merge Changeset: dd6350b4abc4 Author: amurillo Date: 2013-03-08 08:10 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dd6350b4abc4 Merge Changeset: 65b797426a3b Author: amurillo Date: 2013-03-08 08:10 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/65b797426a3b Added tag hs25-b22 for changeset dd6350b4abc4 ! .hgtags Changeset: f1629878512f Author: katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f1629878512f Added tag jdk8-b81 for changeset 65b797426a3b ! .hgtags Changeset: b95ad0610fef Author: asaha Date: 2012-10-26 09:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b95ad0610fef Merge - agent/make/ClosureFinder.java - agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/asm/AbstractInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/Address.java - agent/src/share/classes/sun/jvm/hotspot/asm/Arithmetic.java - agent/src/share/classes/sun/jvm/hotspot/asm/ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/BaseIndexScaleDispAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/CPUHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Immediate.java - agent/src/share/classes/sun/jvm/hotspot/asm/IndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLDataTypes.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLOperations.java - agent/src/share/classes/sun/jvm/hotspot/asm/ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/StoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FP2RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPopDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FlushDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/Format3ADecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IllegalInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/JmplDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LogicDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/MemoryInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RestoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RettDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCAtomicLoadStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCDisassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFP2RegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFlushInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFormat3AInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIndirectCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCJmplInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLdstubInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCNoopInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCOpcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRestoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRettInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSaveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSethiInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStbarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSwapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCTrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCUnimpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV8Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9CasInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ConditionFlags.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9DoneInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FlushwInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9IlltrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ImpdepInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MembarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PopcInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrefetchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RdprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RestoredInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RetryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SavedInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SirInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WrprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCWriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SaveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SethiDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/StoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/TrapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/UnimpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpacePrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CCBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CasDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9DoneRetryDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FlushwDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntRegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PopcDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrivilegedReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RdprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SavedRestoredDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WrprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ConditionalJmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatGRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/GRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/JmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/LogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/MoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/RotateDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSELogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CondJmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86GeneralInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86IllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86JmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterDirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterPart.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RotateInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisterAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegisters.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/gc_implementation/parallelScavenge/PSPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGenGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGenGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/ContigPermSpace.java - agent/src/share/classes/sun/jvm/hotspot/memory/PermGen.java - agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/CompiledICHolderKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCacheKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/KlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/MethodDataKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/MethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ObjArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/TypeArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64CurrentFrameGuess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64JavaCallWrapper.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64RegisterMap.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/cInterpreter.java - agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ia64/LinuxIA64JavaThreadPDAccess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/win32_ia64/Win32IA64JavaThreadPDAccess.java - agent/src/share/classes/sun/jvm/hotspot/ui/tree/BadOopTreeNodeAdapter.java - make/solaris/makefiles/reorder_COMPILER1_amd64 - make/solaris/makefiles/reorder_COMPILER1_i486 - make/solaris/makefiles/reorder_COMPILER1_sparc - make/solaris/makefiles/reorder_COMPILER1_sparcv9 - make/solaris/makefiles/reorder_COMPILER2_amd64 - make/solaris/makefiles/reorder_COMPILER2_i486 - make/solaris/makefiles/reorder_COMPILER2_sparc - make/solaris/makefiles/reorder_COMPILER2_sparcv9 - make/solaris/makefiles/reorder_CORE_i486 - make/solaris/makefiles/reorder_CORE_sparc - make/solaris/makefiles/reorder_CORE_sparcv9 - make/solaris/makefiles/reorder_TIERED_amd64 - make/solaris/makefiles/reorder_TIERED_i486 - make/solaris/makefiles/reorder_TIERED_sparc - make/solaris/makefiles/reorder_TIERED_sparcv9 - make/solaris/reorder.sh - src/cpu/sparc/vm/dump_sparc.cpp - src/cpu/x86/vm/dump_x86_32.cpp - src/cpu/x86/vm/dump_x86_64.cpp - src/cpu/zero/vm/dump_zero.cpp - src/share/tools/ProjectCreator/DirectoryTree.java - src/share/tools/ProjectCreator/DirectoryTreeNode.java - src/share/tools/ProjectCreator/FileFormatException.java - src/share/tools/ProjectCreator/WinGammaPlatformVC6.java - src/share/vm/ci/ciArrayKlassKlass.hpp - src/share/vm/ci/ciCPCache.cpp - src/share/vm/ci/ciCPCache.hpp - src/share/vm/ci/ciInstanceKlassKlass.cpp - src/share/vm/ci/ciInstanceKlassKlass.hpp - src/share/vm/ci/ciKlassKlass.cpp - src/share/vm/ci/ciKlassKlass.hpp - src/share/vm/ci/ciMethodKlass.cpp - src/share/vm/ci/ciMethodKlass.hpp - src/share/vm/ci/ciObjArrayKlassKlass.cpp - src/share/vm/ci/ciObjArrayKlassKlass.hpp - src/share/vm/ci/ciTypeArrayKlassKlass.cpp - src/share/vm/ci/ciTypeArrayKlassKlass.hpp ! src/share/vm/compiler/compilerOracle.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.hpp - src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp - src/share/vm/gc_implementation/parallelScavenge/psPermGen.hpp - src/share/vm/memory/classify.cpp - src/share/vm/memory/classify.hpp - src/share/vm/memory/compactPermGen.hpp - src/share/vm/memory/compactingPermGenGen.cpp - src/share/vm/memory/compactingPermGenGen.hpp - src/share/vm/memory/dump.cpp - src/share/vm/memory/permGen.cpp - src/share/vm/memory/permGen.hpp - src/share/vm/memory/restore.cpp - src/share/vm/memory/serialize.cpp - src/share/vm/oops/arrayKlassKlass.cpp - src/share/vm/oops/arrayKlassKlass.hpp - src/share/vm/oops/compiledICHolderKlass.cpp - src/share/vm/oops/compiledICHolderKlass.hpp - src/share/vm/oops/compiledICHolderOop.cpp - src/share/vm/oops/compiledICHolderOop.hpp - src/share/vm/oops/constMethodKlass.cpp - src/share/vm/oops/constMethodKlass.hpp - src/share/vm/oops/constMethodOop.cpp - src/share/vm/oops/constMethodOop.hpp - src/share/vm/oops/constantPoolKlass.cpp - src/share/vm/oops/constantPoolKlass.hpp - src/share/vm/oops/constantPoolOop.cpp - src/share/vm/oops/constantPoolOop.hpp - src/share/vm/oops/cpCacheKlass.cpp - src/share/vm/oops/cpCacheKlass.hpp - src/share/vm/oops/cpCacheOop.cpp - src/share/vm/oops/cpCacheOop.hpp - src/share/vm/oops/instanceKlassKlass.cpp - src/share/vm/oops/instanceKlassKlass.hpp - src/share/vm/oops/klassKlass.cpp - src/share/vm/oops/klassKlass.hpp - src/share/vm/oops/klassOop.cpp - src/share/vm/oops/klassOop.hpp - src/share/vm/oops/methodDataKlass.cpp - src/share/vm/oops/methodDataKlass.hpp - src/share/vm/oops/methodDataOop.cpp - src/share/vm/oops/methodDataOop.hpp - src/share/vm/oops/methodKlass.cpp - src/share/vm/oops/methodKlass.hpp - src/share/vm/oops/methodOop.cpp - src/share/vm/oops/methodOop.hpp - src/share/vm/oops/objArrayKlassKlass.cpp - src/share/vm/oops/objArrayKlassKlass.hpp - src/share/vm/oops/typeArrayKlassKlass.cpp - src/share/vm/oops/typeArrayKlassKlass.hpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 77443715ec55 Author: kamg Date: 2012-11-05 17:03 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/77443715ec55 8001307: Modify ACC_SUPER behavior Summary: Disallow non-virtual calls even when ACC_SUPER is absent. Reviewed-by: kvn, acorn ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/runtime/globals.hpp Changeset: b5cb079ecaa4 Author: ewendeli Date: 2013-02-03 22:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b5cb079ecaa4 Merge ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 1cabf9c80e84 Author: ewendeli Date: 2013-02-19 21:45 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1cabf9c80e84 Merge ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/runtime/arguments.cpp Changeset: d4a32a6f8c82 Author: ewendeli Date: 2013-02-25 07:22 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d4a32a6f8c82 Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 11d5942ef9c7 Author: lana Date: 2013-03-12 18:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/11d5942ef9c7 Merge ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 5ee744831dcb Author: lana Date: 2013-03-14 19:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5ee744831dcb Merge From lana.steuck at oracle.com Sun Mar 17 06:02:56 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 17 Mar 2013 06:02:56 +0000 Subject: hg: jdk8/tl/jdk: 99 new changesets Message-ID: <20130317062159.EADE2481ED@hg.openjdk.java.net> Changeset: d60a95b95f01 Author: katleman Date: 2013-03-07 11:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d60a95b95f01 Added tag jdk8-b80 for changeset dfb40f066c6c ! .hgtags Changeset: 758db1c4c65c Author: ehelin Date: 2013-03-04 15:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/758db1c4c65c 8009384: Temporarily disable jstat tests to ease complicated push Reviewed-by: mchung ! test/ProblemList.txt Changeset: aee1c6c52b68 Author: erikj Date: 2013-03-06 16:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/aee1c6c52b68 8008073: build-infra: Need --with-dxsdk option? And awt/sound -I option additions? Reviewed-by: tbell ! makefiles/CompileNativeLibraries.gmk Changeset: da8edcfc19af Author: katleman Date: 2013-03-11 13:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da8edcfc19af Merge Changeset: bc0ca8bc4637 Author: erikj Date: 2013-03-12 15:17 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bc0ca8bc4637 8009695: embedded/GP/RI: This intermittent error happens too often, makes the build unstable, and waste machine Reviewed-by: dholmes, tbell ! make/common/shared/Defs-utils.gmk ! makefiles/Images.gmk Changeset: c0f8022eba53 Author: katleman Date: 2013-03-12 19:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c0f8022eba53 Merge Changeset: 509c45748f3e Author: katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/509c45748f3e Added tag jdk8-b81 for changeset c0f8022eba53 ! .hgtags Changeset: f6eb212081b2 Author: jgodinez Date: 2013-02-14 14:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f6eb212081b2 8008173: [parfait] #1173 Uninitialised variable -- TransformHelper.cpp Reviewed-by: prr, vadim Contributed-by: jia-hong.chen at oracle.com ! src/share/native/sun/java2d/loops/TransformHelper.c Changeset: 4b11045a9c4c Author: jgodinez Date: 2013-02-18 14:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4b11045a9c4c 8005191: [parfait] #384 sun/font/layout/LookupProcessor.cpp Null pointer dereference Reviewed-by: prr, vadim Contributed-by: jia-hong.chen at oracle.com ! src/share/native/sun/font/layout/LookupProcessor.cpp Changeset: 41008f5cef1a Author: lana Date: 2013-02-19 22:10 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/41008f5cef1a Merge - src/macosx/classes/sun/lwawt/macosx/EventDispatchAccess.java - src/share/classes/java/time/PeriodParser.java - src/share/classes/java/time/calendar/ChronoDateImpl.java - src/share/classes/java/time/calendar/HijrahChrono.java - src/share/classes/java/time/calendar/HijrahDate.java - src/share/classes/java/time/calendar/HijrahDeviationReader.java - src/share/classes/java/time/calendar/HijrahEra.java - src/share/classes/java/time/calendar/JapaneseChrono.java - src/share/classes/java/time/calendar/JapaneseDate.java - src/share/classes/java/time/calendar/JapaneseEra.java - src/share/classes/java/time/calendar/MinguoChrono.java - src/share/classes/java/time/calendar/MinguoDate.java - src/share/classes/java/time/calendar/MinguoEra.java - src/share/classes/java/time/calendar/Ser.java - src/share/classes/java/time/calendar/ThaiBuddhistChrono.java - src/share/classes/java/time/calendar/ThaiBuddhistDate.java - src/share/classes/java/time/calendar/ThaiBuddhistEra.java - src/share/classes/java/time/calendar/package-info.java - src/share/classes/java/time/format/DateTimeFormatters.java - src/share/classes/java/time/format/DateTimePrintException.java - src/share/classes/java/time/temporal/Chrono.java - src/share/classes/java/time/temporal/ChronoLocalDate.java - src/share/classes/java/time/temporal/ChronoLocalDateTime.java - src/share/classes/java/time/temporal/ChronoLocalDateTimeImpl.java - src/share/classes/java/time/temporal/ChronoZonedDateTime.java - src/share/classes/java/time/temporal/ChronoZonedDateTimeImpl.java - src/share/classes/java/time/temporal/Era.java - src/share/classes/java/time/temporal/ISOChrono.java - src/share/classes/java/time/temporal/ISOEra.java - src/share/classes/java/time/temporal/ISOFields.java - src/share/classes/java/time/temporal/MonthDay.java - src/share/classes/java/time/temporal/OffsetDate.java - src/share/classes/java/time/temporal/OffsetDateTime.java - src/share/classes/java/time/temporal/OffsetTime.java - src/share/classes/java/time/temporal/Ser.java - src/share/classes/java/time/temporal/SimplePeriod.java - src/share/classes/java/time/temporal/TemporalAdder.java - src/share/classes/java/time/temporal/TemporalSubtractor.java - src/share/classes/java/time/temporal/Year.java - src/share/classes/java/time/temporal/YearMonth.java - src/share/classes/sun/util/calendar/TzIDOldMapping.java - test/java/time/META-INF/services/java.time.temporal.Chrono - test/java/time/tck/java/time/calendar/CopticChrono.java - test/java/time/tck/java/time/calendar/CopticDate.java - test/java/time/tck/java/time/calendar/CopticEra.java - test/java/time/tck/java/time/calendar/TestChronoLocalDate.java - test/java/time/tck/java/time/calendar/TestChronoLocalDateTime.java - test/java/time/tck/java/time/calendar/TestHijrahChrono.java - test/java/time/tck/java/time/calendar/TestJapaneseChrono.java - test/java/time/tck/java/time/calendar/TestMinguoChrono.java - test/java/time/tck/java/time/calendar/TestServiceLoader.java - test/java/time/tck/java/time/calendar/TestThaiBuddhistChrono.java - test/java/time/tck/java/time/format/TCKDateTimePrintException.java - test/java/time/tck/java/time/temporal/TCKISOFields.java - test/java/time/tck/java/time/temporal/TCKMonthDay.java - test/java/time/tck/java/time/temporal/TCKOffsetDate.java - test/java/time/tck/java/time/temporal/TCKOffsetDateTime.java - test/java/time/tck/java/time/temporal/TCKOffsetTime.java - test/java/time/tck/java/time/temporal/TCKSimplePeriod.java - test/java/time/tck/java/time/temporal/TCKYear.java - test/java/time/tck/java/time/temporal/TCKYearMonth.java - test/java/time/tck/java/time/temporal/TestChrono.java - test/java/time/tck/java/time/temporal/TestISOChrono.java - test/java/time/test/java/time/TestPeriodParser.java - test/java/time/test/java/time/format/TestDateTimeFormatters.java - test/java/time/test/java/time/format/TestDateTimePrintException.java - test/java/time/test/java/time/format/TestPadParserDecorator.java - test/java/time/test/java/time/format/TestZoneIdParser.java - test/java/time/test/java/time/temporal/TestISOChronoImpl.java - test/java/time/test/java/time/temporal/TestMonthDay.java - test/java/time/test/java/time/temporal/TestOffsetDate.java - test/java/time/test/java/time/temporal/TestOffsetDateTime.java - test/java/time/test/java/time/temporal/TestOffsetDateTime_instants.java - test/java/time/test/java/time/temporal/TestOffsetTime.java - test/java/time/test/java/time/temporal/TestYear.java - test/java/time/test/java/time/temporal/TestYearMonth.java Changeset: d2d7da120c37 Author: jgodinez Date: 2013-02-22 11:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d2d7da120c37 8006110: pageDialog is showing the swing dialog with DialogTypeSelection.NATIVE Reviewed-by: bae, prr ! src/share/classes/sun/print/RasterPrinterJob.java Changeset: 99c1f910abcc Author: jgodinez Date: 2013-02-22 13:20 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/99c1f910abcc 8005796: [parfait] Possible uninitialised variable at jdk/src/share/native/sun/java2d/loops/ByteBinary1Bit.c Reviewed-by: prr, vadim, flar Contributed-by: jia-hong.chen at oracle.com ! src/share/native/sun/java2d/loops/AnyByteBinary.h ! src/share/native/sun/java2d/loops/ByteIndexed.h ! src/share/native/sun/java2d/loops/IntArgb.h ! src/share/native/sun/java2d/loops/IntArgbBm.h ! src/share/native/sun/java2d/loops/IntArgbPre.h ! src/share/native/sun/java2d/loops/Ushort4444Argb.h ! src/share/native/sun/java2d/loops/UshortIndexed.h Changeset: 934f5f10107d Author: lana Date: 2013-02-22 11:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/934f5f10107d Merge Changeset: 4fd6048a78c0 Author: lana Date: 2013-02-22 23:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4fd6048a78c0 Merge Changeset: f3368a3fc023 Author: bae Date: 2013-03-05 17:18 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f3368a3fc023 7152608: [macosx] Crash in liblwawt.dylib in AccelGlyphCache_RemoveCellInfo Reviewed-by: jgodinez, ant ! src/macosx/classes/sun/font/CStrike.java ! src/macosx/classes/sun/font/CStrikeDisposer.java ! src/macosx/native/sun/font/AWTStrike.m Changeset: fd8810d50c99 Author: bae Date: 2013-03-07 14:05 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fd8810d50c99 8005530: [lcms] Improve performance of ColorConverOp for default destinations Reviewed-by: prr, jgodinez ! make/sun/cmm/lcms/Makefile ! make/sun/cmm/lcms/mapfile-vers ! makefiles/CompileNativeLibraries.gmk ! makefiles/mapfiles/liblcms/mapfile-vers ! src/share/classes/sun/java2d/cmm/lcms/LCMS.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java ! src/share/demo/java2d/J2DBench/build.xml + src/share/demo/java2d/J2DBench/resources/cmm_images/img_icc_large.jpg + src/share/demo/java2d/J2DBench/resources/cmm_images/img_icc_medium.jpg + src/share/demo/java2d/J2DBench/resources/cmm_images/img_icc_small.jpg ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ColorConversionTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/EmbeddedProfileTests.java ! src/share/native/sun/java2d/cmm/lcms/LCMS.c Changeset: 8e9b133dcec9 Author: lana Date: 2013-03-12 16:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8e9b133dcec9 Merge Changeset: e6c94a202bfd Author: alexsch Date: 2013-02-15 14:24 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e6c94a202bfd 7173873: JFrame.setDefaultCloseOperation(EXIT_ON_CLOSE) will never lead to SE if EXIT_ON_CLOSE is already set Reviewed-by: malenkov, serb ! src/share/classes/javax/swing/JFrame.java Changeset: 4bf242def958 Author: dingxmin Date: 2013-02-15 15:05 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4bf242def958 8008289: DefaultButtonModel instance keeps stale listeners in html FormView Reviewed-by: malenkov, alexsch ! src/share/classes/javax/swing/text/html/FormView.java + test/javax/swing/text/html/7189299/bug7189299.java Changeset: 88a83b9e9baa Author: kshefov Date: 2013-02-15 17:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/88a83b9e9baa 8005920: After pressing combination Windows Key and M key, the frame, the instruction and the dialog can't be minimized. Reviewed-by: serb, denis Contributed-by: Vera Akulova ! test/java/awt/Modal/WsDisabledStyle/Winkey/Winkey.java Changeset: 0fe12ecf80b2 Author: pchelko Date: 2013-02-19 11:26 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0fe12ecf80b2 8008374: Build failure (NEWBUILD=false) on Mac Summary: Fixed an old build system failure Reviewed-by: art, anthony ! make/sun/lwawt/FILES_export_macosx.gmk Changeset: 5ad0bd367f6d Author: kshefov Date: 2013-02-19 17:26 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5ad0bd367f6d 8008379: TEST_BUG: Fail automatically with java.lang.NullPointerException. Reviewed-by: serb, anthony + test/java/awt/Modal/ModalDialogMultiscreenTest/ModalDialogMultiscreenTest.java Changeset: a43115c6359d Author: kshefov Date: 2013-02-19 20:00 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a43115c6359d 8006070: TEST_BUG: Up and down the Y coordinate of the mouse position, the selected item doesn't change for the single list. Reviewed-by: serb, anthony + test/java/awt/List/MouseDraggedOutCauseScrollingTest/MouseDraggedOutCauseScrollingTest.html + test/java/awt/List/MouseDraggedOutCauseScrollingTest/MouseDraggedOutCauseScrollingTest.java Changeset: 9bc26b7b8b47 Author: lana Date: 2013-02-19 22:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9bc26b7b8b47 Merge - src/share/classes/java/time/PeriodParser.java - src/share/classes/java/time/calendar/ChronoDateImpl.java - src/share/classes/java/time/calendar/HijrahChrono.java - src/share/classes/java/time/calendar/HijrahDate.java - src/share/classes/java/time/calendar/HijrahDeviationReader.java - src/share/classes/java/time/calendar/HijrahEra.java - src/share/classes/java/time/calendar/JapaneseChrono.java - src/share/classes/java/time/calendar/JapaneseDate.java - src/share/classes/java/time/calendar/JapaneseEra.java - src/share/classes/java/time/calendar/MinguoChrono.java - src/share/classes/java/time/calendar/MinguoDate.java - src/share/classes/java/time/calendar/MinguoEra.java - src/share/classes/java/time/calendar/Ser.java - src/share/classes/java/time/calendar/ThaiBuddhistChrono.java - src/share/classes/java/time/calendar/ThaiBuddhistDate.java - src/share/classes/java/time/calendar/ThaiBuddhistEra.java - src/share/classes/java/time/calendar/package-info.java - src/share/classes/java/time/format/DateTimeFormatters.java - src/share/classes/java/time/format/DateTimePrintException.java - src/share/classes/java/time/temporal/Chrono.java - src/share/classes/java/time/temporal/ChronoLocalDate.java - src/share/classes/java/time/temporal/ChronoLocalDateTime.java - src/share/classes/java/time/temporal/ChronoLocalDateTimeImpl.java - src/share/classes/java/time/temporal/ChronoZonedDateTime.java - src/share/classes/java/time/temporal/ChronoZonedDateTimeImpl.java - src/share/classes/java/time/temporal/Era.java - src/share/classes/java/time/temporal/ISOChrono.java - src/share/classes/java/time/temporal/ISOEra.java - src/share/classes/java/time/temporal/ISOFields.java - src/share/classes/java/time/temporal/MonthDay.java - src/share/classes/java/time/temporal/OffsetDate.java - src/share/classes/java/time/temporal/OffsetDateTime.java - src/share/classes/java/time/temporal/OffsetTime.java - src/share/classes/java/time/temporal/Ser.java - src/share/classes/java/time/temporal/SimplePeriod.java - src/share/classes/java/time/temporal/TemporalAdder.java - src/share/classes/java/time/temporal/TemporalSubtractor.java - src/share/classes/java/time/temporal/Year.java - src/share/classes/java/time/temporal/YearMonth.java - src/share/classes/sun/util/calendar/TzIDOldMapping.java - test/java/time/META-INF/services/java.time.temporal.Chrono - test/java/time/tck/java/time/calendar/CopticChrono.java - test/java/time/tck/java/time/calendar/CopticDate.java - test/java/time/tck/java/time/calendar/CopticEra.java - test/java/time/tck/java/time/calendar/TestChronoLocalDate.java - test/java/time/tck/java/time/calendar/TestChronoLocalDateTime.java - test/java/time/tck/java/time/calendar/TestHijrahChrono.java - test/java/time/tck/java/time/calendar/TestJapaneseChrono.java - test/java/time/tck/java/time/calendar/TestMinguoChrono.java - test/java/time/tck/java/time/calendar/TestServiceLoader.java - test/java/time/tck/java/time/calendar/TestThaiBuddhistChrono.java - test/java/time/tck/java/time/format/TCKDateTimePrintException.java - test/java/time/tck/java/time/temporal/TCKISOFields.java - test/java/time/tck/java/time/temporal/TCKMonthDay.java - test/java/time/tck/java/time/temporal/TCKOffsetDate.java - test/java/time/tck/java/time/temporal/TCKOffsetDateTime.java - test/java/time/tck/java/time/temporal/TCKOffsetTime.java - test/java/time/tck/java/time/temporal/TCKSimplePeriod.java - test/java/time/tck/java/time/temporal/TCKYear.java - test/java/time/tck/java/time/temporal/TCKYearMonth.java - test/java/time/tck/java/time/temporal/TestChrono.java - test/java/time/tck/java/time/temporal/TestISOChrono.java - test/java/time/test/java/time/TestPeriodParser.java - test/java/time/test/java/time/format/TestDateTimeFormatters.java - test/java/time/test/java/time/format/TestDateTimePrintException.java - test/java/time/test/java/time/format/TestPadParserDecorator.java - test/java/time/test/java/time/format/TestZoneIdParser.java - test/java/time/test/java/time/temporal/TestISOChronoImpl.java - test/java/time/test/java/time/temporal/TestMonthDay.java - test/java/time/test/java/time/temporal/TestOffsetDate.java - test/java/time/test/java/time/temporal/TestOffsetDateTime.java - test/java/time/test/java/time/temporal/TestOffsetDateTime_instants.java - test/java/time/test/java/time/temporal/TestOffsetTime.java - test/java/time/test/java/time/temporal/TestYear.java - test/java/time/test/java/time/temporal/TestYearMonth.java Changeset: 73d1efc4710a Author: ant Date: 2013-02-22 15:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/73d1efc4710a 8006406: lightweight embedding in other Java UI toolkits Reviewed-by: serb, anthony, art ! src/macosx/classes/sun/lwawt/LWComponentPeer.java + src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformComponent.java + src/macosx/classes/sun/lwawt/macosx/CPlatformLWComponent.java + src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java + src/macosx/classes/sun/lwawt/macosx/CPlatformLWWindow.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/share/classes/java/awt/peer/FramePeer.java ! src/share/classes/java/awt/peer/WindowPeer.java ! src/share/classes/sun/awt/EmbeddedFrame.java ! src/share/classes/sun/awt/HToolkit.java + src/share/classes/sun/awt/LightweightFrame.java ! src/share/classes/sun/awt/SunToolkit.java + src/share/classes/sun/swing/JLightweightFrame.java + src/share/classes/sun/swing/LightweightContent.java ! src/solaris/classes/sun/awt/X11/XFramePeer.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java ! src/windows/classes/sun/awt/windows/WEmbeddedFramePeer.java ! src/windows/classes/sun/awt/windows/WFramePeer.java + src/windows/classes/sun/awt/windows/WLightweightFramePeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/native/sun/windows/awt_Frame.cpp ! src/windows/native/sun/windows/awt_Frame.h ! src/windows/native/sun/windows/awt_Window.h Changeset: 63bb402d4a6a Author: lana Date: 2013-02-23 19:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/63bb402d4a6a Merge Changeset: d502cc7bcc3d Author: pchelko Date: 2013-02-25 10:17 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d502cc7bcc3d 8006634: Unify LWCToolkit.invokeAndWait() and sun.awt.datatransfer.ToolkitThreadBlockedHandler Summary: Changed the logic for the nested event loops and deleted deadlock detection Reviewed-by: art, denis ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CToolkitThreadBlockedHandler.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/ApplicationDelegate.m ! src/macosx/native/sun/awt/CClipboard.m ! src/macosx/native/sun/awt/CDropTarget.m ! src/macosx/native/sun/awt/CMenu.m ! src/macosx/native/sun/awt/CMenuBar.m ! src/macosx/native/sun/awt/CMenuItem.m ! src/macosx/native/sun/awt/JavaComponentAccessibility.m ! src/macosx/native/sun/awt/LWCToolkit.m ! src/macosx/native/sun/osxapp/ThreadUtilities.h ! src/macosx/native/sun/osxapp/ThreadUtilities.m Changeset: e58f0b163f43 Author: denis Date: 2013-02-27 19:38 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e58f0b163f43 7178079: REGRESSION: Some AWT Drag-n-Drop tests fail since JDK 7u6 b13 Reviewed-by: serb, anthony ! src/macosx/classes/sun/lwawt/macosx/CDropTargetContextPeer.java Changeset: bc914b7f0878 Author: denis Date: 2013-02-27 20:34 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bc914b7f0878 8009158: Incomplete fix for 7178079 Reviewed-by: serb, anthony ! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java Changeset: 3dee850e2653 Author: serb Date: 2013-02-28 17:04 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3dee850e2653 8008660: Failure in 2D Queue Flusher thread on Mac Reviewed-by: swingler, bae ! src/macosx/classes/sun/awt/CGraphicsConfig.java ! src/macosx/classes/sun/awt/CGraphicsDevice.java ! src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java ! src/macosx/classes/sun/lwawt/macosx/CRobot.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/CRobot.m ! src/macosx/native/sun/awt/LWCToolkit.h ! src/macosx/native/sun/awt/LWCToolkit.m ! src/macosx/native/sun/java2d/opengl/CGLGraphicsConfig.m Changeset: 554d0f41a6ab Author: serb Date: 2013-02-28 20:27 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/554d0f41a6ab 8003169: [macosx] JVM crash after disconnecting from projector Reviewed-by: anthony, alexsch ! src/macosx/classes/sun/awt/CGraphicsDevice.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/CGraphicsDevice.m Changeset: 657a02fcaa00 Author: malenkov Date: 2013-03-01 14:30 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/657a02fcaa00 7163696: JCK Swing interactive test JScrollBarTest0013 fails with Nimbus and GTK L&Fs Reviewed-by: alexsch ! src/share/classes/java/beans/PropertyDescriptor.java ! test/java/beans/Introspector/Test7192955.java Changeset: 5816595a4cdc Author: serb Date: 2013-03-01 15:31 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5816595a4cdc 7194902: [macosx] closed/java/awt/Button/DoubleActionEventTest/DoubleActionEventTest failed since jdk8b49 7181403: Invalid MouseEvent conversion with SwingUtilities.convertMouseEvent Reviewed-by: malenkov, alexsch ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/share/classes/javax/swing/SwingUtilities.java Changeset: 4912a9e3a95e Author: serb Date: 2013-03-01 21:50 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4912a9e3a95e 7184945: [macosx] NPE in AquaComboBoxUI since jdk7u6b17, jdk8b47 Reviewed-by: malenkov, alexsch ! src/macosx/classes/com/apple/laf/AquaComboBoxUI.java Changeset: 91e17a813483 Author: alexsch Date: 2013-03-06 19:42 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/91e17a813483 6877495: JTextField and JTextArea does not support supplementary characters Reviewed-by: serb, alexp ! src/share/classes/sun/awt/datatransfer/DataTransferer.java + test/sun/awt/datatransfer/SuplementaryCharactersTransferTest.java Changeset: 7962014b1729 Author: mcherkas Date: 2013-03-06 20:10 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7962014b1729 8007295: Reduce number of warnings in awt classes Reviewed-by: bae, anthony ! src/share/classes/java/awt/CheckboxMenuItem.java ! src/share/classes/java/awt/Cursor.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/Menu.java ! src/share/classes/java/awt/MenuBar.java ! src/share/classes/java/awt/MenuComponent.java ! src/share/classes/java/awt/MenuItem.java ! src/share/classes/java/awt/RenderingHints.java ! src/share/classes/java/awt/datatransfer/Clipboard.java ! src/share/classes/java/awt/dnd/DragGestureEvent.java ! src/share/classes/java/awt/dnd/DragGestureRecognizer.java ! src/share/classes/java/awt/dnd/DragSource.java ! src/share/classes/java/awt/dnd/InvalidDnDOperationException.java ! src/share/classes/java/awt/geom/AffineTransform.java Changeset: f3ffead3069e Author: lana Date: 2013-03-12 16:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f3ffead3069e Merge Changeset: 5880bfd30db1 Author: lana Date: 2013-03-12 16:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5880bfd30db1 Merge - make/tools/javazic/Makefile - make/tools/src/build/tools/javazic/BackEnd.java - make/tools/src/build/tools/javazic/Checksum.java - make/tools/src/build/tools/javazic/DayOfWeek.java - make/tools/src/build/tools/javazic/Gen.java - make/tools/src/build/tools/javazic/GenDoc.java - make/tools/src/build/tools/javazic/Main.java - make/tools/src/build/tools/javazic/Mappings.java - make/tools/src/build/tools/javazic/Month.java - make/tools/src/build/tools/javazic/Rule.java - make/tools/src/build/tools/javazic/RuleDay.java - make/tools/src/build/tools/javazic/RuleRec.java - make/tools/src/build/tools/javazic/Simple.java - make/tools/src/build/tools/javazic/Time.java - make/tools/src/build/tools/javazic/Timezone.java - make/tools/src/build/tools/javazic/Zone.java - make/tools/src/build/tools/javazic/ZoneRec.java - make/tools/src/build/tools/javazic/Zoneinfo.java - src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java - src/share/classes/java/util/function/Block.java - src/share/classes/java/util/function/DoubleBlock.java - src/share/classes/java/util/function/IntBlock.java - src/share/classes/java/util/function/LongBlock.java - test/javax/script/RhinoExceptionTest.java Changeset: 72ffb2bc15bb Author: lana Date: 2013-03-12 18:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/72ffb2bc15bb Merge - make/tools/javazic/Makefile - make/tools/src/build/tools/javazic/BackEnd.java - make/tools/src/build/tools/javazic/Checksum.java - make/tools/src/build/tools/javazic/DayOfWeek.java - make/tools/src/build/tools/javazic/Gen.java - make/tools/src/build/tools/javazic/GenDoc.java - make/tools/src/build/tools/javazic/Main.java - make/tools/src/build/tools/javazic/Mappings.java - make/tools/src/build/tools/javazic/Month.java - make/tools/src/build/tools/javazic/Rule.java - make/tools/src/build/tools/javazic/RuleDay.java - make/tools/src/build/tools/javazic/RuleRec.java - make/tools/src/build/tools/javazic/Simple.java - make/tools/src/build/tools/javazic/Time.java - make/tools/src/build/tools/javazic/Timezone.java - make/tools/src/build/tools/javazic/Zone.java - make/tools/src/build/tools/javazic/ZoneRec.java - make/tools/src/build/tools/javazic/Zoneinfo.java - src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java - src/share/classes/java/util/function/Block.java - src/share/classes/java/util/function/DoubleBlock.java - src/share/classes/java/util/function/IntBlock.java - src/share/classes/java/util/function/LongBlock.java ! test/ProblemList.txt - test/javax/script/RhinoExceptionTest.java Changeset: 66a892bb28b7 Author: anthony Date: 2012-10-12 15:51 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/66a892bb28b7 7173145: Improve in-memory representation of splashscreens Reviewed-by: bae, mschoene ! src/share/native/sun/awt/splashscreen/splashscreen_jpeg.c Changeset: 85bf51db473c Author: xuelei Date: 2012-10-15 07:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/85bf51db473c 7192393: Better Checking of order of TLS Messages Summary: Also reviewed by Andrew Gross Reviewed-by: weijun ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java Changeset: 24a3eb2f0553 Author: malenkov Date: 2012-10-15 19:00 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/24a3eb2f0553 7200493: Improve cache handling Reviewed-by: art, ahgross ! src/share/classes/com/sun/beans/finder/MethodFinder.java Changeset: c7c39320bc6c Author: rupashka Date: 2012-10-16 14:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c7c39320bc6c 7186948: Improve Swing data validation Reviewed-by: art, ahgross ! src/share/classes/javax/swing/UIDefaults.java Changeset: 3c8d0085b094 Author: ksrini Date: 2012-10-16 12:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c8d0085b094 7186945: Unpack200 improvement Reviewed-by: jrose, jjh, mschoene ! src/share/native/com/sun/java/util/jar/pack/jni.cpp Changeset: 01f67953c057 Author: ksrini Date: 2012-10-16 12:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01f67953c057 7186957: Improve Pack200 data validation Reviewed-by: jrose, jjh, mschoene ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/native/com/sun/java/util/jar/pack/bands.cpp ! src/share/native/com/sun/java/util/jar/pack/bands.h ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp Changeset: b0bf41ba1cf8 Author: ksrini Date: 2012-10-16 12:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b0bf41ba1cf8 7186946: Refine unpacker resource usage Reviewed-by: jrose, jjh, mschoene ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java ! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java ! src/share/native/com/sun/java/util/jar/pack/jni.cpp ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp Changeset: f0bc5a6dff2b Author: ksrini Date: 2012-10-16 16:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f0bc5a6dff2b 7200499: Better data validation for options Reviewed-by: darcy, jjh, mschoene ! src/share/bin/jli_util.h ! src/windows/bin/java_md.c Changeset: 7e19ab4ff5d3 Author: ksrini Date: 2012-10-16 10:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7e19ab4ff5d3 7200500: Launcher better input validation Reviewed-by: darcy, jjh, mschoene ! src/share/bin/parse_manifest.c Changeset: 62f3270f03fa Author: dholmes Date: 2012-08-22 21:40 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/62f3270f03fa 6776941: Improve thread pool shutdown Reviewed-by: dl, skoivu ! src/share/classes/java/util/concurrent/ThreadPoolExecutor.java Changeset: e7cce63bf293 Author: xuelei Date: 2012-10-22 07:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e7cce63bf293 7192392: Better validation of client keys Summary: Also reviewed by Andrew Gross Reviewed-by: vinnie ! src/share/classes/com/sun/crypto/provider/DHKeyAgreement.java ! src/share/classes/sun/security/pkcs11/P11KeyAgreement.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/DHClientKeyExchange.java ! src/share/classes/sun/security/ssl/DHCrypt.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java ! src/share/classes/sun/security/util/DisabledAlgorithmConstraints.java - src/share/classes/sun/security/util/KeyLength.java + src/share/classes/sun/security/util/KeyUtil.java ! test/sun/security/mscapi/ShortRSAKeyWithinTLS.java Changeset: 091dd6eb30aa Author: khazra Date: 2012-10-22 11:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/091dd6eb30aa 7186954: Improve connection performance Reviewed-by: chegar, skoivu ! src/share/classes/sun/net/httpserver/ChunkedInputStream.java ! src/share/classes/sun/net/www/http/ChunkedInputStream.java Changeset: c26d42a92bd8 Author: weijun Date: 2012-09-19 12:58 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c26d42a92bd8 8000210: Improve JarFile code quality Reviewed-by: ahgross, xuelei, mschoene ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/sun/security/util/DerIndefLenConverter.java Changeset: a54b61ae6f12 Author: mullan Date: 2012-10-26 15:21 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a54b61ae6f12 7201068: Better handling of UI elements Reviewed-by: xuelei ! src/share/lib/security/java.security ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 71ab8d79c6b4 Author: asaha Date: 2012-10-26 10:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71ab8d79c6b4 Merge - src/macosx/classes/sun/awt/SunToolkitSubclass.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/java/util/ServiceLoader.java ! src/share/classes/sun/invoke/util/ValueConversions.java - src/share/classes/sun/management/LockDataConverter.java - src/share/classes/sun/management/LockDataConverterMXBean.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java - src/share/classes/sun/util/xml/XMLUtils.java - src/share/test/pack200/pack.conf - test/sun/misc/URLClassPath/ClassnameCharTest.sh - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: be07910b3fad Author: asaha Date: 2012-10-26 13:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/be07910b3fad Merge Changeset: e14221289076 Author: dsamersoff Date: 2012-10-30 17:05 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e14221289076 8000539: JMX implementation allows invocation of methods of a system class Summary: Added extra packageAccess check call Reviewed-by: ahgross, dfuchs Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java Changeset: 64440cc2ea8b Author: mchung Date: 2012-11-02 16:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/64440cc2ea8b 7197546: (proxy) Reflect about creating reflective proxies Reviewed-by: alanb, jdn, jrose ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java ! test/java/rmi/server/RMIClassLoader/loadProxyClasses/security.policy Changeset: f936be5be1e7 Author: rupashka Date: 2012-11-06 15:30 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f936be5be1e7 7200491: Tighten up JTable layout code Reviewed-by: art, skoivu ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java Changeset: 3069b91ff041 Author: chegar Date: 2012-11-07 14:26 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3069b91ff041 7201071: InetSocketAddress serialization issue Reviewed-by: alanb, michaelm, skoivu ! src/share/classes/java/net/InetSocketAddress.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/solaris/native/sun/nio/ch/DatagramChannelImpl.c ! src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c ! src/windows/native/sun/nio/ch/DatagramChannelImpl.c ! test/java/nio/channels/DatagramChannel/SendToUnresolved.java Changeset: 69fd15e0437d Author: smarks Date: 2012-11-08 15:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/69fd15e0437d 7201070: Serialization to conform to protocol Reviewed-by: dmocek, ahgross, skoivu ! src/share/classes/java/io/ObjectInputStream.java Changeset: 9097b6ec0ecd Author: ksrini Date: 2012-11-09 14:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9097b6ec0ecd 8002091: tools/launcher/ToolsOpts.java test started to fail since 7u11 b01 on Windows Reviewed-by: darcy, jjh, mschoene ! src/share/bin/jli_util.h ! src/windows/bin/java_md.c ! test/tools/launcher/ToolsOpts.java Changeset: 7bc8d5a63d9e Author: bagiras Date: 2012-11-15 23:03 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7bc8d5a63d9e 7192977: Issue in toolkit thread Reviewed-by: skoivu, rupashka, art ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/Window.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/sun/applet/AppletPanel.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java Changeset: 09e2dcd476cf Author: bae Date: 2012-11-16 11:05 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/09e2dcd476cf 8001972: Improve image processing Reviewed-by: prr, ahgross ! src/share/classes/sun/awt/image/ByteComponentRaster.java ! src/share/classes/sun/awt/image/ByteInterleavedRaster.java ! src/share/classes/sun/awt/image/ShortComponentRaster.java ! src/share/classes/sun/awt/image/ShortInterleavedRaster.java ! src/share/native/sun/awt/image/awt_parseImage.c ! src/share/native/sun/awt/medialib/safe_alloc.h Changeset: 1b616e1ca09c Author: dmocek Date: 2012-11-19 13:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1b616e1ca09c 6563318: RMI data sanitization Reviewed-by: ahgross, hawtin, mchung, smarks ! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java ! test/java/rmi/testlibrary/JavaVM.java Changeset: aa8717a5c9cd Author: dmocek Date: 2012-11-19 15:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/aa8717a5c9cd 8001242: Improve RMI HTTP conformance Reviewed-by: ahgross, mchung, smarks ! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java ! src/share/classes/sun/rmi/transport/proxy/HttpInputStream.java Changeset: ecedf46ae7db Author: bae Date: 2012-11-20 11:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ecedf46ae7db 8002325: Improve management of images Reviewed-by: prr, ahgross ! src/share/native/sun/awt/image/awt_parseImage.c ! src/share/native/sun/awt/image/awt_parseImage.h Changeset: eda84d5738e3 Author: denis Date: 2012-11-26 20:49 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eda84d5738e3 7186952: Improve clipboard access Reviewed-by: serb, ahgross ! src/share/classes/java/awt/TextComponent.java ! src/windows/native/sun/windows/awt_TextComponent.cpp ! src/windows/native/sun/windows/awt_TextComponent.h Changeset: d1668eca22bf Author: mchung Date: 2012-11-26 22:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d1668eca22bf 6664509: Add logging context 6664528: Find log level matching its name or value given at construction time Reviewed-by: alanb, ahgross, jgish, hawtin ! src/share/classes/java/util/logging/Level.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/logging/Logging.java ! src/share/classes/java/util/logging/LoggingProxyImpl.java ! src/share/classes/java/util/logging/SimpleFormatter.java ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/misc/JavaAWTAccess.java ! src/share/lib/security/java.security Changeset: b8ee2e9ff7e3 Author: denis Date: 2012-11-30 15:51 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b8ee2e9ff7e3 7201064: Better dialogue checking Reviewed-by: serb, skoivu ! src/share/classes/java/awt/Dialog.java Changeset: 90bbdae7aaa4 Author: ewendeli Date: 2013-02-03 23:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90bbdae7aaa4 Merge ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/TextComponent.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/logging/Logging.java ! src/share/classes/java/util/logging/LoggingProxyImpl.java ! src/share/classes/java/util/logging/SimpleFormatter.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java ! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java ! src/share/classes/sun/rmi/transport/proxy/HttpInputStream.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/DHClientKeyExchange.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java - src/share/classes/sun/security/util/KeyLength.java ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! src/share/native/com/sun/java/util/jar/pack/bands.cpp ! src/share/native/com/sun/java/util/jar/pack/bands.h ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/solaris/native/sun/nio/ch/DatagramChannelImpl.c ! src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c ! src/windows/native/sun/nio/ch/DatagramChannelImpl.c ! test/java/rmi/testlibrary/JavaVM.java Changeset: cc2057f84eb7 Author: mchung Date: 2012-12-05 14:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cc2057f84eb7 8004175: Restricted packages added in java.security are missing in java.security-{macosx, solaris, windows} Reviewed-by: alanb, ahgross, mullan ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 89e43b8940c9 Author: dsamersoff Date: 2012-12-07 22:49 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/89e43b8940c9 8000537: Contextualize RequiredModelMBean class Summary: Contextualize RequiredModelMBean class Reviewed-by: asaha Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/javax/management/modelmbean/RequiredModelMBean.java Changeset: 7933c80c162a Author: denis Date: 2012-12-12 21:08 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7933c80c162a 8004341: Two JCK tests fails with 7u11 b06 Reviewed-by: serb, skoivu ! src/share/classes/java/awt/Dialog.java Changeset: ed08394e1a15 Author: mullan Date: 2012-12-18 13:48 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ed08394e1a15 8004302: javax/xml/soap/Test7013971.java fails since jdk6u39b01 Reviewed-by: vinnie, skoivu, mgrebac, ohair, tbell ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/Makefile Changeset: 32cd4975d2d6 Author: mchung Date: 2013-01-10 19:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/32cd4975d2d6 8005615: Java Logger fails to load tomcat logger implementation (JULI) Reviewed-by: alanb, ahgross ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/CustomLogManager.java + test/java/util/logging/CustomLogManagerTest.java + test/java/util/logging/SimpleLogManager.java Changeset: c0fbd737aef0 Author: ewendeli Date: 2013-01-28 11:07 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c0fbd737aef0 8006864: Update java.security-linux to include changes in java.security Reviewed-by: mchung, mullan ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 12491fa16985 Author: ewendeli Date: 2013-02-05 15:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/12491fa16985 Merge ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java ! src/share/classes/java/lang/Class.java - src/share/classes/sun/security/util/KeyLength.java Changeset: de419ea8ed8f Author: mchung Date: 2013-01-28 15:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/de419ea8ed8f 8006882: Proxy generated classes in sun.proxy package breaks JMockit Reviewed-by: alanb, ahgross ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 8effe3b7489d Author: dfuchs Date: 2013-01-30 11:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8effe3b7489d 8006446: Restrict MBeanServer access Reviewed-by: alanb, mchung, darcy, jrose, ahgross, skoivu ! src/share/classes/com/sun/jmx/mbeanserver/ClassLoaderRepositorySupport.java ! src/share/classes/com/sun/jmx/mbeanserver/JmxMBeanServer.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanInstantiator.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanSupport.java ! src/share/classes/java/lang/management/ManagementFactory.java ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation2Test.java ! test/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation3Test.java Changeset: ebfb0bb58428 Author: mchung Date: 2013-01-24 16:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ebfb0bb58428 8004937: Improve proxy construction Reviewed-by: jrose, ahgross ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java Changeset: af11c227a91e Author: mchung Date: 2013-02-05 22:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/af11c227a91e 8007393: Possible race condition after JDK-6664509 Reviewed-by: alanb, jgish ! src/share/classes/java/util/logging/LogManager.java Changeset: 1143bb5e7064 Author: mchung Date: 2013-02-07 09:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1143bb5e7064 8007611: logging behavior in applet changed Reviewed-by: alanb, jgish ! src/share/classes/java/util/logging/LogManager.java Changeset: 5925630b7a7d Author: xuelei Date: 2013-02-07 16:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5925630b7a7d 8006777: Improve TLS handling of invalid messages Reviewed-by: wetmore, ahgross ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/EngineInputRecord.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/InputRecord.java ! src/share/classes/sun/security/ssl/MAC.java ! src/share/classes/sun/security/ssl/OutputRecord.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: d57363ff612f Author: valeriep Date: 2013-02-07 16:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d57363ff612f 8007688: Blacklist known bad certificate Summary: Added two known bad certs to the blacklist certs. Reviewed-by: mullan ! src/share/classes/sun/security/util/UntrustedCertificates.java Changeset: c18aeb4ca957 Author: ewendeli Date: 2013-02-19 21:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c18aeb4ca957 Merge ! src/share/bin/parse_manifest.c ! src/share/classes/java/lang/Class.java - src/share/classes/sun/security/util/KeyLength.java ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! src/share/native/sun/awt/image/awt_parseImage.c ! test/Makefile Changeset: f7fb3de623ba Author: ewendeli Date: 2013-02-19 21:53 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f7fb3de623ba Merge Changeset: f686c8e3c8e0 Author: ewendeli Date: 2013-02-25 08:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f686c8e3c8e0 Merge ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/logging/LogManager.java - src/share/classes/sun/security/util/KeyLength.java ! src/share/native/com/sun/java/util/jar/pack/bands.cpp ! src/share/native/com/sun/java/util/jar/pack/bands.h ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp Changeset: e3cac5962e32 Author: vlivanov Date: 2013-02-22 03:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e3cac5962e32 8006439: Improve MethodHandles coverage Reviewed-by: jrose, twisti ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandles.java Changeset: 62be74f35886 Author: vlivanov Date: 2013-02-22 03:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/62be74f35886 8006179: JSR292 MethodHandles lookup with interface using findVirtual() Reviewed-by: jrose, twisti ! src/share/classes/java/lang/invoke/DirectMethodHandle.java Changeset: 9995881dfb4e Author: vlivanov Date: 2013-02-22 02:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9995881dfb4e 8006125: Update MethodHandles library interactions Reviewed-by: jrose ! src/share/classes/sun/reflect/misc/MethodUtil.java Changeset: 0807820fca96 Author: vlivanov Date: 2013-02-22 02:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0807820fca96 8004933: Improve MethodHandle interaction with libraries Reviewed-by: jrose ! src/share/classes/java/lang/invoke/MethodHandleNatives.java Changeset: ae1fed8d80e1 Author: ewendeli Date: 2013-02-26 06:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ae1fed8d80e1 Merge - src/share/classes/sun/security/util/KeyLength.java Changeset: 5e4c2d7f3b67 Author: ewendeli Date: 2013-02-26 20:36 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e4c2d7f3b67 Merge ! src/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandles.java - src/share/classes/sun/security/util/KeyLength.java Changeset: 4d4848124bff Author: ewendeli Date: 2013-02-27 09:28 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4d4848124bff Merge - src/share/classes/sun/security/util/KeyLength.java Changeset: 36ff48ae6ffe Author: ewendeli Date: 2013-02-27 18:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/36ff48ae6ffe Merge - src/share/classes/sun/security/util/KeyLength.java Changeset: 931fb59eae26 Author: lana Date: 2013-03-12 19:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/931fb59eae26 Merge ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/lang/Class.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/EngineInputRecord.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/InputRecord.java ! src/share/classes/sun/security/ssl/MAC.java ! src/share/classes/sun/security/ssl/OutputRecord.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java - src/share/classes/sun/security/util/KeyLength.java ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java Changeset: 9528e88f8d53 Author: lana Date: 2013-03-13 23:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9528e88f8d53 Merge - make/tools/javazic/Makefile - make/tools/src/build/tools/javazic/BackEnd.java - make/tools/src/build/tools/javazic/Checksum.java - make/tools/src/build/tools/javazic/DayOfWeek.java - make/tools/src/build/tools/javazic/Gen.java - make/tools/src/build/tools/javazic/GenDoc.java - make/tools/src/build/tools/javazic/Main.java - make/tools/src/build/tools/javazic/Mappings.java - make/tools/src/build/tools/javazic/Month.java - make/tools/src/build/tools/javazic/Rule.java - make/tools/src/build/tools/javazic/RuleDay.java - make/tools/src/build/tools/javazic/RuleRec.java - make/tools/src/build/tools/javazic/Simple.java - make/tools/src/build/tools/javazic/Time.java - make/tools/src/build/tools/javazic/Timezone.java - make/tools/src/build/tools/javazic/Zone.java - make/tools/src/build/tools/javazic/ZoneRec.java - make/tools/src/build/tools/javazic/Zoneinfo.java ! makefiles/CompileNativeLibraries.gmk ! makefiles/Images.gmk - src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java - src/share/classes/java/util/function/Block.java - src/share/classes/java/util/function/DoubleBlock.java - src/share/classes/java/util/function/IntBlock.java - src/share/classes/java/util/function/LongBlock.java - src/share/classes/sun/security/util/KeyLength.java - test/javax/script/RhinoExceptionTest.java Changeset: f282190e931a Author: lana Date: 2013-03-14 19:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f282190e931a Merge Changeset: c1a142965db0 Author: lana Date: 2013-03-15 23:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1a142965db0 Merge ! makefiles/CompileNativeLibraries.gmk ! src/share/classes/java/util/logging/Logger.java - src/share/classes/sun/security/util/KeyLength.java From chris.hegarty at oracle.com Sun Mar 17 08:36:24 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sun, 17 Mar 2013 08:36:24 +0000 Subject: hg: jdk8/tl/jdk: 8009222: java.lang.IllegalArgumentException: not invocable, no method type when attempting to get getter method handle for a static field Message-ID: <20130317083702.33312481F1@hg.openjdk.java.net> Changeset: c1165d566a23 Author: vlivanov Date: 2013-03-06 16:59 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1165d566a23 8009222: java.lang.IllegalArgumentException: not invocable, no method type when attempting to get getter method handle for a static field Reviewed-by: jrose, twisti ! src/share/classes/java/lang/invoke/DirectMethodHandle.java + test/java/lang/invoke/8009222/Test8009222.java From chris.hegarty at oracle.com Sun Mar 17 09:56:52 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sun, 17 Mar 2013 09:56:52 +0000 Subject: hg: jdk8/tl/jdk: 8010142: ProblemList.txt updates (3/2013) Message-ID: <20130317095730.7A3E3481F2@hg.openjdk.java.net> Changeset: ec8229b26dbc Author: chegar Date: 2013-03-17 09:55 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ec8229b26dbc 8010142: ProblemList.txt updates (3/2013) Reviewed-by: alanb ! test/ProblemList.txt From philip.race at oracle.com Sun Mar 17 16:10:58 2013 From: philip.race at oracle.com (Phil Race) Date: Sun, 17 Mar 2013 09:10:58 -0700 Subject: @Supported design issues In-Reply-To: <5144DFC7.6090306@gmail.com> References: <51266B7C.3040804@oracle.com>, <20130228113121.144747@eggemoggin.niobe.net>, <5134EED7.3040900@oracle.com> <20130315141249.582558@eggemoggin.niobe.net> <5144DFC7.6090306@gmail.com> Message-ID: <5145EB12.10905@oracle.com> 1. I suspect that the percentage of deprecated APIs is less than 0.1 % .. So removing 1 ouf every 1,000 methods is not exactly going to make a huge difference here. 2. Some methods were deprecated at a time when the policy was to encourage people to use "newer" API, even though there wasn't anything very wrong. with the old one. For example Component.show()/hide() were deprecated in favour of Component.setVisible(boolean) although as far as I know there's absolutely no problem with the former. So such a policy would not be something you could apply automatically you'd need to go examine each case to understand it. 3. Removing methods *from the doc* and *from the runtime* each have their consequences, from the doc would discourage new uses but make it harder to understand old code. I think a long ago ill-fated JSR for javadoc improvements pondered hiding deprecated methods if you didn't want to see them. Remiving from the runtime would break apps, and in some cases people don't have the option to change and fix. -phil. On 3/16/13 2:10 PM, Daniel Latr?moli?re wrote: >> I'm continually surprised by developers I meet at conferences who >> (sometimes angrily) demand that deprecated APIs be removed, so I think >> the reality is a mixed bag -- not that it matters a great deal either >> way. > Just a personal opinion as a developer. Java APIs are very big and > removing deprecated APIs can reduce this size. It will help solving > this question: "what can be the name of the currently needed > class/method in all these APIs?", which is very important, > particularly for new Java developers, frequently lost in these > numerous APIs. > > Readability is the biggest design feature of Java, then I think there > is some logic if developers ask for removal of deprecated API, because > it will improve readability of APIs. > > From daniel.latremoliere at gmail.com Sun Mar 17 19:10:32 2013 From: daniel.latremoliere at gmail.com (=?ISO-8859-1?Q?Daniel_Latr=E9moli=E8re?=) Date: Sun, 17 Mar 2013 20:10:32 +0100 Subject: @Supported design issues In-Reply-To: <5145EB12.10905@oracle.com> References: <51266B7C.3040804@oracle.com>, <20130228113121.144747@eggemoggin.niobe.net>, <5134EED7.3040900@oracle.com> <20130315141249.582558@eggemoggin.niobe.net> <5144DFC7.6090306@gmail.com> <5145EB12.10905@oracle.com> Message-ID: <51461528.1010604@gmail.com> > 1. I suspect that the percentage of deprecated APIs is less than 0.1 % .. > So removing 1 ouf every 1,000 methods is not exactly going to make > a huge difference here. > > 2. Some methods were deprecated at a time when the policy was to > encourage people to use "newer" API, even though there wasn't > anything very wrong. with the old one. > For example Component.show()/hide() were deprecated > in favour of Component.setVisible(boolean) although as far as I know > there's absolutely no problem with the former. > So such a policy would not be something you could apply automatically > you'd need to go examine each case to understand it. Yes or no for 0,1%, depending if you include some big parts like AWT, Swing, CORBA which are obsolete for many developers, because they are not considered up-to-date for their domains (UI, RPC) and their development is stopped. In this case, deprecated or obsolete API are concerning important domains, like: * UI (AWT -> Swing -> JavaFX), * date management (Date -> Calendar -> JSR 310) * RPC (RMI, CORBA, WebServices, REST like JAX-RS: not all are used even if winner depends of project). * LDAP dedicated API are provided by vendors like Apache Directory, OpenDJ for replacing JNDI (not evolving since Java 1.4 and seen not sufficiently specialized). * Logging API is split between java.util.logging, Log4J, SLF4J (depending of project). Other domains has evolved (like IO, NIO, NIO2) but contains some complex differences: e.g. Path vs. File. Considering File as deprecated in Java7 is frequent even if it is not official: http://stackoverflow.com/questions/6903335/java-7-path-vs-file Another related problem for a developer is that many parts of API show their age given others enhancements: e.g. Math/StrictMath classes were introduced before Integer/Long/Float/Double classes but would probably not have existed if order was inverse (static methods are notoriously difficult to find, because we don't know by default the class containing them). Globally, an API designed before Java 1.5 has usually be updated for generics but not for enumerations and only partially for annotations. Now, seeing an int for describing an enumeration in an API became surprising (like Modifier in reflection). Marker interfaces (like java.io.Serializable, java.util.RandomAccess) have same problem against annotations. The reason is simply that Java 1.5 is old: it has 8.5 years. API designed before have accumulated a technical debt and are not seen up-to-date. I think, I have covered big parts of Java API, concerning all developers, with various names (deprecated, obsolete, technical debt) for only one problem: feeling of an old API and need of cleaning it. NB: With static methods in interface, you will probably have the same problem in some years: 1) First round: add factories methods in interface. Developer speaking: When I want an instance of an interface it is always difficult to search a subclass and only after that call its constructor. I want to go to the expected interface and call a static factory for all my frequent usecases, then: please add some static methods like followings in List class (and all other interfaces with implementations provided by default): public static List newRandomAccessList() { return new ArrayList(); } public static List newLinearAccessList() { return new LinkedList(); } 2) Second round (some years after): remove them from public API. Developer speaking: I do not need to see AbstractList, ArrayList and LinkedList because I don't call them directly, at least in 99% of my usecases. This is a List-related implementation detail only useful when I want to create my own custom List for a highly specific and performance-sensitive usecase. Remove these classes from public API and put them in another library not seen by me by default, excepted if I really search it. In Javadoc, I only see the signature of method, and not the code of method (implementation detail), then I don't want to see these classes only implementing interfaces (implementation detail): the factory method in interface is sufficient with one paragraph in the Javadoc giving tradeoffs of each implementation provided by default. > 3. Removing methods *from the doc* and *from the runtime* each > have their consequences, from the doc would discourage new uses > but make it harder to understand old code. I think a long ago > ill-fated JSR > for javadoc improvements pondered hiding deprecated methods if > you didn't want to see them. Remiving from the runtime would > break apps, and in some cases people don't have the option to change > and fix. Currently, profiles are clearly reducing some API complexity for developer. NB: JavaFX doclet seems to remove methods with prefix impl_ from Javadoc. I think it seems sad, that one of the biggest differences between Java and shorter language like JavaScript is static typing: it give an excellent accuracy when used for automatic refactoring in Java. Given static typing, IDE have added many automatic refactoring and some mechanisms for helping updating code (e.g. generics), JSR 308 has also some inference tools. But bytecode refactoring (AOT in build process or JIT in ClassLoader) was mostly used for supporting new Java code with old JVM (Retroweaver, Retrotranslator) and not the inverse: supporting old Java bytecode on new JVM. I thought it was possibly used for executing JavaME program on JavaSE JVM but I am not sure. I hope of a future where Java easier refactoring (given static typing) would help evolving Java faster by breaking direct compatibility while keeping sufficiently real compatibility (old programs are only slightly slower in compatibility ClassLoader). With easier evolution, Java API can be better organized and developer become happy. NB: I never used "Java platform" because I think Java is slowly evolving, for developers, to become more a library for their application, than a platform containing application. Having an integrated JVM in each application is a big change in compatibility requirements, because developer has control on compatibility and it will possibly relax some constraints. 1) JavaEE applications are evolving to include server and not inverse: http://www.adam-bien.com/roller/abien/entry/why_not_one_application_per 2) JavaSE applications are evolving to include JVM and not to run on a JVM provided by OS: mobile OS prohibiting shared libraries and security problems of OS-global JVM define the rules: http://fxexperience.com/2012/06/application-deployment-with-javafx/ From philip.race at oracle.com Sun Mar 17 19:47:05 2013 From: philip.race at oracle.com (Phil Race) Date: Sun, 17 Mar 2013 12:47:05 -0700 Subject: @Supported design issues In-Reply-To: <51461528.1010604@gmail.com> References: <51266B7C.3040804@oracle.com>, <20130228113121.144747@eggemoggin.niobe.net>, <5134EED7.3040900@oracle.com> <20130315141249.582558@eggemoggin.niobe.net> <5144DFC7.6090306@gmail.com> <5145EB12.10905@oracle.com> <51461528.1010604@gmail.com> Message-ID: <51461DB9.5090305@oracle.com> That isn't at all what @deprecated means. "Encouraged for new development" doesn't mean everything else is @deprecated. These are all part of the Java SE platform spec, and are documented as such and are fully supported .. a focus on compatibility is very important to a lot of our customers, even if that's not you. -phil. On 3/17/13 12:10 PM, Daniel Latr?moli?re wrote: > >> 1. I suspect that the percentage of deprecated APIs is less than 0.1 >> % .. >> So removing 1 ouf every 1,000 methods is not exactly going to make >> a huge difference here. >> >> 2. Some methods were deprecated at a time when the policy was to >> encourage people to use "newer" API, even though there wasn't >> anything very wrong. with the old one. >> For example Component.show()/hide() were deprecated >> in favour of Component.setVisible(boolean) although as far as I know >> there's absolutely no problem with the former. >> So such a policy would not be something you could apply >> automatically >> you'd need to go examine each case to understand it. > Yes or no for 0,1%, depending if you include some big parts like AWT, > Swing, CORBA which are obsolete for many developers, because they are > not considered up-to-date for their domains (UI, RPC) and their > development is stopped. In this case, deprecated or obsolete API are > concerning important domains, like: > > * UI (AWT -> Swing -> JavaFX), > * date management (Date -> Calendar -> JSR 310) > * RPC (RMI, CORBA, WebServices, REST like JAX-RS: not all are used > even if winner depends of project). > * LDAP dedicated API are provided by vendors like Apache Directory, > OpenDJ for replacing JNDI (not evolving since Java 1.4 and seen > not sufficiently specialized). > * Logging API is split between java.util.logging, Log4J, SLF4J > (depending of project). > > Other domains has evolved (like IO, NIO, NIO2) but contains some > complex differences: e.g. Path vs. File. Considering File as > deprecated in Java7 is frequent even if it is not official: > http://stackoverflow.com/questions/6903335/java-7-path-vs-file > > Another related problem for a developer is that many parts of API show > their age given others enhancements: e.g. Math/StrictMath classes were > introduced before Integer/Long/Float/Double classes but would probably > not have existed if order was inverse (static methods are notoriously > difficult to find, because we don't know by default the class > containing them). > > Globally, an API designed before Java 1.5 has usually be updated for > generics but not for enumerations and only partially for annotations. > Now, seeing an int for describing an enumeration in an API became > surprising (like Modifier in reflection). Marker interfaces (like > java.io.Serializable, java.util.RandomAccess) have same problem > against annotations. The reason is simply that Java 1.5 is old: it has > 8.5 years. API designed before have accumulated a technical debt and > are not seen up-to-date. > > I think, I have covered big parts of Java API, concerning all > developers, with various names (deprecated, obsolete, technical debt) > for only one problem: feeling of an old API and need of cleaning it. > > NB: With static methods in interface, you will probably have the same > problem in some years: > > 1) First round: add factories methods in interface. > Developer speaking: When I want an instance of an interface it is > always difficult to search a subclass and only after that call its > constructor. I want to go to the expected interface and call a static > factory for all my frequent usecases, then: please add some static > methods like followings in List class (and all other interfaces with > implementations provided by default): > public static List newRandomAccessList() { > return new ArrayList(); > } > public static List newLinearAccessList() { > return new LinkedList(); > } > > 2) Second round (some years after): remove them from public API. > Developer speaking: I do not need to see AbstractList, ArrayList and > LinkedList because I don't call them directly, at least in 99% of my > usecases. This is a List-related implementation detail only useful > when I want to create my own custom List for a highly specific and > performance-sensitive usecase. Remove these classes from public API > and put them in another library not seen by me by default, excepted if > I really search it. > In Javadoc, I only see the signature of method, and not the code of > method (implementation detail), then I don't want to see these classes > only implementing interfaces (implementation detail): the factory > method in interface is sufficient with one paragraph in the Javadoc > giving tradeoffs of each implementation provided by default. > >> 3. Removing methods *from the doc* and *from the runtime* each >> have their consequences, from the doc would discourage new uses >> but make it harder to understand old code. I think a long ago >> ill-fated JSR >> for javadoc improvements pondered hiding deprecated methods if >> you didn't want to see them. Remiving from the runtime would >> break apps, and in some cases people don't have the option to change >> and fix. > Currently, profiles are clearly reducing some API complexity for > developer. > NB: JavaFX doclet seems to remove methods with prefix impl_ from Javadoc. > > I think it seems sad, that one of the biggest differences between Java > and shorter language like JavaScript is static typing: it give an > excellent accuracy when used for automatic refactoring in Java. Given > static typing, IDE have added many automatic refactoring and some > mechanisms for helping updating code (e.g. generics), JSR 308 has also > some inference tools. > > But bytecode refactoring (AOT in build process or JIT in ClassLoader) > was mostly used for supporting new Java code with old JVM > (Retroweaver, Retrotranslator) and not the inverse: supporting old > Java bytecode on new JVM. I thought it was possibly used for executing > JavaME program on JavaSE JVM but I am not sure. > > > I hope of a future where Java easier refactoring (given static typing) > would help evolving Java faster by breaking direct compatibility while > keeping sufficiently real compatibility (old programs are only > slightly slower in compatibility ClassLoader). With easier evolution, > Java API can be better organized and developer become happy. > > > NB: I never used "Java platform" because I think Java is slowly > evolving, for developers, to become more a library for their > application, than a platform containing application. Having an > integrated JVM in each application is a big change in compatibility > requirements, because developer has control on compatibility and it > will possibly relax some constraints. > 1) JavaEE applications are evolving to include server and not inverse: > http://www.adam-bien.com/roller/abien/entry/why_not_one_application_per > 2) JavaSE applications are evolving to include JVM and not to run on a > JVM provided by OS: mobile OS prohibiting shared libraries and > security problems of OS-global JVM define the rules: > http://fxexperience.com/2012/06/application-deployment-with-javafx/ > From daniel.latremoliere at gmail.com Sun Mar 17 22:30:47 2013 From: daniel.latremoliere at gmail.com (=?ISO-8859-1?Q?Daniel_Latr=E9moli=E8re?=) Date: Sun, 17 Mar 2013 23:30:47 +0100 Subject: @Supported design issues In-Reply-To: <51461DB9.5090305@oracle.com> References: <51266B7C.3040804@oracle.com>, <20130228113121.144747@eggemoggin.niobe.net>, <5134EED7.3040900@oracle.com> <20130315141249.582558@eggemoggin.niobe.net> <5144DFC7.6090306@gmail.com> <5145EB12.10905@oracle.com> <51461528.1010604@gmail.com> <51461DB9.5090305@oracle.com> Message-ID: <51464417.5070407@gmail.com> > That isn't at all what @deprecated means. > > "Encouraged for new development" doesn't mean everything else is > @deprecated. > These are all part of the Java SE platform spec, and are documented as > such > and are fully supported .. a focus on compatibility is very important > to a lot > of our customers, even if that's not you. Sorry if I have not clearly read, but it is not my opinion on Swing. Just for explaining reasons of my opinion (if you found some others people thinking like me) and not really arguing (person-specific then usually near useless), I will give you some texts inducing this personal point of view on Swing. --- When to Deprecate When you design an API, carefully consider whether it supersedes an old API. If it does, and you wish to encourage developers (users of the API) to migrate to the new API, then deprecate the old API. http://docs.oracle.com/javase/7/docs/technotes/guides/javadoc/deprecation/deprecation.html --- 6. Is JavaFX replacing Swing as the new client UI library for Java SE? Yes. However, Swing will remain part of the Java SE specification for the foreseeable future, and therefore included in the JRE. While we recommend developers to leverage JavaFX APIs as much as possible when building new applications, it is possible to extend a Swing application with JavaFX, allowing for a smoother transition. http://www.oracle.com/technetwork/java/javafx/overview/faq-1446554.html#6 --- [JEP 161] The primary motivation for this feature is to allow applications that do not require the entire Java SE Platform to run on resource-constrained devices. An application that does not use the Swing/AWT/2D graphics stack, e.g., or which uses Java FX instead, can achieve considerable space savings by running on top of a Profile that does not include those APIs. [... CDC migration to JavaSE ...] As a secondary benefit, this feature is likely to enable faster download times for applications that bundle their own Java Runtime Environment (JRE). http://openjdk.java.net/jeps/161 --- JavaFX applications have implicit dependency on the availability of Java and JavaFX runtimes, and while existing deployment methods provide a means to validate the system requirements are met -- and even guide the user to perform required installation/upgrades -- they do not fully address all of the important scenarios. In particular, here are few examples: the user may not have admin permissions to install new system software if the application was certified to run in the specific environment (fixed version of Java and JavaFX) then it may be hard to ensure user has this environment due to an autoupdate of the system version of Java/JavaFX (to ensure they are secure). Potentially, other apps may have a requirement for a different JRE or FX version that your app is incompatible with. your distribution channel may disallow dependencies on external frameworks (e.g. Mac AppStore) https://blogs.oracle.com/talkingjavadeployment/entry/native_packaging_for_javafx From sundararajan.athijegannathan at oracle.com Mon Mar 18 05:23:21 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Mon, 18 Mar 2013 05:23:21 +0000 Subject: hg: jdk8/tl/nashorn: 6 new changesets Message-ID: <20130318052326.24CA148207@hg.openjdk.java.net> Changeset: c54e218333be Author: sundar Date: 2013-03-12 18:12 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c54e218333be 8009757: Package access clean up and refactoring Reviewed-by: jlaskey, lagergren, attila ! docs/JavaScriptingProgrammersGuide.html ! docs/source/javaarray.js ! make/build.xml ! make/java.security.override ! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java + src/jdk/nashorn/api/scripting/ScriptUtils.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/NashornLoader.java ! src/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java + src/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java ! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js ! src/jdk/nashorn/internal/runtime/resources/parser.js ! test/script/basic/JDK-8008448.js ! test/script/basic/NASHORN-401.js ! test/script/basic/consstring.js ! test/script/basic/fileline.js ! test/script/basic/javainnerclasses.js ! test/script/basic/list.js ! test/script/basic/map.js ! test/script/basic/stdin.js ! test/script/sandbox/javaextend.js ! test/script/sandbox/javaextend.js.EXPECTED ! test/script/sandbox/reflection.js - test/script/sandbox/reflection.js.EXPECTED ! test/script/sandbox/unsafe.js - test/script/sandbox/unsafe.js.EXPECTED ! test/script/trusted/urlreader.js ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java - test/src/jdk/nashorn/internal/runtime/Nashorn401TestSubject.java ! test/src/jdk/nashorn/internal/runtime/TrustedScriptEngineTest.java - test/src/jdk/nashorn/internal/test/models/ConstructorWithArgument.java - test/src/jdk/nashorn/internal/test/models/DessertTopping.java - test/src/jdk/nashorn/internal/test/models/DessertToppingFloorWaxDriver.java - test/src/jdk/nashorn/internal/test/models/FinalClass.java - test/src/jdk/nashorn/internal/test/models/FloorWax.java - test/src/jdk/nashorn/internal/test/models/NoAccessibleConstructorClass.java - test/src/jdk/nashorn/internal/test/models/NonPublicClass.java - test/src/jdk/nashorn/internal/test/models/OuterClass.java - test/src/jdk/nashorn/internal/test/models/OverloadedSam.java - test/src/jdk/nashorn/internal/test/models/OverrideObject.java - test/src/jdk/nashorn/internal/test/models/StringArgs.java - test/src/jdk/nashorn/internal/test/models/Toothpaste.java + test/src/jdk/nashorn/test/models/ConstructorWithArgument.java + test/src/jdk/nashorn/test/models/DessertTopping.java + test/src/jdk/nashorn/test/models/DessertToppingFloorWaxDriver.java + test/src/jdk/nashorn/test/models/FinalClass.java + test/src/jdk/nashorn/test/models/FloorWax.java + test/src/jdk/nashorn/test/models/Nashorn401TestSubject.java + test/src/jdk/nashorn/test/models/NoAccessibleConstructorClass.java + test/src/jdk/nashorn/test/models/NonPublicClass.java + test/src/jdk/nashorn/test/models/OuterClass.java + test/src/jdk/nashorn/test/models/OverloadedSam.java + test/src/jdk/nashorn/test/models/OverrideObject.java + test/src/jdk/nashorn/test/models/SourceHelper.java + test/src/jdk/nashorn/test/models/StringArgs.java + test/src/jdk/nashorn/test/models/Toothpaste.java Changeset: e15806b9d716 Author: lagergren Date: 2013-03-12 15:30 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e15806b9d716 8009718: Lazy execution architecture continued - ScriptFunctionData is either final or recompilable. Moved ScriptFunctionData creation logic away from runtime to compile time. Prepared for method generation/specialization. Got rid of ScriptFunctionImplTrampoline whose semantics could be done as part of the relinking anyway. Merge with the lookup package change. Reviewed-by: attila, jlaskey ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/BranchOptimizer.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/CompileUnit.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/ir/UnaryNode.java - src/jdk/nashorn/internal/ir/annotations/ChildNode.java - src/jdk/nashorn/internal/ir/annotations/ParentNode.java ! src/jdk/nashorn/internal/ir/annotations/Reference.java ! src/jdk/nashorn/internal/ir/debug/ASTWriter.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java - src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java ! src/jdk/nashorn/internal/parser/JSONParser.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java + src/jdk/nashorn/internal/runtime/CompiledFunction.java + src/jdk/nashorn/internal/runtime/CompiledFunctions.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ECMAException.java + src/jdk/nashorn/internal/runtime/FinalScriptFunctionData.java + src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java - src/jdk/nashorn/internal/runtime/SpecializedMethodChooser.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuards.java ! src/jdk/nashorn/internal/runtime/options/OptionTemplate.java ! src/jdk/nashorn/internal/runtime/resources/Options.properties ! test/script/currently-failing/JDK-8006529.js + test/script/currently-failing/clone_ir.js Changeset: 60684aeba89c Author: sundar Date: 2013-03-12 21:17 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/60684aeba89c 8009868: For loop with "true" as condition results in AssertionError in codegen Reviewed-by: jlaskey, hannesw, lagergren ! src/jdk/nashorn/internal/codegen/Lower.java + test/script/basic/JDK-8009868.js Changeset: 390d44ba90cf Author: lagergren Date: 2013-03-14 14:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/390d44ba90cf 8009982: Lazy execution bugfix. Added lazy sunspider unit test. Added mandreel to compile-octane test. Fixed warnings Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/regexp/DefaultRegExp.java ! src/jdk/nashorn/internal/runtime/regexp/JoniRegExp.java ! src/jdk/nashorn/internal/runtime/regexp/RegExp.java ! src/jdk/nashorn/internal/runtime/regexp/RegExpFactory.java ! src/jdk/nashorn/internal/runtime/regexp/RegExpResult.java ! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java ! test/script/basic/compile-octane.js.EXPECTED ! test/script/basic/run-octane.js + test/script/basic/runsunspider-eager.js + test/script/basic/runsunspider-lazy.js ! test/script/basic/runsunspider.js Changeset: d5d80b52cf1c Author: lagergren Date: 2013-03-15 16:07 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d5d80b52cf1c 8010147: Forgot to add EXPECTED files for lazy and eager sunspider test Reviewed-by: sundar, jlaskey + test/script/basic/runsunspider-eager.js.EXPECTED + test/script/basic/runsunspider-lazy.js.EXPECTED - test/script/basic/runsunspider.js.EXPECTED Changeset: 4daacf8a25ef Author: sundar Date: 2013-03-15 21:52 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/4daacf8a25ef 8010145: removed workaround "init.js" in nashorn repo Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/api/scripting/Formatter.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptUtils.java ! src/jdk/nashorn/api/scripting/resources/engine.js - src/jdk/nashorn/api/scripting/resources/init.js From dl at cs.oswego.edu Mon Mar 18 14:10:51 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Mon, 18 Mar 2013 10:10:51 -0400 Subject: RFR 8005696: Add CompletableFuture - JEP 155 In-Reply-To: <5143258A.9020906@oracle.com> References: <5142070C.6000709@oracle.com> <51430D6B.4060601@cs.oswego.edu> <5143258A.9020906@oracle.com> Message-ID: <5147206B.4060001@cs.oswego.edu> On 03/15/13 09:43, Chris Hegarty wrote: > On 15/03/2013 12:00, Doug Lea wrote: >> Yes, thanks! This keeps the exception specs consistent across similar >> methods. > > Now that I reread these method descriptions, I think thenAcceptBothXXX suffer > the same problem: Yes; thanks. And also a few other cases of non-symmetric doc/code constructions. Martin and I (thanks Martin!) did a couple of passes to try to hit them all. (Chris: maybe you could resync with CVS?) The slogan for this class is: We write all the variants so users never have to. Some of the variants were added during a set of exchanges on concurrency-interest list last fall, which let some gratuitous differences creep in. -Doug From staffan.larsen at oracle.com Mon Mar 18 14:13:20 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 18 Mar 2013 15:13:20 +0100 Subject: RFR(S): 8009397 test/com/sun/jdi/PrivateTransportTest.sh: ERROR: transport library missing onLoad entry: private_dt_socket In-Reply-To: <6E926A33-CBCE-46C9-86A4-2C3F57E058CB@oracle.com> References: <2A1F6D24-22FC-4CB4-84FD-05E8ECDDC9BF@oracle.com> <513646F9.3060601@oracle.com> <51379D88.6080807@oracle.com> <6E926A33-CBCE-46C9-86A4-2C3F57E058CB@oracle.com> Message-ID: Can I get an official Review of this change? Thanks, /Staffan On 7 mar 2013, at 12:54, Staffan Larsen wrote: > Here is a webrev for fixing this problem. I actually removed all of our own tokenization code in dll_build_name() and replaced it with calls to strtok_r (strtok_s on windows) instead. I think this should be more robust, at the cost of an extra memory allocation. I've also added the const qualifier to some of the parameters. > > http://cr.openjdk.java.net/~sla/8009558/webrev.02/ > > All of the jdi and hprof tests passes with this change. > > Thanks, > /Staffan > > On 6 mar 2013, at 20:48, serguei.spitsyn at oracle.com wrote: > >> Staffan, >> >> Thank you for the confirmation and taking care about this issue! >> >> Thanks, >> Serguei >> >> >> On 3/6/13 11:36 AM, Staffan Larsen wrote: >>> Nice catch, Serguei! >>> >>> Unfortunately I have already pushed my change, but I filed "JDK-8009558: linked_md.c::dll_build_name can get stuck in an infinite loop" to track this new problem and I am working on a fix. >>> >>> Thanks, >>> /Staffan >>> >>> >>> On 5 mar 2013, at 20:26, serguei.spitsyn at oracle.com wrote: >>> >>>> Hi Staffan, >>>> >>>> Thank you for this discovery! >>>> It looks good, but I have a couple of comments. >>>> >>>> It seems, there is one more problem in this code: >>>> 68 /* check for NULL path */ >>>> 69 if (p == pathname) { >>>> 70 continue; <== Endless loop if we hit this line >>>> 71 } >>>> >>>> Do we need to do 'pathname++' before continuing at the line #70? >>>> It is going to be endless loop in cases there is a PATH_SEPARATOR >>>> at the beginning of paths or two PATH_SEPARATOR's in a row. >>>> These would be incorrect path lists but the code above is targeting exactly such cases. >>>> >>>> Also, the argument name "pathname" in the original code is confusing. >>>> Should we rename it to "pathnames"? >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 3/4/13 10:56 AM, Staffan Larsen wrote: >>>>> I accidentally stepped on this bug the other day. There is a problem in linker_md.c : dll_build_name() where an internal pointer can be moved to point outside the string. The code looks like: >>>>> >>>>> 57 static void dll_build_name(char* buffer, size_t buflen, >>>>> 58 const char* pname, const char* fname) { >>>>> 59 // Based on os_solaris.cpp >>>>> 60 >>>>> 61 char *path_sep = PATH_SEPARATOR; >>>>> 62 char *pathname = (char *)pname; >>>>> 63 while (strlen(pathname) > 0) { >>>>> 64 char *p = strchr(pathname, *path_sep); >>>>> 65 if (p == NULL) { >>>>> 66 p = pathname + strlen(pathname); >>>>> 67 } >>>>> 68 /* check for NULL path */ >>>>> 69 if (p == pathname) { >>>>> 70 continue; >>>>> 71 } >>>>> 72 (void)snprintf(buffer, buflen, "%.*s/lib%s." LIB_SUFFIX, (p - pathname), >>>>> 73 pathname, fname); >>>>> 74 >>>>> 75 if (access(buffer, F_OK) == 0) { >>>>> 76 break; >>>>> 77 } >>>>> 78 pathname = p + 1; >>>>> 79 *buffer = '\0'; >>>>> 80 } >>>>> >>>>> If the supplied pname is a buffer with a simple path without any path separators in it, p will be set to the terminating nul on line 66. Then on line 78 it will be moved outside the buffer. Fixing this also necessitates fixes to the callers to check for an empty return string (in buffer). >>>>> >>>>> The same code show up in both the solaris code and the windows code as well as hprof. >>>>> >>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8009397 >>>>> webrev: http://cr.openjdk.java.net/~sla/8009397/webrev.00/ >>>>> >>>>> Thanks, >>>>> /Staffan >>>> >>> >> > From staffan.larsen at oracle.com Mon Mar 18 14:14:03 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 18 Mar 2013 15:14:03 +0100 Subject: RFR(S): 8006637 Failure to filter out native frame events on Solaris In-Reply-To: <47E924B8-0406-4EA9-B9C5-2C30B7E3EBE6@oracle.com> References: <47E924B8-0406-4EA9-B9C5-2C30B7E3EBE6@oracle.com> Message-ID: <182C0956-0285-48E6-9A56-E90DDEDEDBB0@oracle.com> I still need an official Review for this change. Thanks, Staffan On 7 mar 2013, at 09:10, Staffan Larsen wrote: > Adding core-libs-dev and re-asking for a review. > > Thanks, > /Staffan > > On 27 feb 2013, at 15:59, Staffan Larsen wrote: > >> Please review the following test fix. >> >> webrev: http://cr.openjdk.java.net/~sla/8006637/webrev.00/ >> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006637 >> >> The problem is that the test assumes that no other threads call String.intern() while the tests is running. This is normally ok, but when running with JFR there are other threads calling String.intern() in the background and the test fails. The solution is to add a thread filter to the method exit requests so that only calls to String.inter() in the main thread are reported. >> >> Thanks, >> /Staffan > From jonathan.gibbons at oracle.com Mon Mar 18 15:46:33 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 18 Mar 2013 15:46:33 +0000 Subject: hg: jdk8/tl/langtools: 8005220: RFE to write javap tests for repeating annotations. Message-ID: <20130318154636.C04EB48212@hg.openjdk.java.net> Changeset: 1f8c28134ffc Author: jjg Date: 2013-03-18 08:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1f8c28134ffc 8005220: RFE to write javap tests for repeating annotations. Reviewed-by: jjg Contributed-by: peter.jensen at oracle.com + test/tools/javap/output/RepeatingTypeAnnotations.java + test/tools/javap/output/Tester.java From serguei.spitsyn at oracle.com Mon Mar 18 16:47:04 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 18 Mar 2013 09:47:04 -0700 Subject: RFR(S): 8009397 test/com/sun/jdi/PrivateTransportTest.sh: ERROR: transport library missing onLoad entry: private_dt_socket In-Reply-To: References: <2A1F6D24-22FC-4CB4-84FD-05E8ECDDC9BF@oracle.com> <513646F9.3060601@oracle.com> <51379D88.6080807@oracle.com> <6E926A33-CBCE-46C9-86A4-2C3F57E058CB@oracle.com> Message-ID: <51474508.7040000@oracle.com> I already reviewed this, and it is a good fix. Please, see my email attached. Thanks, Serguei On 3/18/13 7:13 AM, Staffan Larsen wrote: > Can I get an official Review of this change? > > Thanks, > /Staffan > > On 7 mar 2013, at 12:54, Staffan Larsen > wrote: > >> Here is a webrev for fixing this problem. I actually removed all of >> our own tokenization code in dll_build_name() and replaced it with >> calls to strtok_r (strtok_s on windows) instead. I think this should >> be more robust, at the cost of an extra memory allocation. I've also >> added the const qualifier to some of the parameters. >> >> http://cr.openjdk.java.net/~sla/8009558/webrev.02/ >> >> >> All of the jdi and hprof tests passes with this change. >> >> Thanks, >> /Staffan >> >> On 6 mar 2013, at 20:48, serguei.spitsyn at oracle.com >> wrote: >> >>> Staffan, >>> >>> Thank you for the confirmation and taking care about this issue! >>> >>> Thanks, >>> Serguei >>> >>> >>> On 3/6/13 11:36 AM, Staffan Larsen wrote: >>>> Nice catch, Serguei! >>>> >>>> Unfortunately I have already pushed my change, but I filed >>>> "JDK-8009558: linked_md.c::dll_build_name can get stuck in an >>>> infinite loop" to track this new problem and I am working on a fix. >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> >>>> On 5 mar 2013, at 20:26, serguei.spitsyn at oracle.com >>>> wrote: >>>> >>>>> Hi Staffan, >>>>> >>>>> Thank you for this discovery! >>>>> It looks good, but I have a couple of comments. >>>>> >>>>> It seems, there is one more problem in this code: >>>>> 68 /* check for NULL path */ >>>>> 69 if (p == pathname) { >>>>> 70 continue;<== Endless loop if we hit this line >>>>> 71 } >>>>> >>>>> Do we need to do 'pathname++' before continuing at the line #70? >>>>> It is going to be endless loop in cases there is a PATH_SEPARATOR >>>>> at the beginning of paths or two PATH_SEPARATOR's in a row. >>>>> These would be incorrect path lists but the code above is >>>>> targeting exactly such cases. >>>>> >>>>> Also, the argument name "pathname" in the original code is confusing. >>>>> Should we rename it to "pathnames"? >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 3/4/13 10:56 AM, Staffan Larsen wrote: >>>>>> I accidentally stepped on this bug the other day. There is a problem in linker_md.c : dll_build_name() where an internal pointer can be moved to point outside the string. The code looks like: >>>>>> >>>>>> 57 static void dll_build_name(char* buffer, size_t buflen, >>>>>> 58 const char* pname, const char* fname) { >>>>>> 59 // Based on os_solaris.cpp >>>>>> 60 >>>>>> 61 char *path_sep = PATH_SEPARATOR; >>>>>> 62 char *pathname = (char *)pname; >>>>>> 63 while (strlen(pathname) > 0) { >>>>>> 64 char *p = strchr(pathname, *path_sep); >>>>>> 65 if (p == NULL) { >>>>>> 66 p = pathname + strlen(pathname); >>>>>> 67 } >>>>>> 68 /* check for NULL path */ >>>>>> 69 if (p == pathname) { >>>>>> 70 continue; >>>>>> 71 } >>>>>> 72 (void)snprintf(buffer, buflen, "%.*s/lib%s." LIB_SUFFIX, (p - pathname), >>>>>> 73 pathname, fname); >>>>>> 74 >>>>>> 75 if (access(buffer, F_OK) == 0) { >>>>>> 76 break; >>>>>> 77 } >>>>>> 78 pathname = p + 1; >>>>>> 79 *buffer = '\0'; >>>>>> 80 } >>>>>> >>>>>> If the supplied pname is a buffer with a simple path without any path separators in it, p will be set to the terminating nul on line 66. Then on line 78 it will be moved outside the buffer. Fixing this also necessitates fixes to the callers to check for an empty return string (in buffer). >>>>>> >>>>>> The same code show up in both the solaris code and the windows code as well as hprof. >>>>>> >>>>>> bug:http://bugs.sun.com/view_bug.do?bug_id=8009397 >>>>>> webrev:http://cr.openjdk.java.net/~sla/8009397/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> /Staffan >>>>> >>>> >>> >> > -------------- next part -------------- An embedded message was scrubbed... From: "serguei.spitsyn at oracle.com" Subject: Re: RFR(S): 8009397 test/com/sun/jdi/PrivateTransportTest.sh: ERROR: transport library missing onLoad entry: private_dt_socket Date: Thu, 07 Mar 2013 10:49:05 -0800 Size: 5335 URL: From serguei.spitsyn at oracle.com Mon Mar 18 16:54:00 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 18 Mar 2013 09:54:00 -0700 Subject: RFR(S): 8006637 Failure to filter out native frame events on Solaris In-Reply-To: <182C0956-0285-48E6-9A56-E90DDEDEDBB0@oracle.com> References: <47E924B8-0406-4EA9-B9C5-2C30B7E3EBE6@oracle.com> <182C0956-0285-48E6-9A56-E90DDEDEDBB0@oracle.com> Message-ID: <514746A8.7090205@oracle.com> It is just a remainder that I reviewed this as well (the fix is good too). My email is attached. Thanks, Serguei On 3/18/13 7:14 AM, Staffan Larsen wrote: > I still need an official Review for this change. > > Thanks, > Staffan > > On 7 mar 2013, at 09:10, Staffan Larsen wrote: > >> Adding core-libs-dev and re-asking for a review. >> >> Thanks, >> /Staffan >> >> On 27 feb 2013, at 15:59, Staffan Larsen wrote: >> >>> Please review the following test fix. >>> >>> webrev: http://cr.openjdk.java.net/~sla/8006637/webrev.00/ >>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006637 >>> >>> The problem is that the test assumes that no other threads call String.intern() while the tests is running. This is normally ok, but when running with JFR there are other threads calling String.intern() in the background and the test fails. The solution is to add a thread filter to the method exit requests so that only calls to String.inter() in the main thread are reported. >>> >>> Thanks, >>> /Staffan -------------- next part -------------- An embedded message was scrubbed... From: "serguei.spitsyn at oracle.com" Subject: Re: RFR(S): 8006637 Failure to filter out native frame events on Solaris Date: Thu, 07 Mar 2013 02:05:00 -0800 Size: 1697 URL: From heliofrota at gmail.com Mon Mar 18 18:09:41 2013 From: heliofrota at gmail.com (Helio Frota) Date: Mon, 18 Mar 2013 15:09:41 -0300 Subject: java encoding charset suggestion Message-ID: Hi All, Sorry if here is not the right place to do a suggestion of this subject. Please take a look on this post: http://www.heliofrota.com/blog/2013/03/18/understanding-java-encoding/ I would suggest taking en_US.UTF-8 as default when the LANG variable is not set to avoid problems with encoding. Thanks. -- Helio Frota http://www.heliofrota.com/ From martinrb at google.com Mon Mar 18 18:24:21 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 18 Mar 2013 11:24:21 -0700 Subject: java encoding charset suggestion In-Reply-To: References: Message-ID: It *would* be nice if the world agreed on using UTF-8 as a universal encoding for all text. However: Standard says http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html """If the LANG environment variable is not set or is set to the empty string, the implementation-defined default locale shall be used.""" But I think the operating system should set the default, not the application. On my Ubuntu system I see the traditional ASCII English default: $ (unset LC_ALL LC_COLLATE LANG LANGUAGE GDM_LANG; locale) LANG= LANGUAGE= LC_CTYPE="POSIX" LC_NUMERIC="POSIX" LC_TIME="POSIX" LC_COLLATE="POSIX" LC_MONETARY="POSIX" LC_MESSAGES="POSIX" LC_PAPER="POSIX" LC_NAME="POSIX" LC_ADDRESS="POSIX" LC_TELEPHONE="POSIX" LC_MEASUREMENT="POSIX" LC_IDENTIFICATION="POSIX" LC_ALL= On Mon, Mar 18, 2013 at 11:09 AM, Helio Frota wrote: > > I would suggest taking en_US.UTF-8 as default when the LANG variable is not > set to avoid problems with encoding. > From heliofrota at gmail.com Mon Mar 18 18:34:01 2013 From: heliofrota at gmail.com (Helio Frota) Date: Mon, 18 Mar 2013 15:34:01 -0300 Subject: java encoding charset suggestion In-Reply-To: References: Message-ID: Hi Martin Buchholz, I believe (but I could be wrong) that only java applications exhibit this behavior, programs made with GTK or QT are not affected, they probably look at the level of the X11 case are not in variable LANG or assume a default locale. > $ (unset LC_ALL LC_COLLATE LANG LANGUAGE GDM_LANG; locale) > LANG= > LANGUAGE= > LC_CTYPE="POSIX" > LC_NUMERIC="POSIX" > LC_TIME="POSIX" > LC_COLLATE="POSIX" > LC_MONETARY="POSIX" > LC_MESSAGES="POSIX" > LC_PAPER="POSIX" > LC_NAME="POSIX" > LC_ADDRESS="POSIX" > LC_TELEPHONE="POSIX" > LC_MEASUREMENT="POSIX" > LC_IDENTIFICATION="POSIX" > LC_ALL= > Please try to use ? ? ? ... But I think the operating system should set the default, not the > application. On my Ubuntu system I see the traditional ASCII English > default: > I agree, but the JVM could not be pro-active ? Thanks for reply ! 2013/3/18 Martin Buchholz > It *would* be nice if the world agreed on using UTF-8 as a universal > encoding for all text. However: > > Standard says > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html > > """If the LANG environment variable is not set or is set to the empty > string, the implementation-defined default locale shall be used.""" > > But I think the operating system should set the default, not the > application. On my Ubuntu system I see the traditional ASCII English > default: > > $ (unset LC_ALL LC_COLLATE LANG LANGUAGE GDM_LANG; locale) > LANG= > LANGUAGE= > LC_CTYPE="POSIX" > LC_NUMERIC="POSIX" > LC_TIME="POSIX" > LC_COLLATE="POSIX" > LC_MONETARY="POSIX" > LC_MESSAGES="POSIX" > LC_PAPER="POSIX" > LC_NAME="POSIX" > LC_ADDRESS="POSIX" > LC_TELEPHONE="POSIX" > LC_MEASUREMENT="POSIX" > LC_IDENTIFICATION="POSIX" > LC_ALL= > > > On Mon, Mar 18, 2013 at 11:09 AM, Helio Frota wrote: > >> >> I would suggest taking en_US.UTF-8 as default when the LANG variable is >> not >> set to avoid problems with encoding. >> > -- Helio Frota http://www.heliofrota.com/ From lowasser at google.com Mon Mar 18 18:47:25 2013 From: lowasser at google.com (Louis Wasserman) Date: Mon, 18 Mar 2013 11:47:25 -0700 Subject: java encoding charset suggestion In-Reply-To: References: Message-ID: This would probably be likely to break lots of existing users depending on the default charset, depressingly enough. On Mon, Mar 18, 2013 at 11:34 AM, Helio Frota wrote: > Hi Martin Buchholz, > > I believe (but I could be wrong) that only java applications exhibit this > behavior, programs made with GTK or QT are not affected, > they probably look at the level of the X11 case are not in variable > LANG or assume > a default locale. > > > > $ (unset LC_ALL LC_COLLATE LANG LANGUAGE GDM_LANG; locale) > > LANG= > > LANGUAGE= > > LC_CTYPE="POSIX" > > LC_NUMERIC="POSIX" > > LC_TIME="POSIX" > > LC_COLLATE="POSIX" > > LC_MONETARY="POSIX" > > LC_MESSAGES="POSIX" > > LC_PAPER="POSIX" > > LC_NAME="POSIX" > > LC_ADDRESS="POSIX" > > LC_TELEPHONE="POSIX" > > LC_MEASUREMENT="POSIX" > > LC_IDENTIFICATION="POSIX" > > LC_ALL= > > > > Please try to use ? ? ? ... > > But I think the operating system should set the default, not the > > application. On my Ubuntu system I see the traditional ASCII English > > default: > > > > I agree, but the JVM could not be pro-active ? > > Thanks for reply ! > > 2013/3/18 Martin Buchholz > > > It *would* be nice if the world agreed on using UTF-8 as a universal > > encoding for all text. However: > > > > Standard says > > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html > > > > """If the LANG environment variable is not set or is set to the empty > > string, the implementation-defined default locale shall be used.""" > > > > But I think the operating system should set the default, not the > > application. On my Ubuntu system I see the traditional ASCII English > > default: > > > > $ (unset LC_ALL LC_COLLATE LANG LANGUAGE GDM_LANG; locale) > > LANG= > > LANGUAGE= > > LC_CTYPE="POSIX" > > LC_NUMERIC="POSIX" > > LC_TIME="POSIX" > > LC_COLLATE="POSIX" > > LC_MONETARY="POSIX" > > LC_MESSAGES="POSIX" > > LC_PAPER="POSIX" > > LC_NAME="POSIX" > > LC_ADDRESS="POSIX" > > LC_TELEPHONE="POSIX" > > LC_MEASUREMENT="POSIX" > > LC_IDENTIFICATION="POSIX" > > LC_ALL= > > > > > > On Mon, Mar 18, 2013 at 11:09 AM, Helio Frota >wrote: > > > >> > >> I would suggest taking en_US.UTF-8 as default when the LANG variable is > >> not > >> set to avoid problems with encoding. > >> > > > > > -- > Helio Frota > http://www.heliofrota.com/ > -- Louis Wasserman From martinrb at google.com Mon Mar 18 19:04:08 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 18 Mar 2013 12:04:08 -0700 Subject: java encoding charset suggestion In-Reply-To: References: Message-ID: On Mon, Mar 18, 2013 at 11:34 AM, Helio Frota wrote: > > Please try to use ? ? ? ... > > But I think the operating system should set the default, not the >> application. On my Ubuntu system I see the traditional ASCII English >> default: >> > > I agree, but the JVM could not be pro-active ? How can java know that UTF-8 will work better than, for example, ISO-8859-1? It cannot, so it asks the operating system, which answers "Use ASCII". "Well, OK, at least it will work for Americans" From heliofrota at gmail.com Mon Mar 18 20:05:50 2013 From: heliofrota at gmail.com (Helio Frota) Date: Mon, 18 Mar 2013 17:05:50 -0300 Subject: java encoding charset suggestion In-Reply-To: References: Message-ID: Hi Martin, Is not interesting to favor one country or language. I read some documents including the link you shared ( opengroup ). Only one thing i found is the python language that try to found defined values on others variables. http://docs.python.org/2/library/locale.html But after absorbing more information, I agree that would be chaos breaking compatibility. Thanks for reply ! I learned more things today. 2013/3/18 Martin Buchholz > > > > On Mon, Mar 18, 2013 at 11:34 AM, Helio Frota wrote: > >> >> Please try to use ? ? ? ... >> >> But I think the operating system should set the default, not the >>> application. On my Ubuntu system I see the traditional ASCII English >>> default: >>> >> >> I agree, but the JVM could not be pro-active ? > > > How can java know that UTF-8 will work better than, for example, > ISO-8859-1? > It cannot, so it asks the operating system, which answers "Use ASCII". > "Well, OK, at least it will work for Americans" > -- Helio Frota http://www.heliofrota.com/ From martinrb at google.com Mon Mar 18 21:28:23 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 18 Mar 2013 14:28:23 -0700 Subject: Please review: surrogate fiddle Message-ID: Hello Jim, Mike, I'd like you to do a code review: http://cr.openjdk.java.net/~martin/webrevs/openjdk8/surrogate-fiddle/ From mike.duigou at oracle.com Mon Mar 18 22:08:45 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 18 Mar 2013 15:08:45 -0700 Subject: Please review: surrogate fiddle In-Reply-To: References: Message-ID: This change would seem to change the result when a high surrogate is the last char in the String/StringBuilder/StringBuffer. Rather than throwing an ArrayIndexException it will return the high surrogate char. I am going to defer to Sherman on this. I don't know that returning the character is the right thing to do. Sherman? Mike On Mar 18 2013, at 14:28 , Martin Buchholz wrote: > Hello Jim, Mike, > > I'd like you to do a code review: > > http://cr.openjdk.java.net/~martin/webrevs/openjdk8/surrogate-fiddle/ From martinrb at google.com Mon Mar 18 22:13:01 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 18 Mar 2013 15:13:01 -0700 Subject: Please review: surrogate fiddle In-Reply-To: References: Message-ID: It does change the behavior. The existing behavior is clearly a bug, since it reads a char that should be inaccessible. I don't believe AIOOBE exception is thrown, with or without my fix. On Mon, Mar 18, 2013 at 3:08 PM, Mike Duigou wrote: > This change would seem to change the result when a high surrogate is the > last char in the String/StringBuilder/StringBuffer. > > Rather than throwing an ArrayIndexException it will return the high > surrogate char. > > I am going to defer to Sherman on this. I don't know that returning the > character is the right thing to do. > > Sherman? > > Mike > > On Mar 18 2013, at 14:28 , Martin Buchholz wrote: > > Hello Jim, Mike, > > I'd like you to do a code review: > > http://cr.openjdk.java.net/~martin/webrevs/openjdk8/surrogate-fiddle/ > > > From xueming.shen at oracle.com Mon Mar 18 22:37:30 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 18 Mar 2013 15:37:30 -0700 Subject: Please review: surrogate fiddle In-Reply-To: References: Message-ID: <5147972A.6000603@oracle.com> The spec of both affected methods says "the char at the index is returned, if the following conditions are not true 1) hi-surrogate && 2) next index < count && 3) char at next is lo-surrogate So it is the right thing to do to simply return the char at index, if it is the last char in the buffer. Martin, the purpose of dup the code here is for better performance? -Sherman On 03/18/2013 03:13 PM, Martin Buchholz wrote: > It does change the behavior. The existing behavior is clearly a bug, since it reads a char that should be inaccessible. I don't believe AIOOBE exception is thrown, with or without my fix. > > > On Mon, Mar 18, 2013 at 3:08 PM, Mike Duigou > wrote: > > This change would seem to change the result when a high surrogate is the last char in the String/StringBuilder/StringBuffer. > > Rather than throwing an ArrayIndexException it will return the high surrogate char. > > I am going to defer to Sherman on this. I don't know that returning the character is the right thing to do. > > Sherman? > > Mike > > On Mar 18 2013, at 14:28 , Martin Buchholz wrote: > >> Hello Jim, Mike, >> >> I'd like you to do a code review: >> >> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/surrogate-fiddle/ > > From david.holmes at oracle.com Tue Mar 19 01:09:53 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Mar 2013 11:09:53 +1000 Subject: RFR(S): 8009397 test/com/sun/jdi/PrivateTransportTest.sh: ERROR: transport library missing onLoad entry: private_dt_socket In-Reply-To: <51474508.7040000@oracle.com> References: <2A1F6D24-22FC-4CB4-84FD-05E8ECDDC9BF@oracle.com> <513646F9.3060601@oracle.com> <51379D88.6080807@oracle.com> <6E926A33-CBCE-46C9-86A4-2C3F57E058CB@oracle.com> <51474508.7040000@oracle.com> Message-ID: <5147BAE1.8070509@oracle.com> Hi Serguei, On 19/03/2013 2:47 AM, serguei.spitsyn at oracle.com wrote: > I already reviewed this, and it is a good fix. > Please, see my email attached. You are not an OpenJDK Reviewer [1] . Staffan needs an official Review from a Reviewer before it can be pushed. That doesn't mean your review is not wanted or appreciated - it mostly certain is - but an official Review is still required. Cheers, David [1] http://openjdk.java.net/bylaws#reviewer > Thanks, > Serguei > > On 3/18/13 7:13 AM, Staffan Larsen wrote: >> Can I get an official Review of this change? >> >> Thanks, >> /Staffan >> >> On 7 mar 2013, at 12:54, Staffan Larsen > > wrote: >> >>> Here is a webrev for fixing this problem. I actually removed all of >>> our own tokenization code in dll_build_name() and replaced it with >>> calls to strtok_r (strtok_s on windows) instead. I think this should >>> be more robust, at the cost of an extra memory allocation. I've also >>> added the const qualifier to some of the parameters. >>> >>> http://cr.openjdk.java.net/~sla/8009558/webrev.02/ >>> >>> >>> All of the jdi and hprof tests passes with this change. >>> >>> Thanks, >>> /Staffan >>> >>> On 6 mar 2013, at 20:48, serguei.spitsyn at oracle.com >>> wrote: >>> >>>> Staffan, >>>> >>>> Thank you for the confirmation and taking care about this issue! >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 3/6/13 11:36 AM, Staffan Larsen wrote: >>>>> Nice catch, Serguei! >>>>> >>>>> Unfortunately I have already pushed my change, but I filed >>>>> "JDK-8009558: linked_md.c::dll_build_name can get stuck in an >>>>> infinite loop" to track this new problem and I am working on a fix. >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> >>>>> On 5 mar 2013, at 20:26, serguei.spitsyn at oracle.com >>>>> wrote: >>>>> >>>>>> Hi Staffan, >>>>>> >>>>>> Thank you for this discovery! >>>>>> It looks good, but I have a couple of comments. >>>>>> >>>>>> It seems, there is one more problem in this code: >>>>>> 68 /* check for NULL path */ >>>>>> 69 if (p == pathname) { >>>>>> 70 continue;<== Endless loop if we hit this line >>>>>> 71 } >>>>>> >>>>>> Do we need to do 'pathname++' before continuing at the line #70? >>>>>> It is going to be endless loop in cases there is a PATH_SEPARATOR >>>>>> at the beginning of paths or two PATH_SEPARATOR's in a row. >>>>>> These would be incorrect path lists but the code above is >>>>>> targeting exactly such cases. >>>>>> >>>>>> Also, the argument name "pathname" in the original code is confusing. >>>>>> Should we rename it to "pathnames"? >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 3/4/13 10:56 AM, Staffan Larsen wrote: >>>>>>> I accidentally stepped on this bug the other day. There is a >>>>>>> problem in linker_md.c : dll_build_name() where an internal >>>>>>> pointer can be moved to point outside the string. The code looks >>>>>>> like: >>>>>>> >>>>>>> 57 static void dll_build_name(char* buffer, size_t buflen, >>>>>>> 58 const char* pname, const char* >>>>>>> fname) { >>>>>>> 59 // Based on os_solaris.cpp >>>>>>> 60 >>>>>>> 61 char *path_sep = PATH_SEPARATOR; >>>>>>> 62 char *pathname = (char *)pname; >>>>>>> 63 while (strlen(pathname) > 0) { >>>>>>> 64 char *p = strchr(pathname, *path_sep); >>>>>>> 65 if (p == NULL) { >>>>>>> 66 p = pathname + strlen(pathname); >>>>>>> 67 } >>>>>>> 68 /* check for NULL path */ >>>>>>> 69 if (p == pathname) { >>>>>>> 70 continue; >>>>>>> 71 } >>>>>>> 72 (void)snprintf(buffer, buflen, "%.*s/lib%s." >>>>>>> LIB_SUFFIX, (p - pathname), >>>>>>> 73 pathname, fname); >>>>>>> 74 >>>>>>> 75 if (access(buffer, F_OK) == 0) { >>>>>>> 76 break; >>>>>>> 77 } >>>>>>> 78 pathname = p + 1; >>>>>>> 79 *buffer = '\0'; >>>>>>> 80 } >>>>>>> >>>>>>> If the supplied pname is a buffer with a simple path without any >>>>>>> path separators in it, p will be set to the terminating nul on >>>>>>> line 66. Then on line 78 it will be moved outside the buffer. >>>>>>> Fixing this also necessitates fixes to the callers to check for >>>>>>> an empty return string (in buffer). >>>>>>> >>>>>>> The same code show up in both the solaris code and the windows >>>>>>> code as well as hprof. >>>>>>> >>>>>>> bug:http://bugs.sun.com/view_bug.do?bug_id=8009397 >>>>>>> webrev:http://cr.openjdk.java.net/~sla/8009397/webrev.00/ >>>>>>> >>>>>>> Thanks, >>>>>>> /Staffan >>>>>> >>>>> >>>> >>> >> > From bradford.wetmore at oracle.com Tue Mar 19 01:29:45 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Mon, 18 Mar 2013 18:29:45 -0700 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: <513AEEBB.2080900@oracle.com> References: <5139E680.6000606@oracle.com> <513A0A96.7080508@oracle.com> <513A8194.9040002@oracle.com> <513AEEBB.2080900@oracle.com> Message-ID: <5147BF89.7000602@oracle.com> Sorry for the delay in response, I've been pulled in yet another direction, and this has come back up in priority. On 3/9/2013 12:11 AM, Chris Hegarty wrote: >> I agree about warning creeping problems. This is a temporary solution, >> we should soon be fixing the underlying hashcode/equals problems...but... > > Your temporary solution, -overrides, is just that. It will enable the > old build to complete today, but it could fail at any point in the > future, as the code changes. Correct. As it stands today, a recent change now requires *BOTH* overrides/deprecation in order to get a complete MASTER build using the old build system. [brwetmor at flicker-vm1] 222 >hg diff common/shared/Defs-java.gmk diff --git a/make/common/shared/Defs-java.gmk b/make/common/shared/Defs-java.gmk --- a/make/common/shared/Defs-java.gmk +++ b/make/common/shared/Defs-java.gmk @@ -127,7 +127,7 @@ endif # TODO: Workaround for CR 7063027. Remove -path eventually. -JAVAC_LINT_OPTIONS += -Xlint:-path +JAVAC_LINT_OPTIONS += -Xlint:-path,-overrides,-deprecation JAVACFLAGS += $(JAVAC_LINT_OPTIONS) > For example, java.net is currently warning free, in the old it compiles > with fatal warnings enabled. Lets say, in a moment of madness, I add a > dependency from java.net.Socket to say java.awt.RenderingHints.Key ( or > any class that produces warnings when compiled. I run the new build, all > is fine. Push the changes. Now someone else sync's up, but need to build > using the old build. If the new dependent class is not already compiled > before java.net.Socket gets compiled, it will be compiled implicitly. > It's warnings will cause the compile to fail, and the old build will > fail. Or much simpler, anyone could write sloppy code with warnings, the > new build will suppress them, and they won't notice. Push this code, and > the old build will fail if is explicitly, or implicitly, compiles this > code with -Werror enabled. Exactly. Our formerly clean code now requires disabling of two Lint options, but the new build is happy just to report the warning. The old build crashes on the warning. Our options for the old build system are: 1. disable the warning for overrides/deprecation, keep -Werror (my preferred since these are minor warnings.) 2. Somehow disable -Werror on these new directories that are now failing. (more work to figure out, but also acceptable) 3. Fix the warnings. (I don't have cycles to drive a rewrite of use of deprecated code and/or add missing equals/hashcode that the recent javac changes exposed.) >> We >> spent a lot of time cleaning up many directories, seems a shame to start >> allowing non-fatal warnings to come back into previously clean code >> because people aren't taking the time to fix new warnings as they are >> introduced. > > I personally spent several weeks over the past number of years fixing > warnings and reviewing warning cleanup webrevs from others. I took much > pride in keeping certain areas warnings free. > > It is with great regret that I propose to disable fatal warnings in the > old build, but I felt this the best/safest option. I heard much > annoyance and frustration from others about hitting seemingly random > errors with the old build recently. This is the only sure way to avoid > that. > >> The new builds will still warn, but the >> old builds will still fail for all but these override problems. Yes, >> you lose the warnings in the old, but seems better than completely >> shutting off erroring. > > I'm ok with that, if others are. To clarify, I think you are suggesting > that we keep the old build as it, with -overrides, and now ",-deprecation" :( > and use it > periodically as a way of tracking new warnings being introduced into > areas that were warning free. That would be a side-effect, as someone would occasionally need to figure out what's changed. The main issue we're hitting right now is that RE has to make several source code changes in order to build JCE jar files without errors. I was able to change the individual LINT options globally and reduce it down to one change, but that's still one change that RE has to make. I feel that RE should not be making any changes, but that ship has already sailed and we're stuck with the results now. That is, if the old build fails because of > a fatal warning, so be it. File a bug and fix the source code. Then the > old build will work again. This means that at any point in time the old > build cannot be guaranteed to be buildable. > > Everyone seems to agree, a solution needs to be found to allow us to > keep certain areas warning free. This issue is too important, and too > much time was spent, to allow it to regress to the state it was in a few > years ago. It's already started. Brad > -Chris. > >> >> (Ideally it would be nice to warn but not fail on just this one lint >> option, but don't see how that's possible.) >> >> Brad >> >> >> >> >> >>> -Chris. >>> >>>> >>>> Mike >>>> >>>> On Mar 8 2013, at 05:24 , Chris Hegarty wrote: >>>> >>>>> Since the new build does not enable -Werror when compiling any java >>>>> code, and disables quite a few lint options, new changes my >>>>> inadvertently introduce warnings without even realizing. This can >>>>> cause problems when building with the old build as many areas do >>>>> compile with -Werror set. Since the old build is on life support, >>>>> probably best to just completely disable -Werror, so anyone still >>>>> needing to use it can. >>>>> >>>>> diff -r 48b7295f02f8 make/common/shared/Defs-java.gmk >>>>> --- a/make/common/shared/Defs-java.gmk Thu Mar 07 10:07:13 2013 +0000 >>>>> +++ b/make/common/shared/Defs-java.gmk Thu Mar 07 11:10:37 2013 +0000 >>>>> @@ -122,9 +122,10 @@ ifeq ($(JAVAC_MAX_WARNINGS), true) >>>>> ifeq ($(JAVAC_MAX_WARNINGS), true) >>>>> JAVAC_LINT_OPTIONS += -Xlint:all >>>>> endif >>>>> -ifeq ($(JAVAC_WARNINGS_FATAL), true) >>>>> - JAVACFLAGS += -Werror >>>>> -endif >>>>> +# Disable fatal warnings, 8009517 >>>>> +#ifeq ($(JAVAC_WARNINGS_FATAL), true) >>>>> +# JAVACFLAGS += -Werror >>>>> +#endif >>>>> >>>>> # TODO: Workaround for CR 7063027. Remove -path eventually. >>>>> JAVAC_LINT_OPTIONS += -Xlint:-path >>>>> >>>>> -Chris. >>>> From jonathan.gibbons at oracle.com Tue Mar 19 01:35:56 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 19 Mar 2013 01:35:56 +0000 Subject: hg: jdk8/tl/jaxws: 8007803: Implement javax.lang.model API for Type Annotations Message-ID: <20130319013600.64CC548234@hg.openjdk.java.net> Changeset: 0ab59cba6167 Author: jjg Date: 2013-03-18 18:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/0ab59cba6167 8007803: Implement javax.lang.model API for Type Annotations Reviewed-by: darcy ! src/share/jaxws_classes/com/sun/tools/internal/jxc/model/nav/ApNavigator.java From jonathan.gibbons at oracle.com Tue Mar 19 01:36:30 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 19 Mar 2013 01:36:30 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20130319013639.115A448235@hg.openjdk.java.net> Changeset: 40adaf938847 Author: jjg Date: 2013-03-18 14:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/40adaf938847 8008425: Remove interim new javax.lang.model API for type-annotations Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java - src/share/classes/javax/lang/model/type/AnnotatedType.java ! src/share/classes/javax/lang/model/type/ExecutableType.java ! src/share/classes/javax/lang/model/type/TypeKind.java ! src/share/classes/javax/lang/model/type/TypeVisitor.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java ! src/share/classes/javax/lang/model/util/Types.java Changeset: 97f6839673d6 Author: jjg Date: 2013-03-18 18:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/97f6839673d6 8007803: Implement javax.lang.model API for Type Annotations Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java + src/share/classes/com/sun/tools/javac/model/JavacAnnoConstructs.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java + src/share/classes/javax/lang/model/AnnotatedConstruct.java ! src/share/classes/javax/lang/model/element/Element.java ! src/share/classes/javax/lang/model/element/ExecutableElement.java ! src/share/classes/javax/lang/model/type/ExecutableType.java ! src/share/classes/javax/lang/model/type/TypeMirror.java ! src/share/classes/javax/lang/model/util/Types.java From masayoshi.okutsu at oracle.com Tue Mar 19 02:44:08 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Tue, 19 Mar 2013 11:44:08 +0900 Subject: Please review: surrogate fiddle In-Reply-To: References: Message-ID: <5147D0F8.3090101@oracle.com> Thank you for catching this bug. AbstractStringBuilder.codePointAt(int) should have called Character.codePointAt(char[], int, int). As for duplicating code, I originally duplicated similar code everywhere for performance. But someone told me probably during code review that hotspot inlining was as good as C/C++ macros, and I agreed to replace the duplicated code with method calls. Masayoshi On 3/19/2013 7:13 AM, Martin Buchholz wrote: > It does change the behavior. The existing behavior is clearly a bug, since > it reads a char that should be inaccessible. I don't believe AIOOBE > exception is thrown, with or without my fix. > > > On Mon, Mar 18, 2013 at 3:08 PM, Mike Duigou wrote: > >> This change would seem to change the result when a high surrogate is the >> last char in the String/StringBuilder/StringBuffer. >> >> Rather than throwing an ArrayIndexException it will return the high >> surrogate char. >> >> I am going to defer to Sherman on this. I don't know that returning the >> character is the right thing to do. >> >> Sherman? >> >> Mike >> >> On Mar 18 2013, at 14:28 , Martin Buchholz wrote: >> >> Hello Jim, Mike, >> >> I'd like you to do a code review: >> >> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/surrogate-fiddle/ >> >> >> From martinrb at google.com Tue Mar 19 04:21:49 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 18 Mar 2013 21:21:49 -0700 Subject: Please review: surrogate fiddle In-Reply-To: <5147972A.6000603@oracle.com> References: <5147972A.6000603@oracle.com> Message-ID: On Mon, Mar 18, 2013 at 3:37 PM, Xueming Shen wrote: > ** > > The spec of both affected methods says "the char at the index is returned, > if > the following conditions are not true > > 1) hi-surrogate && > 2) next index < count && > 3) char at next is lo-surrogate > > So it is the right thing to do to simply return the char at index, if it > is the last > char in the buffer. > > Right. > Martin, the purpose of dup the code here is for better performance? > Yes. From martinrb at google.com Tue Mar 19 06:04:44 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 18 Mar 2013 23:04:44 -0700 Subject: Please review: surrogate fiddle In-Reply-To: <5147D0F8.3090101@oracle.com> References: <5147D0F8.3090101@oracle.com> Message-ID: On Mon, Mar 18, 2013 at 7:44 PM, Masayoshi Okutsu < masayoshi.okutsu at oracle.com> wrote: > Thank you for catching this bug. AbstractStringBuilder.**codePointAt(int) > should have called Character.codePointAt(char[], int, int). > > As for duplicating code, I originally duplicated similar code everywhere > for performance. But someone told me probably during code review that > hotspot inlining was as good as C/C++ macros, and I agreed to replace the > duplicated code with method calls. > > For classes as important as important as StringBuilder, I think we should go the extra mile to ensure best performance, but if you guys insist, I will "merely" fix the bug. If you call the Character method, you will be doing bounds checking twice (or thrice, if you count builtin array checking), and there's a chance that hotspot will be able to optimize it away, but I am not so trusting. Martin From Alan.Bateman at oracle.com Tue Mar 19 07:51:55 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Mar 2013 07:51:55 +0000 Subject: RFR(S): 8006637 Failure to filter out native frame events on Solaris In-Reply-To: <182C0956-0285-48E6-9A56-E90DDEDEDBB0@oracle.com> References: <47E924B8-0406-4EA9-B9C5-2C30B7E3EBE6@oracle.com> <182C0956-0285-48E6-9A56-E90DDEDEDBB0@oracle.com> Message-ID: <5148191B.4060401@oracle.com> I see Serguei has reviewed this. It looks okay to me too. -Alan. On 18/03/2013 14:14, Staffan Larsen wrote: > I still need an official Review for this change. > > Thanks, > Staffan > > On 7 mar 2013, at 09:10, Staffan Larsen wrote: > >> Adding core-libs-dev and re-asking for a review. >> >> Thanks, >> /Staffan >> >> On 27 feb 2013, at 15:59, Staffan Larsen wrote: >> >>> Please review the following test fix. >>> >>> webrev: http://cr.openjdk.java.net/~sla/8006637/webrev.00/ >>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006637 >>> >>> The problem is that the test assumes that no other threads call String.intern() while the tests is running. This is normally ok, but when running with JFR there are other threads calling String.intern() in the background and the test fails. The solution is to add a thread filter to the method exit requests so that only calls to String.inter() in the main thread are reported. >>> >>> Thanks, >>> /Staffan From staffan.larsen at oracle.com Tue Mar 19 08:54:05 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 19 Mar 2013 09:54:05 +0100 Subject: RFR(S): 8006637 Failure to filter out native frame events on Solaris In-Reply-To: <5148191B.4060401@oracle.com> References: <47E924B8-0406-4EA9-B9C5-2C30B7E3EBE6@oracle.com> <182C0956-0285-48E6-9A56-E90DDEDEDBB0@oracle.com> <5148191B.4060401@oracle.com> Message-ID: <6BC8DCF3-605A-4E1F-8BB9-F165D016931B@oracle.com> Thanks! On 19 mar 2013, at 08:51, Alan Bateman wrote: > > I see Serguei has reviewed this. It looks okay to me too. > > -Alan. > > On 18/03/2013 14:14, Staffan Larsen wrote: >> I still need an official Review for this change. >> >> Thanks, >> Staffan >> >> On 7 mar 2013, at 09:10, Staffan Larsen wrote: >> >>> Adding core-libs-dev and re-asking for a review. >>> >>> Thanks, >>> /Staffan >>> >>> On 27 feb 2013, at 15:59, Staffan Larsen wrote: >>> >>>> Please review the following test fix. >>>> >>>> webrev: http://cr.openjdk.java.net/~sla/8006637/webrev.00/ >>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006637 >>>> >>>> The problem is that the test assumes that no other threads call String.intern() while the tests is running. This is normally ok, but when running with JFR there are other threads calling String.intern() in the background and the test fails. The solution is to add a thread filter to the method exit requests so that only calls to String.inter() in the main thread are reported. >>>> >>>> Thanks, >>>> /Staffan > From staffan.larsen at oracle.com Tue Mar 19 08:53:39 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Tue, 19 Mar 2013 08:53:39 +0000 Subject: hg: jdk8/tl/jdk: 8006637: Failure to filter out native frame events on Solaris Message-ID: <20130319085407.F1BA148247@hg.openjdk.java.net> Changeset: a0275a47fa78 Author: sla Date: 2013-03-19 09:53 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a0275a47fa78 8006637: Failure to filter out native frame events on Solaris Summary: Test is confused by other threads calling String.intern(). Add a thread filter to avoid this. Reviewed-by: sspitsyn, alanb ! test/com/sun/jdi/NativeInstanceFilter.java From chris.hegarty at oracle.com Tue Mar 19 09:37:17 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 19 Mar 2013 09:37:17 +0000 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: <5147BF89.7000602@oracle.com> References: <5139E680.6000606@oracle.com> <513A0A96.7080508@oracle.com> <513A8194.9040002@oracle.com> <513AEEBB.2080900@oracle.com> <5147BF89.7000602@oracle.com> Message-ID: <514831CD.9030409@oracle.com> Brad, I do not build using the old build anymore. This is clearly a blocker for your work. If you want to suppress the warnings for overrides/deprecation, then please push the change ( your patch ). We can revisit this in the future, when it is necessary. -Chris. On 03/19/2013 01:29 AM, Brad Wetmore wrote: > Sorry for the delay in response, I've been pulled in yet another > direction, and this has come back up in priority. > > On 3/9/2013 12:11 AM, Chris Hegarty wrote: >>> I agree about warning creeping problems. This is a temporary solution, >>> we should soon be fixing the underlying hashcode/equals >>> problems...but... >> >> Your temporary solution, -overrides, is just that. It will enable the >> old build to complete today, but it could fail at any point in the >> future, as the code changes. > > Correct. As it stands today, a recent change now requires *BOTH* > overrides/deprecation in order to get a complete MASTER build using the > old build system. > > [brwetmor at flicker-vm1] 222 >hg diff common/shared/Defs-java.gmk > diff --git a/make/common/shared/Defs-java.gmk > b/make/common/shared/Defs-java.gmk > --- a/make/common/shared/Defs-java.gmk > +++ b/make/common/shared/Defs-java.gmk > @@ -127,7 +127,7 @@ > endif > > # TODO: Workaround for CR 7063027. Remove -path eventually. > -JAVAC_LINT_OPTIONS += -Xlint:-path > +JAVAC_LINT_OPTIONS += -Xlint:-path,-overrides,-deprecation > > JAVACFLAGS += $(JAVAC_LINT_OPTIONS) > >> For example, java.net is currently warning free, in the old it compiles >> with fatal warnings enabled. Lets say, in a moment of madness, I add a >> dependency from java.net.Socket to say java.awt.RenderingHints.Key ( or >> any class that produces warnings when compiled. I run the new build, all >> is fine. Push the changes. Now someone else sync's up, but need to build >> using the old build. If the new dependent class is not already compiled >> before java.net.Socket gets compiled, it will be compiled implicitly. >> It's warnings will cause the compile to fail, and the old build will >> fail. Or much simpler, anyone could write sloppy code with warnings, the >> new build will suppress them, and they won't notice. Push this code, and >> the old build will fail if is explicitly, or implicitly, compiles this >> code with -Werror enabled. > > Exactly. Our formerly clean code now requires disabling of two Lint > options, but the new build is happy just to report the warning. The old > build crashes on the warning. > > Our options for the old build system are: > > 1. disable the warning for overrides/deprecation, keep -Werror (my > preferred since these are minor warnings.) > 2. Somehow disable -Werror on these new directories that are now > failing. (more work to figure out, but also acceptable) > 3. Fix the warnings. (I don't have cycles to drive a rewrite of use of > deprecated code and/or add missing equals/hashcode that the recent javac > changes exposed.) > >>> We >>> spent a lot of time cleaning up many directories, seems a shame to start >>> allowing non-fatal warnings to come back into previously clean code >>> because people aren't taking the time to fix new warnings as they are >>> introduced. >> >> I personally spent several weeks over the past number of years fixing >> warnings and reviewing warning cleanup webrevs from others. I took much >> pride in keeping certain areas warnings free. >> >> It is with great regret that I propose to disable fatal warnings in the >> old build, but I felt this the best/safest option. I heard much >> annoyance and frustration from others about hitting seemingly random >> errors with the old build recently. This is the only sure way to avoid >> that. >> >>> The new builds will still warn, but the >>> old builds will still fail for all but these override problems. Yes, >>> you lose the warnings in the old, but seems better than completely >>> shutting off erroring. >> >> I'm ok with that, if others are. To clarify, I think you are suggesting >> that we keep the old build as it, with -overrides, > > and now ",-deprecation" :( > >> and use it >> periodically as a way of tracking new warnings being introduced into >> areas that were warning free. > > That would be a side-effect, as someone would occasionally need to > figure out what's changed. > > The main issue we're hitting right now is that RE has to make several > source code changes in order to build JCE jar files without errors. I > was able to change the individual LINT options globally and reduce it > down to one change, but that's still one change that RE has to make. I > feel that RE should not be making any changes, but that ship has already > sailed and we're stuck with the results now. > > That is, if the old build fails because of >> a fatal warning, so be it. File a bug and fix the source code. Then the >> old build will work again. This means that at any point in time the old >> build cannot be guaranteed to be buildable. >> >> Everyone seems to agree, a solution needs to be found to allow us to >> keep certain areas warning free. This issue is too important, and too >> much time was spent, to allow it to regress to the state it was in a few >> years ago. > > It's already started. > > Brad > > >> -Chris. >> >>> >>> (Ideally it would be nice to warn but not fail on just this one lint >>> option, but don't see how that's possible.) >>> >>> Brad >>> >>> >>> >>> >>> >>>> -Chris. >>>> >>>>> >>>>> Mike >>>>> >>>>> On Mar 8 2013, at 05:24 , Chris Hegarty wrote: >>>>> >>>>>> Since the new build does not enable -Werror when compiling any java >>>>>> code, and disables quite a few lint options, new changes my >>>>>> inadvertently introduce warnings without even realizing. This can >>>>>> cause problems when building with the old build as many areas do >>>>>> compile with -Werror set. Since the old build is on life support, >>>>>> probably best to just completely disable -Werror, so anyone still >>>>>> needing to use it can. >>>>>> >>>>>> diff -r 48b7295f02f8 make/common/shared/Defs-java.gmk >>>>>> --- a/make/common/shared/Defs-java.gmk Thu Mar 07 10:07:13 2013 >>>>>> +0000 >>>>>> +++ b/make/common/shared/Defs-java.gmk Thu Mar 07 11:10:37 2013 >>>>>> +0000 >>>>>> @@ -122,9 +122,10 @@ ifeq ($(JAVAC_MAX_WARNINGS), true) >>>>>> ifeq ($(JAVAC_MAX_WARNINGS), true) >>>>>> JAVAC_LINT_OPTIONS += -Xlint:all >>>>>> endif >>>>>> -ifeq ($(JAVAC_WARNINGS_FATAL), true) >>>>>> - JAVACFLAGS += -Werror >>>>>> -endif >>>>>> +# Disable fatal warnings, 8009517 >>>>>> +#ifeq ($(JAVAC_WARNINGS_FATAL), true) >>>>>> +# JAVACFLAGS += -Werror >>>>>> +#endif >>>>>> >>>>>> # TODO: Workaround for CR 7063027. Remove -path eventually. >>>>>> JAVAC_LINT_OPTIONS += -Xlint:-path >>>>>> >>>>>> -Chris. >>>>> From david.holmes at oracle.com Tue Mar 19 10:01:43 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Tue, 19 Mar 2013 10:01:43 +0000 Subject: hg: jdk8/tl/jdk: 8009426: "profiles" target fails due to nashorn if "images" is not built first Message-ID: <20130319100204.DE7DD4824A@hg.openjdk.java.net> Changeset: e766da5575fa Author: dholmes Date: 2013-03-19 06:01 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e766da5575fa 8009426: "profiles" target fails due to nashorn if "images" is not built first Reviewed-by: alanb ! makefiles/CreateJars.gmk ! makefiles/Profiles.gmk ! makefiles/profile-includes.txt From bourges.laurent at gmail.com Tue Mar 19 12:19:58 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Tue, 19 Mar 2013 13:19:58 +0100 Subject: PlatformLogger: isLoggable performance / waste due to HashMap leads to Integer allocations (boxing) Message-ID: Dear all, I run recently netbeans profiler on my swing application (Aspro2: http://www.jmmc.fr/aspro) under linux x64 platform and figured out a performance and waste issue related to PlatformLogger. Actually, the JavaLogger implementation uses a Map levelObjects to store mapping between PlatformLogger's levels (int) and JUL Level instances. However, the isLoggable(int level) method is highly used by awt project and other JDK projects and it leads to many Integer allocations as autoboxing converts the level as int to an Integer instance used by the Map.get() call. /** * JavaLogger forwards all the calls to its corresponding * java.util.logging.Logger object. */ static class JavaLogger extends LoggerProxy { private static final* Map* levelObjects = new HashMap<>(); ... public boolean isLoggable(*int level*) { return LoggingSupport.isLoggable(javaLogger, * levelObjects.get(level)*); } } I wrote a simple test to illustrate that performance / waste problem: PlatformLoggerTest that simply performs 1 million DISABLED log statements: if (log.isLoggable(PlatformLogger.FINEST)) { log.finest("test PlatformLogger.FINEST"); } As you can see in screenshots: - 5 million Integer instances are allocated - Integer.valueOf(int) is called 5 million times (autoboxing) - HashMap.get() represents 30% of the test time - patched PlatformLogger is 3x times faster [jvm options: -Xms8m -Xmx8m -verbose:gc] I suggest you to use an alternative way to map PlatformLogger's levels (int) and JUL Level instances to fix that performance / memory issue: I added the getLevel(int level) method that performs a switch case to return the corresponding Level object (quick and dirty solution). I advocate this is not a very clean solution but I prefer efficiency here: any better solution may be appropriate to avoid at least Integer allocation and maybe enhance performance. Best regards, Laurent Bourg?s PS: here is the patch as text: # This patch file was generated by NetBeans IDE # It uses platform neutral UTF-8 encoding and \n newlines. --- PlatformLogger.java (6767) +++ PlatformLogger.java (6768) @@ -468,31 +468,13 @@ * java.util.logging.Logger object. */ static class JavaLogger extends LoggerProxy { - /** Note: using Integer keys leads to a lot of new Integer instances !! */ - private static final Map levelObjects = new HashMap<>(); - /** fastest mapping to Level instances from PlatformLogger level as integer */ - private static final Object[] fastLevelObjects; - - + private static final Map levelObjects = + new HashMap<>(); + static { if (LoggingSupport.isAvailable()) { // initialize the map to Level objects getLevelObjects(); - - // initialize the fastLevelObjects: - fastLevelObjects = new Object[] { - LoggingSupport.parseLevel(getLevelName(OFF)), // 0 - LoggingSupport.parseLevel(getLevelName(SEVERE)), // 1 - LoggingSupport.parseLevel(getLevelName(WARNING)), // 2 - LoggingSupport.parseLevel(getLevelName(INFO)), // 3 - LoggingSupport.parseLevel(getLevelName(CONFIG)), // 4 - LoggingSupport.parseLevel(getLevelName(FINE)), // 5 - LoggingSupport.parseLevel(getLevelName(FINER)), // 6 - LoggingSupport.parseLevel(getLevelName(FINEST)), // 7 - LoggingSupport.parseLevel(getLevelName(ALL)) // 8 - }; - } else { - fastLevelObjects = null; // check null } } @@ -515,7 +497,7 @@ this.javaLogger = LoggingSupport.getLogger(name); if (level != 0) { // level has been updated and so set the Logger's level - LoggingSupport.setLevel(javaLogger, getLevel(level)); + LoggingSupport.setLevel(javaLogger, levelObjects.get(level)); } } @@ -526,11 +508,11 @@ * not be updated. */ void doLog(int level, String msg) { - LoggingSupport.log(javaLogger, getLevel(level), msg); + LoggingSupport.log(javaLogger, levelObjects.get(level), msg); } void doLog(int level, String msg, Throwable t) { - LoggingSupport.log(javaLogger, getLevel(level), msg, t); + LoggingSupport.log(javaLogger, levelObjects.get(level), msg, t); } void doLog(int level, String msg, Object... params) { @@ -544,12 +526,12 @@ for (int i = 0; i < len; i++) { sparams [i] = String.valueOf(params[i]); } - LoggingSupport.log(javaLogger, getLevel(level), msg, sparams); + LoggingSupport.log(javaLogger, levelObjects.get(level), msg, sparams); } boolean isEnabled() { Object level = LoggingSupport.getLevel(javaLogger); - return level == null || level.equals(getLevel(OFF)) == false; + return level == null || level.equals(levelObjects.get(OFF)) == false; } int getLevel() { @@ -566,34 +548,12 @@ void setLevel(int newLevel) { levelValue = newLevel; - LoggingSupport.setLevel(javaLogger, getLevel(newLevel)); + LoggingSupport.setLevel(javaLogger, levelObjects.get(newLevel)); } public boolean isLoggable(int level) { - return LoggingSupport.isLoggable(javaLogger, getLevel(level)); + return LoggingSupport.isLoggable(javaLogger, levelObjects.get(level)); } - - /** - * Return the corresponding level object (fastest implementation) - * @param level PlatformLogger level as primitive integer - * @return Object (JUL Level instance) - */ - private static Object getLevel(final int level) { - // higher occurences first (finest, fine, finer, info): - switch (level) { - case FINEST : return fastLevelObjects[7]; - case FINE : return fastLevelObjects[5]; - case FINER : return fastLevelObjects[6]; - case INFO : return fastLevelObjects[3]; - case CONFIG : return fastLevelObjects[4]; - case WARNING : return fastLevelObjects[2]; - case SEVERE : return fastLevelObjects[1]; - case ALL : return fastLevelObjects[8]; - case OFF : return fastLevelObjects[0]; - default : return null; - } - } - } private static String getLevelName(int level) { From chris.hegarty at oracle.com Tue Mar 19 16:32:49 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 19 Mar 2013 16:32:49 +0000 Subject: hg: jdk8/tl/jdk: 8007607: security native code doesn't always use malloc, realloc, and calloc correctly Message-ID: <20130319163312.61ECD48255@hg.openjdk.java.net> Changeset: 4103eb6b2137 Author: jzavgren Date: 2013-03-18 14:21 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4103eb6b2137 8007607: security native code doesn't always use malloc, realloc, and calloc correctly Reviewed-by: chegar, dsamersoff, valeriep ! src/share/native/sun/security/jgss/wrapper/GSSLibStub.c ! src/share/native/sun/security/jgss/wrapper/NativeUtil.c ! src/solaris/native/com/sun/security/auth/module/Solaris.c ! src/solaris/native/com/sun/security/auth/module/Unix.c ! src/solaris/native/sun/security/smartcardio/pcsc_md.c From chris.hegarty at oracle.com Tue Mar 19 16:53:43 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 19 Mar 2013 16:53:43 +0000 Subject: RFR 8005696: Add CompletableFuture - JEP 155 In-Reply-To: <5147206B.4060001@cs.oswego.edu> References: <5142070C.6000709@oracle.com> <51430D6B.4060601@cs.oswego.edu> <5143258A.9020906@oracle.com> <5147206B.4060001@cs.oswego.edu> Message-ID: <51489817.7070809@oracle.com> Updated specdiff and webrev. Unless I hear otherwise, I think the API is as good as final. http://cr.openjdk.java.net/~chegar/8005696/ver.01/specdiff/java/util/concurrent/package-summary.html http://cr.openjdk.java.net/~chegar/8005696/ver.01/webrev/ -Chris On 03/18/2013 02:10 PM, Doug Lea wrote: > On 03/15/13 09:43, Chris Hegarty wrote: >> On 15/03/2013 12:00, Doug Lea wrote: >>> Yes, thanks! This keeps the exception specs consistent across similar >>> methods. >> >> Now that I reread these method descriptions, I think thenAcceptBothXXX >> suffer >> the same problem: > > Yes; thanks. And also a few other cases of non-symmetric doc/code > constructions. Martin and I (thanks Martin!) did a couple of passes > to try to hit them all. (Chris: maybe you could resync with CVS?) > > The slogan for this class is: We write all the variants > so users never have to. Some of the variants were added during a > set of exchanges on concurrency-interest list last fall, which > let some gratuitous differences creep in. > > -Doug > > > From martinrb at google.com Tue Mar 19 17:18:07 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 19 Mar 2013 10:18:07 -0700 Subject: RFR 8005696: Add CompletableFuture - JEP 155 In-Reply-To: <51489817.7070809@oracle.com> References: <5142070C.6000709@oracle.com> <51430D6B.4060601@cs.oswego.edu> <5143258A.9020906@oracle.com> <5147206B.4060001@cs.oswego.edu> <51489817.7070809@oracle.com> Message-ID: Sorry, just finished one more (final?) round of exception spec updates, notably to change "unchecked exception" to "exception", since the code catches any Throwable. On Tue, Mar 19, 2013 at 9:53 AM, Chris Hegarty wrote: > Updated specdiff and webrev. Unless I hear otherwise, I think the API is > as good as final. > > > http://cr.openjdk.java.net/~**chegar/8005696/ver.01/** > specdiff/java/util/concurrent/**package-summary.html > http://cr.openjdk.java.net/~**chegar/8005696/ver.01/webrev/ > > -Chris > > > On 03/18/2013 02:10 PM, Doug Lea wrote: > >> On 03/15/13 09:43, Chris Hegarty wrote: >> >>> On 15/03/2013 12:00, Doug Lea wrote: >>> >>>> Yes, thanks! This keeps the exception specs consistent across similar >>>> methods. >>>> >>> >>> Now that I reread these method descriptions, I think thenAcceptBothXXX >>> suffer >>> the same problem: >>> >> >> Yes; thanks. And also a few other cases of non-symmetric doc/code >> constructions. Martin and I (thanks Martin!) did a couple of passes >> to try to hit them all. (Chris: maybe you could resync with CVS?) >> >> The slogan for this class is: We write all the variants >> so users never have to. Some of the variants were added during a >> set of exchanges on concurrency-interest list last fall, which >> let some gratuitous differences creep in. >> >> -Doug >> >> >> >> From chris.hegarty at oracle.com Tue Mar 19 17:33:00 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 19 Mar 2013 17:33:00 +0000 Subject: RFR 8005696: Add CompletableFuture - JEP 155 In-Reply-To: References: <5142070C.6000709@oracle.com> <51430D6B.4060601@cs.oswego.edu> <5143258A.9020906@oracle.com> <5147206B.4060001@cs.oswego.edu> <51489817.7070809@oracle.com> Message-ID: <5148A14C.3030305@oracle.com> On 03/19/2013 05:18 PM, Martin Buchholz wrote: > Sorry, just finished one more (final?) round of exception spec updates, > notably to change "unchecked exception" to "exception", since the code > catches any Throwable. Thanks Martin, my fault I suggested "unchecked". I also like the additional clarification for XXXEither. I'll grab this update, and consider it final ;-) -Chris. > > > On Tue, Mar 19, 2013 at 9:53 AM, Chris Hegarty > wrote: > > Updated specdiff and webrev. Unless I hear otherwise, I think the > API is as good as final. > > > http://cr.openjdk.java.net/~__chegar/8005696/ver.01/__specdiff/java/util/concurrent/__package-summary.html > > http://cr.openjdk.java.net/~__chegar/8005696/ver.01/webrev/ > > > -Chris > > > On 03/18/2013 02:10 PM, Doug Lea wrote: > > On 03/15/13 09:43, Chris Hegarty wrote: > > On 15/03/2013 12:00, Doug Lea wrote: > > Yes, thanks! This keeps the exception specs consistent > across similar > methods. > > > Now that I reread these method descriptions, I think > thenAcceptBothXXX > suffer > the same problem: > > > Yes; thanks. And also a few other cases of non-symmetric doc/code > constructions. Martin and I (thanks Martin!) did a couple of passes > to try to hit them all. (Chris: maybe you could resync with CVS?) > > The slogan for this class is: We write all the variants > so users never have to. Some of the variants were added during a > set of exchanges on concurrency-interest list last fall, which > let some gratuitous differences creep in. > > -Doug > > > > From mandy.chung at oracle.com Tue Mar 19 17:41:08 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 19 Mar 2013 10:41:08 -0700 Subject: PlatformLogger: isLoggable performance / waste due to HashMap leads to Integer allocations (boxing) In-Reply-To: References: Message-ID: <5148A334.6060207@oracle.com> Hi Laurent, Thanks for the contribution. I agree that the map can be replaced with a direct mapping from a int value to Level object and avoid the autoboxing conversion. I have filed a bug to track this and target this for JDK8: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id= 8010309 Thanks Mandy On 3/19/13 5:19 AM, Laurent Bourg?s wrote: > Dear all, > > I run recently netbeans profiler on my swing application (Aspro2: > http://www.jmmc.fr/aspro) under linux x64 platform and figured out a > performance and waste issue related to PlatformLogger. > > Actually, the JavaLogger implementation uses a Map > levelObjects to store mapping between PlatformLogger's levels (int) and JUL > Level instances. > > However, the isLoggable(int level) method is highly used by awt project and > other JDK projects and it leads to many Integer allocations as autoboxing > converts the level as int to an Integer instance used by the Map.get() call. > > /** > * JavaLogger forwards all the calls to its corresponding > * java.util.logging.Logger object. > */ > static class JavaLogger extends LoggerProxy { > private static final* Map* levelObjects = new > HashMap<>(); > ... > public boolean isLoggable(*int level*) { > return LoggingSupport.isLoggable(javaLogger, * > levelObjects.get(level)*); > } > } > > I wrote a simple test to illustrate that performance / waste problem: > PlatformLoggerTest that simply performs 1 million DISABLED log statements: > if (log.isLoggable(PlatformLogger.FINEST)) { > log.finest("test PlatformLogger.FINEST"); > } > > As you can see in screenshots: > - 5 million Integer instances are allocated > - Integer.valueOf(int) is called 5 million times (autoboxing) > - HashMap.get() represents 30% of the test time > - patched PlatformLogger is 3x times faster > [jvm options: -Xms8m -Xmx8m -verbose:gc] > > I suggest you to use an alternative way to map PlatformLogger's levels > (int) and JUL Level instances to fix that performance / memory issue: I > added the getLevel(int level) method that performs a switch case to return > the corresponding Level object (quick and dirty solution). > > I advocate this is not a very clean solution but I prefer efficiency here: > any better solution may be appropriate to avoid at least Integer allocation > and maybe enhance performance. > > Best regards, > Laurent Bourg?s > > PS: here is the patch as text: > > # This patch file was generated by NetBeans IDE > # It uses platform neutral UTF-8 encoding and \n newlines. > --- PlatformLogger.java (6767) > +++ PlatformLogger.java (6768) > @@ -468,31 +468,13 @@ > * java.util.logging.Logger object. > */ > static class JavaLogger extends LoggerProxy { > - /** Note: using Integer keys leads to a lot of new Integer > instances !! */ > - private static final Map levelObjects = new > HashMap<>(); > - /** fastest mapping to Level instances from PlatformLogger level > as integer */ > - private static final Object[] fastLevelObjects; > - > - > + private static final Map levelObjects = > + new HashMap<>(); > + > static { > if (LoggingSupport.isAvailable()) { > // initialize the map to Level objects > getLevelObjects(); > - > - // initialize the fastLevelObjects: > - fastLevelObjects = new Object[] { > - LoggingSupport.parseLevel(getLevelName(OFF)), // > 0 > - LoggingSupport.parseLevel(getLevelName(SEVERE)), // > 1 > - LoggingSupport.parseLevel(getLevelName(WARNING)), // > 2 > - LoggingSupport.parseLevel(getLevelName(INFO)), // > 3 > - LoggingSupport.parseLevel(getLevelName(CONFIG)), // > 4 > - LoggingSupport.parseLevel(getLevelName(FINE)), // > 5 > - LoggingSupport.parseLevel(getLevelName(FINER)), // > 6 > - LoggingSupport.parseLevel(getLevelName(FINEST)), // > 7 > - LoggingSupport.parseLevel(getLevelName(ALL)) // > 8 > - }; > - } else { > - fastLevelObjects = null; // check null > } > } > > @@ -515,7 +497,7 @@ > this.javaLogger = LoggingSupport.getLogger(name); > if (level != 0) { > // level has been updated and so set the Logger's level > - LoggingSupport.setLevel(javaLogger, getLevel(level)); > + LoggingSupport.setLevel(javaLogger, > levelObjects.get(level)); > } > } > > @@ -526,11 +508,11 @@ > * not be updated. > */ > void doLog(int level, String msg) { > - LoggingSupport.log(javaLogger, getLevel(level), msg); > + LoggingSupport.log(javaLogger, levelObjects.get(level), msg); > } > > void doLog(int level, String msg, Throwable t) { > - LoggingSupport.log(javaLogger, getLevel(level), msg, t); > + LoggingSupport.log(javaLogger, levelObjects.get(level), msg, > t); > } > > void doLog(int level, String msg, Object... params) { > @@ -544,12 +526,12 @@ > for (int i = 0; i< len; i++) { > sparams [i] = String.valueOf(params[i]); > } > - LoggingSupport.log(javaLogger, getLevel(level), msg, sparams); > + LoggingSupport.log(javaLogger, levelObjects.get(level), msg, > sparams); > } > > boolean isEnabled() { > Object level = LoggingSupport.getLevel(javaLogger); > - return level == null || level.equals(getLevel(OFF)) == false; > + return level == null || level.equals(levelObjects.get(OFF)) == > false; > } > > int getLevel() { > @@ -566,34 +548,12 @@ > > void setLevel(int newLevel) { > levelValue = newLevel; > - LoggingSupport.setLevel(javaLogger, getLevel(newLevel)); > + LoggingSupport.setLevel(javaLogger, > levelObjects.get(newLevel)); > } > > public boolean isLoggable(int level) { > - return LoggingSupport.isLoggable(javaLogger, getLevel(level)); > + return LoggingSupport.isLoggable(javaLogger, > levelObjects.get(level)); > } > - > - /** > - * Return the corresponding level object (fastest implementation) > - * @param level PlatformLogger level as primitive integer > - * @return Object (JUL Level instance) > - */ > - private static Object getLevel(final int level) { > - // higher occurences first (finest, fine, finer, info): > - switch (level) { > - case FINEST : return fastLevelObjects[7]; > - case FINE : return fastLevelObjects[5]; > - case FINER : return fastLevelObjects[6]; > - case INFO : return fastLevelObjects[3]; > - case CONFIG : return fastLevelObjects[4]; > - case WARNING : return fastLevelObjects[2]; > - case SEVERE : return fastLevelObjects[1]; > - case ALL : return fastLevelObjects[8]; > - case OFF : return fastLevelObjects[0]; > - default : return null; > - } > - } > - > } > > private static String getLevelName(int level) { From martinrb at google.com Tue Mar 19 18:37:26 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 19 Mar 2013 11:37:26 -0700 Subject: Please review: surrogate fiddle In-Reply-To: <51480152.5010102@oracle.com> References: <5147D0F8.3090101@oracle.com> <51480152.5010102@oracle.com> Message-ID: On Mon, Mar 18, 2013 at 11:10 PM, Masayoshi Okutsu < masayoshi.okutsu at oracle.com> wrote: > > For classes as important as important as StringBuilder, I think we > should go the extra mile to ensure best performance, > > > That was exactly the reason why I initially took the same approach. So, > I'd like to leave the decision to performance experts. > I, ummmm... am a "performance expert". How about, if I can ever measure any performance win in a micro-benchmark, we're allowed to keep the lower-level code? From martinrb at google.com Tue Mar 19 18:49:52 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 19 Mar 2013 11:49:52 -0700 Subject: Please review: surrogate fiddle In-Reply-To: References: <5147D0F8.3090101@oracle.com> <51480152.5010102@oracle.com> Message-ID: Masayoshi or Xueming, please file a bug for me: Title: Improve handling of char sequences containing surrogates Desc: Fix and optimize codePointAt, codePointBefore and similar methods Eval: A fine idea! From xueming.shen at oracle.com Tue Mar 19 18:58:01 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 19 Mar 2013 11:58:01 -0700 Subject: Please review: surrogate fiddle In-Reply-To: References: <5147D0F8.3090101@oracle.com> <51480152.5010102@oracle.com> Message-ID: <5148B539.4020508@oracle.com> On 03/19/2013 11:49 AM, Martin Buchholz wrote: > > Masayoshi or Xueming, please file a bug for me: > Title: Improve handling of char sequences containing surrogates > Desc: Fix and optimize codePointAt, codePointBefore and similar methods > Eval: A fine idea! JDK-8010316: Improve handling of char sequences containing surrogates From martinrb at google.com Tue Mar 19 19:18:59 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 19 Mar 2013 12:18:59 -0700 Subject: Please review: surrogate fiddle In-Reply-To: <5148B539.4020508@oracle.com> References: <5147D0F8.3090101@oracle.com> <51480152.5010102@oracle.com> <5148B539.4020508@oracle.com> Message-ID: Thanks! Webrev updated. On Tue, Mar 19, 2013 at 11:58 AM, Xueming Shen wrote: > ** > On 03/19/2013 11:49 AM, Martin Buchholz wrote: > > > Masayoshi or Xueming, please file a bug for me: > Title: Improve handling of char sequences containing surrogates > Desc: Fix and optimize codePointAt, codePointBefore and similar methods > Eval: A fine idea! > > JDK-8010316: Improve handling of char sequences containing surrogates > From martinrb at google.com Tue Mar 19 19:24:00 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 19 Mar 2013 12:24:00 -0700 Subject: Please review: surrogate fiddle In-Reply-To: References: <5147D0F8.3090101@oracle.com> <51480152.5010102@oracle.com> <5148B539.4020508@oracle.com> Message-ID: I couldn't resist fixing the two typos of ArrayIndexOutofBoundsException - // throws ArrayIndexOutofBoundsException if index out of bounds + // throws ArrayIndexOutOfBoundsException if index out of bounds From mark.reinhold at oracle.com Tue Mar 19 19:44:23 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 19 Mar 2013 12:44:23 -0700 (PDT) Subject: JEP 179: Document JDK API Support and Stability Message-ID: <20130319194423.8EFE86D7@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/179 - Mark From mark.reinhold at oracle.com Tue Mar 19 20:09:01 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 19 Mar 2013 16:09:01 -0400 Subject: @Supported design issues In-Reply-To: <5143C7F4.8080006@oracle.com> References: <51266B7C.3040804@oracle.com>, <20130315141249.582558@eggemoggin.niobe.net>, <5143C7F4.8080006@oracle.com> Message-ID: <20130319160901.529710@eggemoggin.niobe.net> 2013/3/15 17:16 -0400, joe.darcy at oracle.com: > On 03/15/2013 02:12 PM, mark.reinhold at oracle.com wrote: >> ... >> >> What I'm trying to understand is, for a JDK API that's @Supported(true) >> in one or more releases, what's the recommended protocol for removing >> it? Perhaps something like this? >> >> @Supported(true) >> @Supported(true) @Deprecated >> @Supported(false) >> >> >> (Time flows downward.) >> >> Or does @Supported(false) happen when @Deprecated is applied? >> >> Or will usage vary? > > The general threshold we've been using to apply @Deprecated is that a > API must be actively harmful rather than just ill-advised. However, a > few methods have been deprecated in Java SE 8 because they are slated > for removal in 9 as part of modularization. > > I would favor a shorter sequence of either > > @Supported(true) > @Supported(false) @Deprecated > > > or even just > > @Supported(true) > @Supported(false) > > > since using the API may not be harmful per se, other than risky in the > sense the API is going away in the future. Agreed -- that's the key distinction: "Harmful" != "going away". >>> ... >>> >>> Since types have a more concrete existence then packages, I regard the >>> jdk.Supported information on package-info files to have a higher mixture >>> of informative versus normative sentiment compared to the annotation on >>> types. >> >> If we're going to go to the trouble of defining an annotation for this, >> and then sprinkle that annotation throughout our code, shouldn't we give >> it as precise a meaning as possible? It'd be a shame for @Supported (or >> whatever it turns out to be) to have no more authoritative value than, >> say, the @since javadoc tag. > > The main point I was making here is that package-info information has a > less concrete existence than information about types, because, for > example, it is possible to configure a build so that multiple > package-info files exist for the same package (the jdk docs build gives > a warning about this situation for some XML-processing code). Ah, yes, there's that wrinkle. I still think, though, that we should strive to give these new annotations as precise a semantics as possible, and also use them as precisely as possible. >>> ... >>> >>> Since any jdk.Supported annotations applied to types are more localized >>> and more specific ("*this* type is or is not supported / stable / etc.") >>> it is both easier for JDK developers to made incremental changes to the >>> JDK code base and is it also easier for users of those types to see what >>> is going on since any inspection of the types can reveal the annotation >>> value. >> >> Agreed, but I was trying to understand how the annotation-based system >> would be harder to "cirvumvent", at either compile time or run time. > > It is harder to plead ignorance of the supported status of the API since > any inspection of it can reveal the annotation whereas a single change > in the javac command line can silence all ct.sym warnings. Okay. I took the word "cirvumvent" to mean that you had some additional automatic enforcement mechanism in mind. - Mark From joe.darcy at oracle.com Tue Mar 19 20:10:56 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 19 Mar 2013 20:10:56 +0000 Subject: hg: jdk8/tl/langtools: 8010179: Remove transitional target values from javac Message-ID: <20130319201101.A6E1248267@hg.openjdk.java.net> Changeset: a4913ea9bb62 Author: darcy Date: 2013-03-19 13:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a4913ea9bb62 8010179: Remove transitional target values from javac Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! test/tools/javac/ClassFileModifiers/MemberModifiers.java ! test/tools/javac/profiles/ProfileOptionTest.java From mandy.chung at oracle.com Tue Mar 19 20:14:41 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 19 Mar 2013 13:14:41 -0700 Subject: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com> References: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com> Message-ID: <5148C731.3050500@oracle.com> I do a partial review in particular to make sure the jdk and hotspot change are in sync. javaClasses.hpp - MN_CALLER_SENSITIVE and MN_SEARCH_SUPERCLASSES have the same value. Should they be different? 1057 MN_CALLER_SENSITIVE = 0x00100000, // @CallerSensitive annotation detected 1061 MN_SEARCH_SUPERCLASSES = 0x00100000, // walk super classes method.hpp - Is caller_sensitive set to true if @CallerSensitive annotation is present and must be loaded by null class loader? Does it only check annotations if the class of that method is defined by the null class loader? Per our offline discussion early, classes loaded by the extension class loader may also be caller-sensitive. If a method calls Reflection.getCallerClass but its class is defined by other class loader (non-null and not extension class loader), your fix will throw InternalError with the same error message even if that method is annotated with @CS. Is there a way to improve the error message so that we can differentiate this case (i.e. @CS is present but not supported)? jvm.cpp: have you considered adding a new entry point instead of having JVM_GetCallerClass to behave differently depending on the existence of sun.reflect.CallerSensitive class? There are pros and cons of both options. Having a new entry point is cleaner and enables the opportunity to remove JVM_GetCallerClass(int) in the future. I am fine with either approach but just to bring it up. Mandy On 3/14/13 8:31 PM, Christian Thalinger wrote: > [This is the HotSpot part of JEP 176] > > http://cr.openjdk.java.net/~twisti/7198429 > > 7198429: need checked categorization of caller-sensitive methods in the JDK > Reviewed-by: > > More information in JEP 176: > > http://openjdk.java.net/jeps/176 > > src/share/vm/ci/ciMethod.cpp > src/share/vm/ci/ciMethod.hpp > src/share/vm/classfile/classFileParser.cpp > src/share/vm/classfile/classFileParser.hpp > src/share/vm/classfile/javaClasses.hpp > src/share/vm/classfile/systemDictionary.hpp > src/share/vm/classfile/vmSymbols.hpp > src/share/vm/oops/method.cpp > src/share/vm/oops/method.hpp > src/share/vm/opto/library_call.cpp > src/share/vm/prims/jvm.cpp > src/share/vm/prims/methodHandles.cpp > src/share/vm/prims/unsafe.cpp > src/share/vm/runtime/vframe.cpp > src/share/vm/runtime/vframe.hpp > From mike.duigou at oracle.com Tue Mar 19 21:19:48 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 19 Mar 2013 14:19:48 -0700 Subject: Code review request: JDK-8008670 (partial java.util.stream implementation) In-Reply-To: References: <51267293.4060203@oracle.com> <513E52B5.5060105@oracle.com> <44E0A9DD-3C4B-472A-9988-B591E5417D7F@oracle.com> Message-ID: <5A7B9173-6AAB-4A0C-8FDE-F888BEF25301@oracle.com> On Mar 12 2013, at 06:51 , Paul Sandoz wrote: >> - should be replace with {@code} >> > > It is mostly consistent with the rest of the Map documentation. We should do a global replace in that case? We are incrementally updating the source with this change. Nobody is going out of their way to fix it but "while you're in the neighborhood. >> - ::computeIfAbsent()/computeIfPresent()/compute() - "key with which the specified value is to be associated" -> derived value. >> > > Perhaps the above three merit a separate discussion. Raise in a separate email thread? I had misunderstood that the Map changes were part of this review (no harm done). We can address this as part of the review of JDK-8010122 > http://hg.openjdk.java.net/lambda/lambda/jdk/rev/077efaf92c8c > > You know off any tests that can be reused? I started to look for ConcurrentMap tests but found not enough. We have a gap here. Mike From mandy.chung at oracle.com Tue Mar 19 21:51:31 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 19 Mar 2013 14:51:31 -0700 Subject: Review request: 8006104: Improve tests to test ".useParentHandlers" property set in the logging configuration Message-ID: <5148DDE3.7070406@oracle.com> Simple update of a logging test to include test cases for the ".useParentHandlers" property set in the logging configuration. Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8006104/webrev.00/ Thanks Mandy From jonathan.gibbons at oracle.com Tue Mar 19 22:13:41 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 19 Mar 2013 22:13:41 +0000 Subject: hg: jdk8/tl/langtools: 8010315: doclint errors in javac public API Message-ID: <20130319221347.ADC2648271@hg.openjdk.java.net> Changeset: 578eb3dd111d Author: jjg Date: 2013-03-19 15:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/578eb3dd111d 8010315: doclint errors in javac public API Reviewed-by: darcy ! make/build.xml ! src/share/classes/com/sun/source/util/DocTreeScanner.java ! src/share/classes/com/sun/source/util/JavacTask.java ! src/share/classes/com/sun/source/util/Plugin.java ! src/share/classes/javax/lang/model/AnnotatedConstruct.java ! src/share/classes/javax/lang/model/type/ExecutableType.java From mike.duigou at oracle.com Tue Mar 19 23:10:09 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 19 Mar 2013 23:10:09 +0000 Subject: hg: jdk8/tl/jdk: 8001642: Add Optional, OptionalDouble, OptionalInt, OptionalLong Message-ID: <20130319231031.7F46B48272@hg.openjdk.java.net> Changeset: 2241a2d34085 Author: mduigou Date: 2013-03-19 16:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2241a2d34085 8001642: Add Optional, OptionalDouble, OptionalInt, OptionalLong Reviewed-by: mduigou, darcy, alanb, jjb Contributed-by: Brian Goetz + src/share/classes/java/util/Optional.java + src/share/classes/java/util/OptionalDouble.java + src/share/classes/java/util/OptionalInt.java + src/share/classes/java/util/OptionalLong.java + test/java/util/Optional/Basic.java + test/java/util/Optional/BasicDouble.java + test/java/util/Optional/BasicInt.java + test/java/util/Optional/BasicLong.java From lana.steuck at oracle.com Tue Mar 19 23:20:15 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 19 Mar 2013 23:20:15 +0000 Subject: hg: jdk8/tl/hotspot: 40 new changesets Message-ID: <20130319232131.9284F48273@hg.openjdk.java.net> Changeset: 8196357e95b5 Author: amurillo Date: 2013-03-08 08:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8196357e95b5 8009688: new hotspot build - hs25-b23 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 255c0a4cb4eb Author: sla Date: 2013-03-05 08:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/255c0a4cb4eb 8009287: [parfait] Uninitialised variable in hotspot/agent/src/os/linux/ps_core.c Reviewed-by: dholmes, kvn, mikael, morris ! agent/src/os/linux/ps_core.c Changeset: 9058789475af Author: iklam Date: 2013-03-05 13:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9058789475af 7107135: Stack guard pages are no more protected after loading a shared library with executable stack Summary: Detect the execstack attribute of the loaded library and attempt to fix the stack guard using Safepoint op. Reviewed-by: dholmes, zgu Contributed-by: ioi.lam at oracle.com ! src/os/linux/vm/globals_linux.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp + test/runtime/7107135/Test.java + test/runtime/7107135/Test7107135.sh + test/runtime/7107135/TestMT.java + test/runtime/7107135/test.c Changeset: 6b803ba47588 Author: zgu Date: 2013-03-07 14:06 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6b803ba47588 8008257: NMT: assert(new_rec->is_allocation_record()) failed when running with shared memory option Summary: Corrected virtual memory recording and tagging code when large pages are used Reviewed-by: coleenp, ccheung ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp Changeset: 3efdfd6ddbf2 Author: coleenp Date: 2013-03-08 11:47 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3efdfd6ddbf2 8003553: NPG: metaspace objects should be zeroed in constructors Summary: Zero metadata in constructors, not in allocation (and some in constructors) Reviewed-by: jmasa, sspitsyn ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/memory/metablock.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/cpCache.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 252ad8d5f22b Author: dcubed Date: 2013-03-08 17:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/252ad8d5f22b Merge ! src/os/bsd/vm/os_bsd.cpp Changeset: 35ef86296a5d Author: dcubed Date: 2013-03-08 17:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/35ef86296a5d Merge ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: 5939f5953b45 Author: coleenp Date: 2013-03-13 09:10 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5939f5953b45 8009836: nsk/regression/b4222717 fails with empty stack trace Summary: Some zeroing was missed for bug 8003553, causing empty stack traces and Xcom crashes, add back zeroing to metablock Reviewed-by: dholmes, rbackman ! src/share/vm/memory/metablock.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/method.cpp Changeset: 96480359523a Author: coleenp Date: 2013-03-11 14:00 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/96480359523a 8008965: @Contended fails with classes having static fields Summary: Disable @Contended support for static fields Reviewed-by: coleenp, kvn Contributed-by: Aleksey Shipilev ! src/share/vm/classfile/classFileParser.cpp + test/runtime/8003985/Test8003985.java Changeset: d6320e955c89 Author: coleenp Date: 2013-03-13 13:47 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d6320e955c89 Merge Changeset: 0ede345ec7c9 Author: coleenp Date: 2013-03-13 15:15 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0ede345ec7c9 8009829: CDS: JDK JPRT test fails crash in Symbol::equals() Summary: -Xshare:dump was creating a Symbol in C_heap. There's an assert there that jdk jprt wasn't hitting because it was only done in product Reviewed-by: dholmes, hseigel, iklam ! src/share/vm/classfile/symbolTable.cpp Changeset: c8b31b461e1a Author: coleenp Date: 2013-03-13 17:34 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c8b31b461e1a 8003419: NPG: Clean up metadata created during class loading if failure Summary: Store metadata on ClassFileParser instance to be cleaned up by destructor. This enabled some refactoring of the enormous parseClassFile function. Reviewed-by: jmasa, acorn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: fad90b102190 Author: jprovino Date: 2013-03-06 13:38 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fad90b102190 8008310: Some adjustments needed to minimal VM warnings and errors for unsupported command line options Summary: Changes to arguments.cpp for warnings vs. errors. Changes for CDS arguments. Reviewed-by: coleenp, cjplummer ! make/excludeSrc.make ! src/share/vm/memory/filemap.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 47bc9800972c Author: jprovino Date: 2013-03-06 13:46 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/47bc9800972c 8006498: #if is wrong in the code. Summary: ASSERT and other symbols used incorrectly with #if are supposed to be defined or not. Reviewed-by: dholmes, mikael ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/frame_x86.hpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/code/compressedStream.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiTrace.hpp Changeset: 67342b960b47 Author: jprovino Date: 2013-03-06 13:50 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/67342b960b47 8008474: Add -Wundef to warning flags. Summary: Force use of undefined macros to be and error. Reviewed-by: dholmes, mikael ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/gcc.make ! make/solaris/makefiles/gcc.make Changeset: cb75b67f04fb Author: jprovino Date: 2013-03-08 12:35 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cb75b67f04fb Merge ! make/bsd/makefiles/gcc.make Changeset: 69ffa4ac9e53 Author: jprovino Date: 2013-03-12 00:02 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/69ffa4ac9e53 8009835: Only produce a warning when -Xshare:auto is explicitly requested Summary: The minimal JVM is printing a warning message for default settings when it should quitely ignore them. Reviewed-by: coleenp, dholmes ! src/share/vm/runtime/arguments.cpp Changeset: 9102c4111564 Author: jprovino Date: 2013-03-14 10:37 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9102c4111564 Merge Changeset: ed53b50794d7 Author: vladidan Date: 2013-03-14 12:49 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ed53b50794d7 Merge Changeset: 0094485b46c7 Author: roland Date: 2013-03-13 09:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0094485b46c7 8009761: Deoptimization on sparc doesn't set Llast_SP correctly in the interpreter frames it creates Summary: deoptimization doesn't set up callee frames so that they restore caller frames correctly. Reviewed-by: kvn ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vframeArray.hpp + test/compiler/8009761/Test8009761.java Changeset: 056ab43544a4 Author: neliasso Date: 2013-03-13 10:56 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/056ab43544a4 8009721: Make PhaseLive independent from regalloc Summary: Moved class definition of LRG_List from chaitin.hpp to live.hpp Reviewed-by: kvn, rbackman, roland Contributed-by: niclas.adlertz at oracle.com ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/live.hpp Changeset: 6d98efabf3ba Author: neliasso Date: 2013-03-13 13:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6d98efabf3ba Merge Changeset: b7c2c5b2572c Author: neliasso Date: 2013-02-13 10:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b7c2c5b2572c 8005772: Stubs report compile id -1 in phase events Summary: Use 0 to indicate id is NA, -1 for error or uninitalized Reviewed-by: kvn, twisti ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/compile.cpp Changeset: 71f13276159d Author: morris Date: 2013-03-14 07:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/71f13276159d 8008560: [parfait] Null pointer deference in hotspot/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp Summary: add null pointer check in signal handler Reviewed-by: kvn ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp Changeset: fba788946616 Author: morris Date: 2013-03-14 16:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fba788946616 Merge Changeset: 9def4075da6d Author: tamao Date: 2013-03-05 15:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9def4075da6d 8008079: G1: Add nextObject routine to CMBitMapRO and replace nextWord Summary: Update the task local finger to the start of the next object when marking aborts, in order to avoid the redundant scanning of all 0's when the marking task restarts, if otherwise updating to the next word. In addition, reuse the routine nextObject() in routine iterate(). Reviewed-by: johnc, ysr Contributed-by: tamao ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp Changeset: 209f8ba5020b Author: tamao Date: 2013-03-07 10:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/209f8ba5020b 8008368: Deprecate MaxGCMinorPauseMillis Summary: Deprecate MaxGCMinorPauseMillis and emit a warning if set by users Reviewed-by: brutisso, johnc Contributed-by: tamao ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: 1f3354851c91 Author: stefank Date: 2013-03-11 08:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1f3354851c91 Merge Changeset: 167812fe00bb Author: kevinw Date: 2013-03-11 12:56 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/167812fe00bb 8009723: CMS logs "concurrent mode failure" twice when using (disabling) -XX:-UseCMSCompactAtFullCollection Reviewed-by: jwilhelm, ehelin, brutisso ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: 71f619500f9b Author: kevinw Date: 2013-03-11 15:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/71f619500f9b Merge Changeset: 1c88b99a2b01 Author: mgerdin Date: 2013-03-12 09:42 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1c88b99a2b01 8009282: Assertion "assert(used_and_free == capacity_bytes) failed: Accounting is wrong" failed with -XX:+Verbose -XX:+TraceMetadataChunkAllocation Summary: Assertion is only valid when at a safepoint, adjust accordingly. Reviewed-by: stefank, jmasa, tamao ! src/share/vm/memory/metaspace.cpp Changeset: ca9580859cf4 Author: stefank Date: 2013-03-11 02:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ca9580859cf4 8004697: SIGSEGV on Solaris sparc with -XX:+UseNUMA Summary: Don't scan pages outside the given range. Reviewed-by: jwilhelm, jmasa ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp Changeset: 62609ffa2fc6 Author: tschatzl Date: 2013-03-12 15:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/62609ffa2fc6 8008684: CMS: concurrent phase start markers should always be printed Summary: Print the concurrent phase start markers for CMS when PrintGCDetails is enabled, not only if both PrintGCDetails and PrintGCTimeStamps are. Reviewed-by: mgerdin, jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: eac371996b44 Author: brutisso Date: 2013-03-12 08:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eac371996b44 8001049: VM crashes when running with large -Xms and not specifying ObjectAlignmentInBytes Summary: Take the initial heap size into account when checking the heap size for compressed oops Reviewed-by: jmasa, kvn, hseigel, ctornqvi ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: 993d878108d9 Author: brutisso Date: 2013-03-13 05:14 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/993d878108d9 Merge Changeset: 82657b6a8cc0 Author: jmasa Date: 2013-03-12 11:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/82657b6a8cc0 6976528: PS: assert(!limit_exceeded || softrefs_clear) failed: Should have been cleared Reviewed-by: johnc ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/memory/collectorPolicy.cpp Changeset: 15401203db6b Author: stefank Date: 2013-03-15 08:57 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/15401203db6b Merge ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/runtime/arguments.cpp Changeset: a10dc1469c3f Author: stefank Date: 2013-03-15 04:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a10dc1469c3f Merge Changeset: 0631ebcc45f0 Author: amurillo Date: 2013-03-15 11:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0631ebcc45f0 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 3db4ab0e12f4 Author: amurillo Date: 2013-03-15 11:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3db4ab0e12f4 Added tag hs25-b23 for changeset 0631ebcc45f0 ! .hgtags From jonathan.gibbons at oracle.com Wed Mar 20 00:04:52 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 20 Mar 2013 00:04:52 +0000 Subject: hg: jdk8/tl/langtools: 8010361: fix some langtools findbugs issues Message-ID: <20130320000457.EA5E048276@hg.openjdk.java.net> Changeset: a03c4a86ea2b Author: jjg Date: 2013-03-19 17:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a03c4a86ea2b 8010361: fix some langtools findbugs issues Reviewed-by: darcy ! src/share/classes/com/sun/tools/classfile/Code_attribute.java ! src/share/classes/com/sun/tools/classfile/Descriptor.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/javah/Util.java ! src/share/classes/com/sun/tools/javap/StackMapWriter.java ! src/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/share/classes/com/sun/tools/jdeps/PlatformClassPath.java ! src/share/classes/com/sun/tools/sjavac/Main.java ! src/share/classes/com/sun/tools/sjavac/comp/Dependencies.java From jonathan.gibbons at oracle.com Wed Mar 20 00:06:23 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 20 Mar 2013 00:06:23 +0000 Subject: hg: jdk8/tl/langtools: 8010333: Remove com.sun.tools.javac.Server Message-ID: <20130320000626.1358E48278@hg.openjdk.java.net> Changeset: 9cf17b7a5fe7 Author: jjg Date: 2013-03-19 17:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9cf17b7a5fe7 8010333: Remove com.sun.tools.javac.Server Reviewed-by: darcy - src/share/classes/com/sun/tools/javac/Server.java From john.r.rose at oracle.com Wed Mar 20 00:21:11 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 19 Mar 2013 17:21:11 -0700 Subject: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com> References: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com> Message-ID: On Mar 14, 2013, at 8:31 PM, Christian Thalinger wrote: > [This is the HotSpot part of JEP 176] > > http://cr.openjdk.java.net/~twisti/7198429 > > 7198429: need checked categorization of caller-sensitive methods in the JDK > Reviewed-by: Over all, great work on a tricky problem. I'd add a few asserts and tweak a couple of lines; see below. Reviewed as is or with suggested changes. ? John --- Method::is_ignored_by_security_stack_walk I would like to see reflect_invoke_cache go away some day. Would it be possible to strengthen the asserts to prove that it is an expensive alias for an intrinsic_id check? (I realize this is a question mainly for folks working on JVMTI.) --- JVM_GetCallerClass Suggest an assert for vfst.method() == NULL. Should not happen, and previous code would apparently have crashed already, but... (The corner case I'm thinking of is a compiled frame with nmethod::method returning null after nmethod::make_unloaded. Should not happen.) --- JVM_GetClassContext What do these lines do: + // Collect method holders + GrowableArray* klass_array = new GrowableArray(); It looks like a paste-o from another source base. --- LibraryCallKit::inline_native_Reflection_getCallerClass I believe this assertion, but I would prefer to see it checked more forcibly: + // NOTE: Start the loop at depth 1 because the current JVM state does + // not include the Reflection.getCallerClass() frame. Not sure there is a good way to do this. But, perhaps put the comment here: case 0: // ...comment... ShouldNotReachHere(); Also, if something goes wrong with caller sensitivity, we just get a "return false". Perhaps do a "caller_jvm=NULL;break" to branch to the pretty failure message? That makes it slightly easier to see what happened. The LogCompilation switch should leave a "paper trail". Actually, I see that LogCompilation doesn't mention failed intrinsic inlines. Rats. At least PrintInlining or PrintIntrinsics (diagnostic flags) will give us some leverage if we need to debug. --- JVM_RegisterUnsafeMethods That's an improvement. Thanks. (A nagging worry: How big are those static tables getting?) --- vframeStreamCommon::security_get_caller_frame This now does something odd if depth < 0. Suggest an assert. From christian.thalinger at oracle.com Wed Mar 20 00:29:58 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 19 Mar 2013 17:29:58 -0700 Subject: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: <5148C731.3050500@oracle.com> References: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com> <5148C731.3050500@oracle.com> Message-ID: <3CE4823C-BB63-44C4-B6E6-C8AC4D1E29E0@oracle.com> On Mar 19, 2013, at 1:14 PM, Mandy Chung wrote: > I do a partial review in particular to make sure the jdk and hotspot change are in sync. > > javaClasses.hpp - MN_CALLER_SENSITIVE and MN_SEARCH_SUPERCLASSES have the same value. Should they be different? > > 1057 MN_CALLER_SENSITIVE = 0x00100000, // @CallerSensitive annotation detected > 1061 MN_SEARCH_SUPERCLASSES = 0x00100000, // walk super classes They can have the same value because they are used for different things in different places. I talked to John about this and he said that the MN_SEARCH_* guys don't add much value and might be removed. > > > method.hpp - Is caller_sensitive set to true if @CallerSensitive annotation is present and must be loaded by null class loader? Does it only check annotations if the class of that method is defined by the null class loader? Per our offline discussion early, classes loaded by the extension class loader may also be caller-sensitive. Right. I forgot to add that code. Here is an incremental webrev: http://cr.openjdk.java.net/~twisti/7198429/edit/ And the full thing: http://cr.openjdk.java.net/~twisti/7198429/ Let me know if that works for you. > > If a method calls Reflection.getCallerClass but its class is defined by other class loader (non-null and not extension class loader), your fix will throw InternalError with the same error message even if that method is annotated with @CS. Is there a way to improve the error message so that we can differentiate this case (i.e. @CS is present but not supported)? Not easily. We set a flag on the method when parse the class. At that point we decide if the annotation is there or not. If the annotation is not allowed in parsed class because it's not loaded by the right class loader then it does not "exist". > > jvm.cpp: have you considered adding a new entry point instead of having JVM_GetCallerClass to behave differently depending on the existence of sun.reflect.CallerSensitive class? There are pros and cons of both options. Having a new entry point is cleaner and enables the opportunity to remove JVM_GetCallerClass(int) in the future. I am fine with either approach but just to bring it up. Yes. I talked to Vladimir about that yesterday. The better solution seems to be to leave the old entry point. If we add a new one that kind of adds a new method to the "official" VM interface. Other VM implementors would have to implement that one as well because the JDK then links to this new method. Thanks for the review! -- Chris > > Mandy > > > On 3/14/13 8:31 PM, Christian Thalinger wrote: >> [This is the HotSpot part of JEP 176] >> >> http://cr.openjdk.java.net/~twisti/7198429 >> >> 7198429: need checked categorization of caller-sensitive methods in the JDK >> Reviewed-by: >> >> More information in JEP 176: >> >> http://openjdk.java.net/jeps/176 >> >> src/share/vm/ci/ciMethod.cpp >> src/share/vm/ci/ciMethod.hpp >> src/share/vm/classfile/classFileParser.cpp >> src/share/vm/classfile/classFileParser.hpp >> src/share/vm/classfile/javaClasses.hpp >> src/share/vm/classfile/systemDictionary.hpp >> src/share/vm/classfile/vmSymbols.hpp >> src/share/vm/oops/method.cpp >> src/share/vm/oops/method.hpp >> src/share/vm/opto/library_call.cpp >> src/share/vm/prims/jvm.cpp >> src/share/vm/prims/methodHandles.cpp >> src/share/vm/prims/unsafe.cpp >> src/share/vm/runtime/vframe.cpp >> src/share/vm/runtime/vframe.hpp >> > From john.r.rose at oracle.com Wed Mar 20 00:39:32 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 19 Mar 2013 17:39:32 -0700 Subject: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: <5148C731.3050500@oracle.com> References: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com> <5148C731.3050500@oracle.com> Message-ID: On Mar 19, 2013, at 1:14 PM, Mandy Chung wrote: > javaClasses.hpp - MN_CALLER_SENSITIVE and MN_SEARCH_SUPERCLASSES have the same value. Should they be different? > > 1057 MN_CALLER_SENSITIVE = 0x00100000, // @CallerSensitive annotation detected > 1061 MN_SEARCH_SUPERCLASSES = 0x00100000, // walk super classes That's OK; they are used with different arguments, as the nearby comments point out. > method.hpp - Is caller_sensitive set to true if @CallerSensitive annotation is present and must be loaded by null class loader? Does it only check annotations if the class of that method is defined by the null class loader? Per our offline discussion early, classes loaded by the extension class loader may also be caller-sensitive. Oops, that needs fixing. For simplicity, I suggest you adjust the boolean 'privileged' that controls the ad hoc category of code that benefits from the annotation parsing. The important property of such code is that it is statically configured with the JVM, not dynamically loaded. > If a method calls Reflection.getCallerClass but its class is defined by other class loader (non-null and not extension class loader), your fix will throw InternalError with the same error message even if that method is annotated with @CS. Is there a way to improve the error message so that we can differentiate this case (i.e. @CS is present but not supported)? Maybe not, if it would involve reparsing the annotations. The error message can mention that the offending method is off the BCP so that even if it _were_ annotated the annotation would not count. We don't need a very user-friendly message here, as long as it points out that there is an offending off-label use of a JVM primitive. Nobody calls JVM_GetCallerClass by accident, and even if an end user is the unlucky discoverer, if the JVM message says "illegal internal method call" or some such, the bug should be clear enough. > jvm.cpp: have you considered adding a new entry point instead of having JVM_GetCallerClass to behave differently depending on the existence of sun.reflect.CallerSensitive class? There are pros and cons of both options. Having a new entry point is cleaner and enables the opportunity to remove JVM_GetCallerClass(int) in the future. I am fine with either approach but just to bring it up. Good point. I'm fine with either option. ? John From john.r.rose at oracle.com Wed Mar 20 00:42:17 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 19 Mar 2013 17:42:17 -0700 Subject: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: <3CE4823C-BB63-44C4-B6E6-C8AC4D1E29E0@oracle.com> References: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com> <5148C731.3050500@oracle.com> <3CE4823C-BB63-44C4-B6E6-C8AC4D1E29E0@oracle.com> Message-ID: On Mar 19, 2013, at 5:29 PM, Christian Thalinger wrote: > Right. I forgot to add that code. Here is an incremental webrev: > > http://cr.openjdk.java.net/~twisti/7198429/edit/ > > And the full thing: > > http://cr.openjdk.java.net/~twisti/7198429/ > > Let me know if that works for you. Good for me. ? John From christian.thalinger at oracle.com Wed Mar 20 01:02:53 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 19 Mar 2013 18:02:53 -0700 Subject: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: References: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com> Message-ID: <7D0554D4-7E1E-4DD0-907A-8F7AF17B9928@oracle.com> On Mar 19, 2013, at 5:21 PM, John Rose wrote: > On Mar 14, 2013, at 8:31 PM, Christian Thalinger wrote: > >> [This is the HotSpot part of JEP 176] >> >> http://cr.openjdk.java.net/~twisti/7198429 >> >> 7198429: need checked categorization of caller-sensitive methods in the JDK >> Reviewed-by: > > > Over all, great work on a tricky problem. I'd add a few asserts and tweak a couple of lines; see below. Reviewed as is or with suggested changes. ? John > > --- Method::is_ignored_by_security_stack_walk > I would like to see reflect_invoke_cache go away some day. Would it be possible to strengthen the asserts to prove that it is an expensive alias for an intrinsic_id check? (I realize this is a question mainly for folks working on JVMTI.) That's what I tried to do: if the intrinsic_id == _invoke it also must be the same method in reflect_invoke_cache. More than that would mean to enhance ActiveMethodOopsCache because you can't ask for methods in the cache. > > --- JVM_GetCallerClass > Suggest an assert for vfst.method() == NULL. Should not happen, and previous code would apparently have crashed already, but... > > (The corner case I'm thinking of is a compiled frame with nmethod::method returning null after nmethod::make_unloaded. Should not happen.) Sure, I can add that assert but there is other code in jvm.cpp that relies on the fact that vfst.method() is non-null. We should add asserts in all that places but that's for another RFE. > > --- JVM_GetClassContext > What do these lines do: > + // Collect method holders > + GrowableArray* klass_array = new GrowableArray(); > > It looks like a paste-o from another source base. Left over. I filed an RFE for that improvement: JDK-8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink > > --- LibraryCallKit::inline_native_Reflection_getCallerClass > > I believe this assertion, but I would prefer to see it checked more forcibly: > + // NOTE: Start the loop at depth 1 because the current JVM state does > + // not include the Reflection.getCallerClass() frame. > > Not sure there is a good way to do this. But, perhaps put the comment here: > case 0: > // ...comment... > ShouldNotReachHere(); How about: case 0: fatal("current JVM state does not include the Reflection.getCallerClass() frame"); break; > > Also, if something goes wrong with caller sensitivity, we just get a "return false". Perhaps do a "caller_jvm=NULL;break" to branch to the pretty failure message? That makes it slightly easier to see what happened. It seems easier to add printing code to the case statement: case 1: // Frame 0 and 1 must be caller sensitive (see JVM_GetCallerClass). if (!m->caller_sensitive()) { #ifndef PRODUCT if ((PrintIntrinsics || PrintInlining || PrintOptoInlining) && Verbose) { tty->print_cr(" Bailing out: CallerSensitive annotation expected at frame %d", n); } #endif return false; // bail-out; let JVM_GetCallerClass do the work } break; > > The LogCompilation switch should leave a "paper trail". Actually, I see that LogCompilation doesn't mention failed intrinsic inlines. Rats. At least PrintInlining or PrintIntrinsics (diagnostic flags) will give us some leverage if we need to debug. > > --- JVM_RegisterUnsafeMethods > That's an improvement. Thanks. > > (A nagging worry: How big are those static tables getting?) We could remove some very old ones like 1.4.0 and 1.4.1. This time, next time? > > --- vframeStreamCommon::security_get_caller_frame > This now does something odd if depth < 0. Suggest an assert. The behavior with depth < 0 in the current code is even worse. An assert is a good idea. As discussed I want to remove that method in the future because its uses are dubious. -- Chris From mandy.chung at oracle.com Wed Mar 20 01:02:16 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 19 Mar 2013 18:02:16 -0700 Subject: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: <3CE4823C-BB63-44C4-B6E6-C8AC4D1E29E0@oracle.com> References: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com> <5148C731.3050500@oracle.com> <3CE4823C-BB63-44C4-B6E6-C8AC4D1E29E0@oracle.com> Message-ID: <51490A98.7080003@oracle.com> On 3/19/2013 5:29 PM, Christian Thalinger wrote: > On Mar 19, 2013, at 1:14 PM, Mandy Chung wrote: > >> I do a partial review in particular to make sure the jdk and hotspot change are in sync. >> >> javaClasses.hpp - MN_CALLER_SENSITIVE and MN_SEARCH_SUPERCLASSES have the same value. Should they be different? >> >> 1057 MN_CALLER_SENSITIVE = 0x00100000, // @CallerSensitive annotation detected >> 1061 MN_SEARCH_SUPERCLASSES = 0x00100000, // walk super classes > They can have the same value because they are used for different things in different places. I talked to John about this and he said that the MN_SEARCH_* guys don't add much value and might be removed. Thanks. That's fine. >> >> method.hpp - Is caller_sensitive set to true if @CallerSensitive annotation is present and must be loaded by null class loader? Does it only check annotations if the class of that method is defined by the null class loader? Per our offline discussion early, classes loaded by the extension class loader may also be caller-sensitive. > Right. I forgot to add that code. Here is an incremental webrev: > > http://cr.openjdk.java.net/~twisti/7198429/edit/ > > And the full thing: > > http://cr.openjdk.java.net/~twisti/7198429/ > > Let me know if that works for you. I'll take your patch and let you know. >> If a method calls Reflection.getCallerClass but its class is defined by other class loader (non-null and not extension class loader), your fix will throw InternalError with the same error message even if that method is annotated with @CS. Is there a way to improve the error message so that we can differentiate this case (i.e. @CS is present but not supported)? > Not easily. We set a flag on the method when parse the class. At that point we decide if the annotation is there or not. If the annotation is not allowed in parsed class because it's not loaded by the right class loader then it does not "exist". 701 THROW_MSG_NULL(vmSymbols::java_lang_InternalError(), err_msg("CallerSensitive annotation expected at frame %d", n)); Perhaps it could check the class loader of the class of the method or print out additional info? It should be rare to run into this error but it would greatly help diagnosing the problem if @CS method loaded by unexpected class loader. >> jvm.cpp: have you considered adding a new entry point instead of having JVM_GetCallerClass to behave differently depending on the existence of sun.reflect.CallerSensitive class? There are pros and cons of both options. Having a new entry point is cleaner and enables the opportunity to remove JVM_GetCallerClass(int) in the future. I am fine with either approach but just to bring it up. > Yes. I talked to Vladimir about that yesterday. The better solution seems to be to leave the old entry point. If we add a new one that kind of adds a new method to the "official" VM interface. Other VM implementors would have to implement that one as well because the JDK then links to this new method. > Yup, that's one of the cons of adding a new entry point. Other VM implementation may need to support JVM_GetCallerClass(-1) to run on our JDK library implementation in either approach. Good and keep the code entry point. I'll send out the jdk change for code review. Mandy From joe.darcy at oracle.com Wed Mar 20 01:32:34 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Tue, 19 Mar 2013 18:32:34 -0700 Subject: @Supported design issues In-Reply-To: <5142055C.3060408@oracle.com> References: <51266B7C.3040804@oracle.com>, <5126D516.1040005@oracle.com>, , <5127C4D4.5090800@oracle.com>, <20130222150427.1712@eggemoggin.niobe.net> <51293038.7090503@oracle.com> <5142055C.3060408@oracle.com> Message-ID: <514911B2.30504@oracle.com> On 3/14/2013 10:14 AM, Joe Darcy wrote: > FYI, I've submitted a JEP reviewed by Alan Bateman on "Capturing > support and stability information about JDK classes in source and > class files." > Following up in the same thread, the JEP for this work is now available for your reading pleasure at: JEP 179: Document JDK API Support and Stability http://openjdk.java.net/jeps/179 -Joe From jonathan.gibbons at oracle.com Wed Mar 20 02:17:21 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 20 Mar 2013 02:17:21 +0000 Subject: hg: jdk8/tl/langtools: 8010317: DocLint incorrectly reports some 

 tags as empty
Message-ID: <20130320021726.56BFA4827E@hg.openjdk.java.net>

Changeset: 74d7f9bcac93
Author:    jjg
Date:      2013-03-19 19:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/74d7f9bcac93

8010317: DocLint incorrectly reports some 
 tags as empty
Reviewed-by: darcy

! src/share/classes/com/sun/tools/doclint/Checker.java
+ test/tools/doclint/EmptyPreTest.java



From mike.duigou at oracle.com  Wed Mar 20 05:11:03 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 19 Mar 2013 22:11:03 -0700
Subject: hg: jdk8/tl/jdk: 8001642: Add Optional, OptionalDouble,
	OptionalInt, OptionalLong
In-Reply-To: 
References: <20130319231031.7F46B48272@hg.openjdk.java.net>
	
Message-ID: 



On Mar 19, 2013, at 9:43 PM, Rob Leland  wrote:

> Has the optional classes been verified to serialize/deserialize correctly? I noticed it tries to use the null object pattern with the use of EMPTY private instance. When I have implemented the NULL pattern I have used a private subclass of the object as opposed to an instance variable to insure it unmarshalls correctly with a simple override of the default desearization to insure this.
> 
They are not tagged as Serializable. Optionals are intended to be transitory. A readResolve to re-associate with the EMPTY instance would be important if they were serializable.
> I also wonder why a marker interface wasn't used or something more substantial at least for methods like isPresent().
> 
I am not sure what you are looking for in this question.
> Also why does the static factory initialization parameters use primatives as opposed to objects?
> 
The OptionalInt etc are intended to be Optional counterparts to the boxed types. If you prefer Optional of the boxed types you can use the reference Optional.
> If objects were used then there would be the oppertunity to use a abstract base class, which has the potential to move the use of isPresent() strictly  into the base class.
> 
> Finally, are these utilities critical to some other part JDK 8 that they were pushed out now as opposed to JDK 9?
> 
They are currently planned for use by the lambda streams libraries. See http://openjdk.java.net/projects/lambda/ and http://jdk8.java.net/lambda/ for more info and an implementation.

Mike
> On Mar 19, 2013 7:18 PM,  wrote:
> Changeset: 2241a2d34085
> Author:    mduigou
> Date:      2013-03-19 16:05 -0700
> URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2241a2d34085
> 
> 8001642: Add Optional, OptionalDouble, OptionalInt, OptionalLong
> Reviewed-by: mduigou, darcy, alanb, jjb
> Contributed-by: Brian Goetz 
> 
> + src/share/classes/java/util/Optional.java
> + src/share/classes/java/util/OptionalDouble.java
> + src/share/classes/java/util/OptionalInt.java
> + src/share/classes/java/util/OptionalLong.java
> + test/java/util/Optional/Basic.java
> + test/java/util/Optional/BasicDouble.java
> + test/java/util/Optional/BasicInt.java
> + test/java/util/Optional/BasicLong.java
> 



From alexey.utkin at oracle.com  Wed Mar 20 09:29:53 2013
From: alexey.utkin at oracle.com (alexey.utkin at oracle.com)
Date: Wed, 20 Mar 2013 09:29:53 +0000
Subject: hg: jdk8/tl/jdk: 8006193: (process) Clean-up
	java.lang.ProcessImpl.finalize, does not need to be public
Message-ID: <20130320093007.2E72848291@hg.openjdk.java.net>

Changeset: fb23896a01f5
Author:    uta
Date:      2013-03-20 13:21 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fb23896a01f5

8006193: (process) Clean-up java.lang.ProcessImpl.finalize, does not need to be public
Reviewed-by: alanb

! src/windows/classes/java/lang/ProcessImpl.java



From peter.levart at gmail.com  Wed Mar 20 09:33:17 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 20 Mar 2013 10:33:17 +0100
Subject: RFR (M): 7198429: need checked categorization of caller-sensitive
	methods in the JDK
In-Reply-To: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com>
References: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com>
Message-ID: <5149825D.1040608@gmail.com>

Hi,

If I understand correctly, sun.reflect.Reflection.getCallerClass(int) 
will not be usable by non-system code any more. I know it's not a public 
API, but it's useful in some situations (not security-related) and 
there's no public API for that functionality.

Is there a reason to not "unofficially" support also classes with @CS 
annotated methods and which are not loaded by bootstrap or extension 
class-loader ?

Regards, Peter

On 03/15/2013 04:31 AM, Christian Thalinger wrote:
> [This is the HotSpot part of JEP 176]
>
> http://cr.openjdk.java.net/~twisti/7198429
>
> 7198429: need checked categorization of caller-sensitive methods in the JDK
> Reviewed-by:
>
> More information in JEP 176:
>
> http://openjdk.java.net/jeps/176
>
> src/share/vm/ci/ciMethod.cpp
> src/share/vm/ci/ciMethod.hpp
> src/share/vm/classfile/classFileParser.cpp
> src/share/vm/classfile/classFileParser.hpp
> src/share/vm/classfile/javaClasses.hpp
> src/share/vm/classfile/systemDictionary.hpp
> src/share/vm/classfile/vmSymbols.hpp
> src/share/vm/oops/method.cpp
> src/share/vm/oops/method.hpp
> src/share/vm/opto/library_call.cpp
> src/share/vm/prims/jvm.cpp
> src/share/vm/prims/methodHandles.cpp
> src/share/vm/prims/unsafe.cpp
> src/share/vm/runtime/vframe.cpp
> src/share/vm/runtime/vframe.hpp
>



From Alan.Bateman at oracle.com  Wed Mar 20 12:30:55 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 20 Mar 2013 12:30:55 +0000
Subject: PlatformLogger: isLoggable performance / waste due to
	HashMap leads to Integer allocations (boxing)
In-Reply-To: 
References: 
Message-ID: <5149ABFF.2090007@oracle.com>

On 19/03/2013 12:19, Laurent Bourg?s wrote:
> Dear all,
>
> I run recently netbeans profiler on my swing application (Aspro2:
> http://www.jmmc.fr/aspro) under linux x64 platform and figured out a
> performance and waste issue related to PlatformLogger.
>
> Actually, the JavaLogger implementation uses a Map
> levelObjects to store mapping between PlatformLogger's levels (int) and JUL
> Level instances.
>
> However, the isLoggable(int level) method is highly used by awt project and
> other JDK projects and it leads to many Integer allocations as autoboxing
> converts the level as int to an Integer instance used by the Map.get() call.
>
It's good to have identified this issue and I agree with Mandy that it 
should be fixed.

Have you read the "How to contribute" page [1]? I don't see you on the 
OCA list and just wanted to check.

-Alan

[1] http://openjdk.java.net/contribute/


From bourges.laurent at gmail.com  Wed Mar 20 12:45:41 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Wed, 20 Mar 2013 13:45:41 +0100
Subject: PlatformLogger: isLoggable performance / waste due to
	HashMap leads to Integer allocations (boxing)
In-Reply-To: <5148A334.6060207@oracle.com>
References: 
	<5148A334.6060207@oracle.com>
Message-ID: 

Hi mandy,

Do you want me to propose an improved patch to remove the former Map and
fix the getLevel() method ? or you prefer fix on your own ?

Is it better to discuss the fix on the bug database (still not visible) ?

Laurent

2013/3/19 Mandy Chung 

>  Hi Laurent,
>
> Thanks for the contribution.  I agree that the map can be replaced with a
> direct mapping from a int value to Level object and avoid the autoboxing
> conversion.
>
> I have filed a bug to track this and target this for JDK8:
>   http://bugs.sun.com/bugdatabase/view_bug.do?bug_id= 8010309
>
> Thanks
> Mandy
>
>
> On 3/19/13 5:19 AM, Laurent Bourg?s wrote:
>
> Dear all,
>
> I run recently netbeans profiler on my swing application (Aspro2:http://www.jmmc.fr/aspro
> ) under linux x64 platform and figured out a
> performance and waste issue related to PlatformLogger.
>
> Actually, the JavaLogger implementation uses a Map
> levelObjects to store mapping between PlatformLogger's levels (int) and JUL
> Level instances.
>
> However, the isLoggable(int level) method is highly used by awt project and
> other JDK projects and it leads to many Integer allocations as autoboxing
> converts the level as int to an Integer instance used by the Map.get() call.
>
>     /**
>      * JavaLogger forwards all the calls to its corresponding
>      * java.util.logging.Logger object.
>      */
>     static class JavaLogger extends LoggerProxy {
>         private static final* Map* levelObjects = new
> HashMap<>();
> ...
>         public boolean isLoggable(*int level*) {
>             return LoggingSupport.isLoggable(javaLogger, *
> levelObjects.get(level)*);
>         }
>     }
>
> I wrote a simple test to illustrate that performance / waste problem:
> PlatformLoggerTest that simply performs 1 million DISABLED log statements:
>             if (log.isLoggable(PlatformLogger.FINEST)) {
>                 log.finest("test PlatformLogger.FINEST");
>             }
>
> As you can see in screenshots:
> - 5 million Integer instances are allocated
> - Integer.valueOf(int) is called 5 million times (autoboxing)
> - HashMap.get() represents 30% of the test time
> - patched PlatformLogger is 3x times faster
> [jvm options: -Xms8m -Xmx8m -verbose:gc]
>
> I suggest you to use an alternative way to map PlatformLogger's levels
> (int) and JUL Level instances to fix that performance / memory issue: I
> added the getLevel(int level) method that performs a switch case to return
> the corresponding Level object (quick and dirty solution).
>
> I advocate this is not a very clean solution but I prefer efficiency here:
> any better solution may be appropriate to avoid at least Integer allocation
> and maybe enhance performance.
>
> Best regards,
> Laurent Bourg?s
>
> PS: here is the patch as text:
>
> # This patch file was generated by NetBeans IDE
> # It uses platform neutral UTF-8 encoding and \n newlines.
> --- PlatformLogger.java (6767)
> +++ PlatformLogger.java (6768)
> @@ -468,31 +468,13 @@
>       * java.util.logging.Logger object.
>       */
>      static class JavaLogger extends LoggerProxy {
> -        /** Note: using Integer keys leads to a lot of new Integer
> instances !! */
> -        private static final Map levelObjects = new
> HashMap<>();
> -        /** fastest mapping to Level instances from PlatformLogger level
> as integer */
> -        private static final Object[] fastLevelObjects;
> -
> -
> +        private static final Map levelObjects =
> +            new HashMap<>();
> +
>          static {
>              if (LoggingSupport.isAvailable()) {
>                  // initialize the map to Level objects
>                  getLevelObjects();
> -
> -                // initialize the fastLevelObjects:
> -                fastLevelObjects = new Object[] {
> -                    LoggingSupport.parseLevel(getLevelName(OFF)),       //
> 0
> -                    LoggingSupport.parseLevel(getLevelName(SEVERE)),    //
> 1
> -                    LoggingSupport.parseLevel(getLevelName(WARNING)),   //
> 2
> -                    LoggingSupport.parseLevel(getLevelName(INFO)),      //
> 3
> -                    LoggingSupport.parseLevel(getLevelName(CONFIG)),    //
> 4
> -                    LoggingSupport.parseLevel(getLevelName(FINE)),      //
> 5
> -                    LoggingSupport.parseLevel(getLevelName(FINER)),     //
> 6
> -                    LoggingSupport.parseLevel(getLevelName(FINEST)),    //
> 7
> -                    LoggingSupport.parseLevel(getLevelName(ALL))        //
> 8
> -                };
> -            } else {
> -                fastLevelObjects = null; // check null
>              }
>          }
>
> @@ -515,7 +497,7 @@
>              this.javaLogger = LoggingSupport.getLogger(name);
>              if (level != 0) {
>                  // level has been updated and so set the Logger's level
> -                LoggingSupport.setLevel(javaLogger, getLevel(level));
> +                LoggingSupport.setLevel(javaLogger,
> levelObjects.get(level));
>              }
>          }
>
> @@ -526,11 +508,11 @@
>          * not be updated.
>          */
>          void doLog(int level, String msg) {
> -            LoggingSupport.log(javaLogger, getLevel(level), msg);
> +            LoggingSupport.log(javaLogger, levelObjects.get(level), msg);
>          }
>
>          void doLog(int level, String msg, Throwable t) {
> -            LoggingSupport.log(javaLogger, getLevel(level), msg, t);
> +            LoggingSupport.log(javaLogger, levelObjects.get(level), msg,
> t);
>          }
>
>          void doLog(int level, String msg, Object... params) {
> @@ -544,12 +526,12 @@
>              for (int i = 0; i < len; i++) {
>                  sparams [i] = String.valueOf(params[i]);
>              }
> -            LoggingSupport.log(javaLogger, getLevel(level), msg, sparams);
> +            LoggingSupport.log(javaLogger, levelObjects.get(level), msg,
> sparams);
>          }
>
>          boolean isEnabled() {
>              Object level = LoggingSupport.getLevel(javaLogger);
> -            return level == null || level.equals(getLevel(OFF)) == false;
> +            return level == null || level.equals(levelObjects.get(OFF)) ==
> false;
>          }
>
>          int getLevel() {
> @@ -566,34 +548,12 @@
>
>          void setLevel(int newLevel) {
>              levelValue = newLevel;
> -            LoggingSupport.setLevel(javaLogger, getLevel(newLevel));
> +            LoggingSupport.setLevel(javaLogger,
> levelObjects.get(newLevel));
>          }
>
>          public boolean isLoggable(int level) {
> -            return LoggingSupport.isLoggable(javaLogger, getLevel(level));
> +            return LoggingSupport.isLoggable(javaLogger,
> levelObjects.get(level));
>          }
> -
> -        /**
> -         * Return the corresponding level object (fastest implementation)
> -         * @param level PlatformLogger level as primitive integer
> -         * @return Object (JUL Level instance)
> -         */
> -        private static Object getLevel(final int level) {
> -            // higher occurences first (finest, fine, finer, info):
> -            switch (level) {
> -                case FINEST  : return fastLevelObjects[7];
> -                case FINE    : return fastLevelObjects[5];
> -                case FINER   : return fastLevelObjects[6];
> -                case INFO    : return fastLevelObjects[3];
> -                case CONFIG  : return fastLevelObjects[4];
> -                case WARNING : return fastLevelObjects[2];
> -                case SEVERE  : return fastLevelObjects[1];
> -                case ALL     : return fastLevelObjects[8];
> -                case OFF     : return fastLevelObjects[0];
> -                default      : return null;
> -            }
> -        }
> -
>      }
>
>      private static String getLevelName(int level) {
>
>
>


From Ulf.Zibis at CoSoCo.de  Wed Mar 20 14:09:18 2013
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Wed, 20 Mar 2013 15:09:18 +0100
Subject: Please review: surrogate fiddle
In-Reply-To: 
References: 
	
	
	<5147D0F8.3090101@oracle.com>
	
	<51480152.5010102@oracle.com>
	
	
	<5148B539.4020508@oracle.com>
	
Message-ID: <5149C30E.1080405@CoSoCo.de>

Hi Martin,

nice to see you again on board.

Am 19.03.2013 20:18, schrieb Martin Buchholz:
> Thanks!  Webrev updated.

Character:
Maybe I'm blind, is there any semantical difference between
         char c1 = seq.charAt(index++);
         if (isHighSurrogate(c1)) {
             if (index < seq.length()) {
and
         char c1 = seq.charAt(index);
         if (isHighSurrogate(c1) && ++index < seq.length()) {
, or is it just for beautifying the code?

AbstractStringBuilder:
Instead
  270     public int codePointBefore(int index) {
  271         int i = index - 1;
  272         if ((i < 0) || (i >= count)) {
  273             throw new StringIndexOutOfBoundsException(index);
  274         }
I suggest
  270     public int codePointBefore(int index) {
  271         if ((--index < 0) || (index >= count)) {
  272             throw new StringIndexOutOfBoundsException(index);
  273         }
, because if e.g. the initial value of index is 0, then -1 reflects the out-of-bound condition, but 
not the initial 0 to report in the StringIndexOutOfBoundsException.
(Hopefully the following redundant i < 0 bounds check from value[i] becomes elimited by JIT.)

If there is some register pressure, you could avoid potential register swapping for temp, temp2, 
hasSurrogate, j and n - j if you would reorder following lines to:
1390             char temp = value[j];
1391             char temp2 = value[j] = value[n - j];
1397             value[n - j] = temp;
1392             if (!hasSurrogate) {
1393                 hasSurrogate = (Character.isSurrogate(temp) ||
1394                                 Character.isSurrogate(temp2));
1395             }
(Nomination for "performance expert II" ?)

> I, ummmm... am a "performance expert".
>
> How about, if I can ever measure any performance win in a micro-benchmark,
> we're allowed to keep the lower-level code?

Yes I remember ;-)
As IMHO better alternative you could proof the JIT result by hsdis.


I think, you independently should test
     static int codePointAtImpl(char[] a, int index, int limit) {...}
to don't read out-of-bounds trailing surrogate.
... and you additionally should provide a test for
     static int codePointBeforeImpl(char[] a, int index, int start) {...}
to don't read out-of-bounds precursory surrogate.


-Ulf



From Alan.Bateman at oracle.com  Wed Mar 20 14:55:57 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 20 Mar 2013 14:55:57 +0000
Subject: Review request: 8006104: Improve tests to test
	".useParentHandlers" property set in the logging configuration
In-Reply-To: <5148DDE3.7070406@oracle.com>
References: <5148DDE3.7070406@oracle.com>
Message-ID: <5149CDFD.8010802@oracle.com>

On 19/03/2013 21:51, Mandy Chung wrote:
> Simple update of a logging test to include test cases for the 
> ".useParentHandlers" property set in the logging configuration.
>
> Webrev at:
>    http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8006104/webrev.00/
It's good to expand the test coverage, this looks okay to me.

-Alan


From alexander.zuev at oracle.com  Wed Mar 20 15:00:53 2013
From: alexander.zuev at oracle.com (Alexander Zuev)
Date: Wed, 20 Mar 2013 19:00:53 +0400
Subject: Please review: surrogate fiddle
In-Reply-To: <5149C30E.1080405@CoSoCo.de>
References: 
	
	
	<5147D0F8.3090101@oracle.com>
	
	<51480152.5010102@oracle.com>
	
	
	<5148B539.4020508@oracle.com>
	
	<5149C30E.1080405@CoSoCo.de>
Message-ID: <5149CF25.1000308@oracle.com>

Hi Ulf,

please see my comments inline.

On 3/20/13 18:09, Ulf Zibis wrote:
> Hi Martin,
>
> nice to see you again on board.
>
> Am 19.03.2013 20:18, schrieb Martin Buchholz:
>> Thanks!  Webrev updated.
>
> Character:
> Maybe I'm blind, is there any semantical difference between
>         char c1 = seq.charAt(index++);
>         if (isHighSurrogate(c1)) {
>             if (index < seq.length()) {
> and
>         char c1 = seq.charAt(index);
>         if (isHighSurrogate(c1) && ++index < seq.length()) {
> , or is it just for beautifying the code?
The only real difference i see is that in case of isHighSurrogate(c1) == 
false we saving one increment instruction.
May be a real deal for performance junkie :)
>
> AbstractStringBuilder:
> Instead
>  270     public int codePointBefore(int index) {
>  271         int i = index - 1;
>  272         if ((i < 0) || (i >= count)) {
>  273             throw new StringIndexOutOfBoundsException(index);
>  274         }
> I suggest
>  270     public int codePointBefore(int index) {
>  271         if ((--index < 0) || (index >= count)) {
>  272             throw new StringIndexOutOfBoundsException(index);
>  273         }
> , because if e.g. the initial value of index is 0, then -1 reflects 
> the out-of-bound condition, but not the initial 0 to report in the 
> StringIndexOutOfBoundsException.
OTOH in case of upper index out of bounds with your code we will report 
exception reporting number laying within the allowed range which may be 
confusing.

Just my $.02

With best regards,
Alex



From john.zavgren at oracle.com  Wed Mar 20 15:22:33 2013
From: john.zavgren at oracle.com (John Zavgren)
Date: Wed, 20 Mar 2013 08:22:33 -0700 (PDT)
Subject: RFR-8008118
Message-ID: <0520220f-b796-48be-b74a-202b81f2d557@default>

Greetings:

Please consider the following fix for a minor memory issue that I found in the file: src/solaris/native/java/lang/UNIXProcess_md.c.

http://cr.openjdk.java.net/~jzavgren/8008118/webrev.01/

Thanks!
John Zavgren


From john.zavgren at oracle.com  Wed Mar 20 15:27:23 2013
From: john.zavgren at oracle.com (John Zavgren)
Date: Wed, 20 Mar 2013 08:27:23 -0700 (PDT)
Subject: RFR JDK-8003245
Message-ID: <4d13ecf0-ed5d-4afd-8c03-6f3b6e5a6929@default>



Greetings: 


Please consider the following changes that eliminate the use of uninitialized memory. 


http://cr.openjdk.java.net/~jzavgren/8003245/webrev.01/ 


Thanks! 
John

From chris.hegarty at oracle.com  Wed Mar 20 15:34:53 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 20 Mar 2013 15:34:53 +0000
Subject: RFR-8008118
In-Reply-To: <0520220f-b796-48be-b74a-202b81f2d557@default>
References: <0520220f-b796-48be-b74a-202b81f2d557@default>
Message-ID: <5149D71D.5030502@oracle.com>

Looks good to me John.

Minor style issue, should be a space after the if, 'if_(xxxx)"

-Chris.

On 20/03/2013 15:22, John Zavgren wrote:
> Greetings:
>
> Please consider the following fix for a minor memory issue that I found in the file: src/solaris/native/java/lang/UNIXProcess_md.c.
>
> http://cr.openjdk.java.net/~jzavgren/8008118/webrev.01/
>
> Thanks!
> John Zavgren


From Alan.Bateman at oracle.com  Wed Mar 20 15:34:54 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 20 Mar 2013 15:34:54 +0000
Subject: RFR-8008118
In-Reply-To: <0520220f-b796-48be-b74a-202b81f2d557@default>
References: <0520220f-b796-48be-b74a-202b81f2d557@default>
Message-ID: <5149D71E.9020003@oracle.com>

On 20/03/2013 15:22, John Zavgren wrote:
> Greetings:
>
> Please consider the following fix for a minor memory issue that I found in the file: src/solaris/native/java/lang/UNIXProcess_md.c.
>
> http://cr.openjdk.java.net/~jzavgren/8008118/webrev.01/
>
> Thanks!
> John Zavgren
If there is a chance that we will recover then splitPath may have 
malloc'ed a few segments before failing. I don't know if you want to 
attempt to free those before bailing (could be tricky). On the other 
hand, I think this is java.lang.UNIXProcess's static initializer so the 
OOME will cause that to fail so we are probably hosed anyway.

A minor comment but it would be best to put a space in "if(" to keep it 
consistent.

-Alan


From chris.hegarty at oracle.com  Wed Mar 20 16:00:34 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Wed, 20 Mar 2013 16:00:34 +0000
Subject: hg: jdk8/tl/jdk: 8010282:
	sun.net.www.protocol.jar.JarFileFactory.close(JarFile) should
	be thread-safe
Message-ID: <20130320160054.9B3564829D@hg.openjdk.java.net>

Changeset: 3070b7363853
Author:    chegar
Date:      2013-03-20 14:39 +0000
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3070b7363853

8010282: sun.net.www.protocol.jar.JarFileFactory.close(JarFile) should be thread-safe
Reviewed-by: khazra, alanb

! src/share/classes/sun/net/www/protocol/jar/JarURLConnection.java
! src/solaris/classes/sun/net/www/protocol/jar/JarFileFactory.java
! src/windows/classes/sun/net/www/protocol/jar/JarFileFactory.java



From sean.mullan at oracle.com  Wed Mar 20 16:07:12 2013
From: sean.mullan at oracle.com (sean.mullan at oracle.com)
Date: Wed, 20 Mar 2013 16:07:12 +0000
Subject: hg: jdk8/tl/jdk: 3 new changesets
Message-ID: <20130320160747.CAF5F4829F@hg.openjdk.java.net>

Changeset: 38116bfe5323
Author:    mullan
Date:      2013-03-20 10:58 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/38116bfe5323

8010112: NullPointerException in sun.security.provider.certpath.CertId()
Reviewed-by: vinnie

! src/share/classes/sun/security/provider/certpath/CertId.java
! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java
! src/share/classes/sun/security/provider/certpath/RevocationChecker.java
! src/share/classes/sun/security/x509/X509CertImpl.java

Changeset: 9859856920ed
Author:    mullan
Date:      2013-03-20 11:23 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9859856920ed

Merge

- src/share/classes/sun/security/util/KeyLength.java

Changeset: 38c1d0c2d6a6
Author:    mullan
Date:      2013-03-20 12:06 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/38c1d0c2d6a6

Merge




From mandy.chung at oracle.com  Wed Mar 20 16:51:42 2013
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Wed, 20 Mar 2013 16:51:42 +0000
Subject: hg: jdk8/tl/jdk: 8006104: Improve tests to test ".useParentHandlers"
	property set in the logging configuration
Message-ID: <20130320165154.8D490482A5@hg.openjdk.java.net>

Changeset: ccd9f53377c4
Author:    mchung
Date:      2013-03-20 09:50 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ccd9f53377c4

8006104: Improve tests to test ".useParentHandlers" property set in the logging configuration
Reviewed-by: alanb

! test/java/util/logging/CustomLogManager.java
! test/java/util/logging/CustomLogManagerTest.java



From mandy.chung at oracle.com  Wed Mar 20 17:16:26 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 20 Mar 2013 10:16:26 -0700
Subject: PlatformLogger: isLoggable performance / waste due to
	HashMap leads to Integer allocations (boxing)
In-Reply-To: 
References: 
	<5148A334.6060207@oracle.com>
	
Message-ID: <5149EEEA.6020700@oracle.com>

Hi Laurent,

Thank you for signing the OCA.  Your contribution is very welcome. You 
can submit a patch for this bug (see [1]) to Core libraries group which 
owns logging.  Jim Gish and I will sponsor it.

Thanks
Mandy
[1] http://openjdk.java.net/contribute/

On 3/20/2013 5:45 AM, Laurent Bourg?s wrote:
> Hi mandy,
>
> Do you want me to propose an improved patch to remove the former Map 
> and fix the getLevel() method ? or you prefer fix on your own ?
>
> Is it better to discuss the fix on the bug database (still not visible) ?
>
> Laurent
>
> 2013/3/19 Mandy Chung  >
>
>     Hi Laurent,
>
>     Thanks for the contribution.  I agree that the map can be replaced
>     with a direct mapping from a int value to Level object and avoid
>     the autoboxing conversion.
>
>     I have filed a bug to track this and target this for JDK8:
>     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id= 8010309
>
>     Thanks
>     Mandy
>
>
>     On 3/19/13 5:19 AM, Laurent Bourg?s wrote:
>>     Dear all, I run recently netbeans profiler on my swing
>>     application (Aspro2: http://www.jmmc.fr/aspro
>>     ) under linux x64 platform and figured out a
>>     performance and waste issue related to PlatformLogger.
>>
>>     Actually, the JavaLogger implementation uses a Map
>>     levelObjects to store mapping between PlatformLogger's levels (int) and JUL
>>     Level instances.
>>
>>     However, the isLoggable(int level) method is highly used by awt project and
>>     other JDK projects and it leads to many Integer allocations as autoboxing
>>     converts the level as int to an Integer instance used by the Map.get() call.
>>
>>          /**
>>           * JavaLogger forwards all the calls to its corresponding
>>           * java.util.logging.Logger object.
>>           */
>>          static class JavaLogger extends LoggerProxy {
>>              private static final* Map* levelObjects = new
>>     HashMap<>();
>>     ...
>>              public boolean isLoggable(*int level*) {
>>                  return LoggingSupport.isLoggable(javaLogger, *
>>     levelObjects.get(level)*);
>>              }
>>          }
>>
>>     I wrote a simple test to illustrate that performance / waste problem:
>>     PlatformLoggerTest that simply performs 1 million DISABLED log statements:
>>                  if (log.isLoggable(PlatformLogger.FINEST)) {
>>                      log.finest("test PlatformLogger.FINEST");
>>                  }
>>
>>     As you can see in screenshots:
>>     - 5 million Integer instances are allocated
>>     - Integer.valueOf(int) is called 5 million times (autoboxing)
>>     - HashMap.get() represents 30% of the test time
>>     - patched PlatformLogger is 3x times faster
>>     [jvm options: -Xms8m -Xmx8m -verbose:gc]
>>
>>     I suggest you to use an alternative way to map PlatformLogger's levels
>>     (int) and JUL Level instances to fix that performance / memory issue: I
>>     added the getLevel(int level) method that performs a switch case to return
>>     the corresponding Level object (quick and dirty solution).
>>
>>     I advocate this is not a very clean solution but I prefer efficiency here:
>>     any better solution may be appropriate to avoid at least Integer allocation
>>     and maybe enhance performance.
>>
>>     Best regards,
>>     Laurent Bourg?s
>>
>>     PS: here is the patch as text:
>>
>>     # This patch file was generated by NetBeans IDE
>>     # It uses platform neutral UTF-8 encoding and \n newlines.
>>     --- PlatformLogger.java (6767)
>>     +++ PlatformLogger.java (6768)
>>     @@ -468,31 +468,13 @@
>>            * java.util.logging.Logger object.
>>            */
>>           static class JavaLogger extends LoggerProxy {
>>     -        /** Note: using Integer keys leads to a lot of new Integer
>>     instances !! */
>>     -        private static final Map levelObjects = new
>>     HashMap<>();
>>     -        /** fastest mapping to Level instances from PlatformLogger level
>>     as integer */
>>     -        private static final Object[] fastLevelObjects;
>>     -
>>     -
>>     +        private static final Map levelObjects =
>>     +            new HashMap<>();
>>     +
>>               static {
>>                   if (LoggingSupport.isAvailable()) {
>>                       // initialize the map to Level objects
>>                       getLevelObjects();
>>     -
>>     -                // initialize the fastLevelObjects:
>>     -                fastLevelObjects = new Object[] {
>>     -                    LoggingSupport.parseLevel(getLevelName(OFF)),       //
>>     0
>>     -                    LoggingSupport.parseLevel(getLevelName(SEVERE)),    //
>>     1
>>     -                    LoggingSupport.parseLevel(getLevelName(WARNING)),   //
>>     2
>>     -                    LoggingSupport.parseLevel(getLevelName(INFO)),      //
>>     3
>>     -                    LoggingSupport.parseLevel(getLevelName(CONFIG)),    //
>>     4
>>     -                    LoggingSupport.parseLevel(getLevelName(FINE)),      //
>>     5
>>     -                    LoggingSupport.parseLevel(getLevelName(FINER)),     //
>>     6
>>     -                    LoggingSupport.parseLevel(getLevelName(FINEST)),    //
>>     7
>>     -                    LoggingSupport.parseLevel(getLevelName(ALL))        //
>>     8
>>     -                };
>>     -            } else {
>>     -                fastLevelObjects = null; // check null
>>                   }
>>               }
>>
>>     @@ -515,7 +497,7 @@
>>                   this.javaLogger = LoggingSupport.getLogger(name);
>>                   if (level != 0) {
>>                       // level has been updated and so set the Logger's level
>>     -                LoggingSupport.setLevel(javaLogger, getLevel(level));
>>     +                LoggingSupport.setLevel(javaLogger,
>>     levelObjects.get(level));
>>                   }
>>               }
>>
>>     @@ -526,11 +508,11 @@
>>               * not be updated.
>>               */
>>               void doLog(int level, String msg) {
>>     -            LoggingSupport.log(javaLogger, getLevel(level), msg);
>>     +            LoggingSupport.log(javaLogger, levelObjects.get(level), msg);
>>               }
>>
>>               void doLog(int level, String msg, Throwable t) {
>>     -            LoggingSupport.log(javaLogger, getLevel(level), msg, t);
>>     +            LoggingSupport.log(javaLogger, levelObjects.get(level), msg,
>>     t);
>>               }
>>
>>               void doLog(int level, String msg, Object... params) {
>>     @@ -544,12 +526,12 @@
>>                   for (int i = 0; i < len; i++) {
>>                       sparams [i] = String.valueOf(params[i]);
>>                   }
>>     -            LoggingSupport.log(javaLogger, getLevel(level), msg, sparams);
>>     +            LoggingSupport.log(javaLogger, levelObjects.get(level), msg,
>>     sparams);
>>               }
>>
>>               boolean isEnabled() {
>>                   Object level = LoggingSupport.getLevel(javaLogger);
>>     -            return level == null || level.equals(getLevel(OFF)) == false;
>>     +            return level == null || level.equals(levelObjects.get(OFF)) ==
>>     false;
>>               }
>>
>>               int getLevel() {
>>     @@ -566,34 +548,12 @@
>>
>>               void setLevel(int newLevel) {
>>                   levelValue = newLevel;
>>     -            LoggingSupport.setLevel(javaLogger, getLevel(newLevel));
>>     +            LoggingSupport.setLevel(javaLogger,
>>     levelObjects.get(newLevel));
>>               }
>>
>>               public boolean isLoggable(int level) {
>>     -            return LoggingSupport.isLoggable(javaLogger, getLevel(level));
>>     +            return LoggingSupport.isLoggable(javaLogger,
>>     levelObjects.get(level));
>>               }
>>     -
>>     -        /**
>>     -         * Return the corresponding level object (fastest implementation)
>>     -         * @param level PlatformLogger level as primitive integer
>>     -         * @return Object (JUL Level instance)
>>     -         */
>>     -        private static Object getLevel(final int level) {
>>     -            // higher occurences first (finest, fine, finer, info):
>>     -            switch (level) {
>>     -                case FINEST  : return fastLevelObjects[7];
>>     -                case FINE    : return fastLevelObjects[5];
>>     -                case FINER   : return fastLevelObjects[6];
>>     -                case INFO    : return fastLevelObjects[3];
>>     -                case CONFIG  : return fastLevelObjects[4];
>>     -                case WARNING : return fastLevelObjects[2];
>>     -                case SEVERE  : return fastLevelObjects[1];
>>     -                case ALL     : return fastLevelObjects[8];
>>     -                case OFF     : return fastLevelObjects[0];
>>     -                default      : return null;
>>     -            }
>>     -        }
>>     -
>>           }
>>
>>           private static String getLevelName(int level) {
>
>



From jim.gish at oracle.com  Wed Mar 20 18:39:17 2013
From: jim.gish at oracle.com (Jim Gish)
Date: Wed, 20 Mar 2013 14:39:17 -0400
Subject: PlatformLogger: isLoggable performance / waste due to
	HashMap leads to Integer allocations (boxing)
In-Reply-To: 
References: 
	<5148A334.6060207@oracle.com>
	
Message-ID: <514A0255.5020902@oracle.com>

Hi Laurent,

If you'd like to submit an improved patch, I'll take a look.  The best 
way to do this is to post a webrev: 
http://openjdk.java.net/guide/webrevHelp.html

Looking forward to  your participation and contributions.  Welcome!

Thanks,
   Jim Gish

On 03/20/2013 08:45 AM, Laurent Bourg?s wrote:
> Hi mandy,
>
> Do you want me to propose an improved patch to remove the former Map and
> fix the getLevel() method ? or you prefer fix on your own ?
>
> Is it better to discuss the fix on the bug database (still not visible) ?
>
> Laurent
>
> 2013/3/19 Mandy Chung 
>
>>   Hi Laurent,
>>
>> Thanks for the contribution.  I agree that the map can be replaced with a
>> direct mapping from a int value to Level object and avoid the autoboxing
>> conversion.
>>
>> I have filed a bug to track this and target this for JDK8:
>>    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id= 8010309
>>
>> Thanks
>> Mandy
>>
>>
>> On 3/19/13 5:19 AM, Laurent Bourg?s wrote:
>>
>> Dear all,
>>
>> I run recently netbeans profiler on my swing application (Aspro2:http://www.jmmc.fr/aspro
>> ) under linux x64 platform and figured out a
>> performance and waste issue related to PlatformLogger.
>>
>> Actually, the JavaLogger implementation uses a Map
>> levelObjects to store mapping between PlatformLogger's levels (int) and JUL
>> Level instances.
>>
>> However, the isLoggable(int level) method is highly used by awt project and
>> other JDK projects and it leads to many Integer allocations as autoboxing
>> converts the level as int to an Integer instance used by the Map.get() call.
>>
>>      /**
>>       * JavaLogger forwards all the calls to its corresponding
>>       * java.util.logging.Logger object.
>>       */
>>      static class JavaLogger extends LoggerProxy {
>>          private static final* Map* levelObjects = new
>> HashMap<>();
>> ...
>>          public boolean isLoggable(*int level*) {
>>              return LoggingSupport.isLoggable(javaLogger, *
>> levelObjects.get(level)*);
>>          }
>>      }
>>
>> I wrote a simple test to illustrate that performance / waste problem:
>> PlatformLoggerTest that simply performs 1 million DISABLED log statements:
>>              if (log.isLoggable(PlatformLogger.FINEST)) {
>>                  log.finest("test PlatformLogger.FINEST");
>>              }
>>
>> As you can see in screenshots:
>> - 5 million Integer instances are allocated
>> - Integer.valueOf(int) is called 5 million times (autoboxing)
>> - HashMap.get() represents 30% of the test time
>> - patched PlatformLogger is 3x times faster
>> [jvm options: -Xms8m -Xmx8m -verbose:gc]
>>
>> I suggest you to use an alternative way to map PlatformLogger's levels
>> (int) and JUL Level instances to fix that performance / memory issue: I
>> added the getLevel(int level) method that performs a switch case to return
>> the corresponding Level object (quick and dirty solution).
>>
>> I advocate this is not a very clean solution but I prefer efficiency here:
>> any better solution may be appropriate to avoid at least Integer allocation
>> and maybe enhance performance.
>>
>> Best regards,
>> Laurent Bourg?s
>>
>> PS: here is the patch as text:
>>
>> # This patch file was generated by NetBeans IDE
>> # It uses platform neutral UTF-8 encoding and \n newlines.
>> --- PlatformLogger.java (6767)
>> +++ PlatformLogger.java (6768)
>> @@ -468,31 +468,13 @@
>>        * java.util.logging.Logger object.
>>        */
>>       static class JavaLogger extends LoggerProxy {
>> -        /** Note: using Integer keys leads to a lot of new Integer
>> instances !! */
>> -        private static final Map levelObjects = new
>> HashMap<>();
>> -        /** fastest mapping to Level instances from PlatformLogger level
>> as integer */
>> -        private static final Object[] fastLevelObjects;
>> -
>> -
>> +        private static final Map levelObjects =
>> +            new HashMap<>();
>> +
>>           static {
>>               if (LoggingSupport.isAvailable()) {
>>                   // initialize the map to Level objects
>>                   getLevelObjects();
>> -
>> -                // initialize the fastLevelObjects:
>> -                fastLevelObjects = new Object[] {
>> -                    LoggingSupport.parseLevel(getLevelName(OFF)),       //
>> 0
>> -                    LoggingSupport.parseLevel(getLevelName(SEVERE)),    //
>> 1
>> -                    LoggingSupport.parseLevel(getLevelName(WARNING)),   //
>> 2
>> -                    LoggingSupport.parseLevel(getLevelName(INFO)),      //
>> 3
>> -                    LoggingSupport.parseLevel(getLevelName(CONFIG)),    //
>> 4
>> -                    LoggingSupport.parseLevel(getLevelName(FINE)),      //
>> 5
>> -                    LoggingSupport.parseLevel(getLevelName(FINER)),     //
>> 6
>> -                    LoggingSupport.parseLevel(getLevelName(FINEST)),    //
>> 7
>> -                    LoggingSupport.parseLevel(getLevelName(ALL))        //
>> 8
>> -                };
>> -            } else {
>> -                fastLevelObjects = null; // check null
>>               }
>>           }
>>
>> @@ -515,7 +497,7 @@
>>               this.javaLogger = LoggingSupport.getLogger(name);
>>               if (level != 0) {
>>                   // level has been updated and so set the Logger's level
>> -                LoggingSupport.setLevel(javaLogger, getLevel(level));
>> +                LoggingSupport.setLevel(javaLogger,
>> levelObjects.get(level));
>>               }
>>           }
>>
>> @@ -526,11 +508,11 @@
>>           * not be updated.
>>           */
>>           void doLog(int level, String msg) {
>> -            LoggingSupport.log(javaLogger, getLevel(level), msg);
>> +            LoggingSupport.log(javaLogger, levelObjects.get(level), msg);
>>           }
>>
>>           void doLog(int level, String msg, Throwable t) {
>> -            LoggingSupport.log(javaLogger, getLevel(level), msg, t);
>> +            LoggingSupport.log(javaLogger, levelObjects.get(level), msg,
>> t);
>>           }
>>
>>           void doLog(int level, String msg, Object... params) {
>> @@ -544,12 +526,12 @@
>>               for (int i = 0; i < len; i++) {
>>                   sparams [i] = String.valueOf(params[i]);
>>               }
>> -            LoggingSupport.log(javaLogger, getLevel(level), msg, sparams);
>> +            LoggingSupport.log(javaLogger, levelObjects.get(level), msg,
>> sparams);
>>           }
>>
>>           boolean isEnabled() {
>>               Object level = LoggingSupport.getLevel(javaLogger);
>> -            return level == null || level.equals(getLevel(OFF)) == false;
>> +            return level == null || level.equals(levelObjects.get(OFF)) ==
>> false;
>>           }
>>
>>           int getLevel() {
>> @@ -566,34 +548,12 @@
>>
>>           void setLevel(int newLevel) {
>>               levelValue = newLevel;
>> -            LoggingSupport.setLevel(javaLogger, getLevel(newLevel));
>> +            LoggingSupport.setLevel(javaLogger,
>> levelObjects.get(newLevel));
>>           }
>>
>>           public boolean isLoggable(int level) {
>> -            return LoggingSupport.isLoggable(javaLogger, getLevel(level));
>> +            return LoggingSupport.isLoggable(javaLogger,
>> levelObjects.get(level));
>>           }
>> -
>> -        /**
>> -         * Return the corresponding level object (fastest implementation)
>> -         * @param level PlatformLogger level as primitive integer
>> -         * @return Object (JUL Level instance)
>> -         */
>> -        private static Object getLevel(final int level) {
>> -            // higher occurences first (finest, fine, finer, info):
>> -            switch (level) {
>> -                case FINEST  : return fastLevelObjects[7];
>> -                case FINE    : return fastLevelObjects[5];
>> -                case FINER   : return fastLevelObjects[6];
>> -                case INFO    : return fastLevelObjects[3];
>> -                case CONFIG  : return fastLevelObjects[4];
>> -                case WARNING : return fastLevelObjects[2];
>> -                case SEVERE  : return fastLevelObjects[1];
>> -                case ALL     : return fastLevelObjects[8];
>> -                case OFF     : return fastLevelObjects[0];
>> -                default      : return null;
>> -            }
>> -        }
>> -
>>       }
>>
>>       private static String getLevelName(int level) {
>>
>>
>>

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From joe.darcy at oracle.com  Wed Mar 20 22:21:33 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Wed, 20 Mar 2013 22:21:33 +0000
Subject: hg: jdk8/tl/jdk: 8010427: Refine Method.isDefault implementation
Message-ID: <20130320222204.58614482BF@hg.openjdk.java.net>

Changeset: cf0049037deb
Author:    darcy
Date:      2013-03-20 15:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf0049037deb

8010427: Refine Method.isDefault implementation
Reviewed-by: acorn, dlsmith

! src/share/classes/java/lang/reflect/Method.java



From stevenschlansker at gmail.com  Wed Mar 20 22:39:54 2013
From: stevenschlansker at gmail.com (Steven Schlansker)
Date: Wed, 20 Mar 2013 15:39:54 -0700
Subject: RFR (S) CR 8006627/8007398: Improve performance of
	Long.toUnsignedString0, Integer.toUnsignedString0,
	UUID(String) and UUID.toString
In-Reply-To: <0D2150A5-DF5A-41CF-8405-C7D19959F3EC@oracle.com>
References: 
	<84A32ABE-B1E7-4E03-9843-DDFE20897B77@oracle.com>
	<0EC036A3-3D11-4F56-B3FD-403CCC610347@gmail.com>
	
	
	<9251F945-7B88-484A-B38F-487A29D66F4D@oracle.com>
	<7DDE01A1-0845-4FE7-9454-958CC5F585FF@gmail.com>
	<9E63A0FB-47D8-4993-94DD-258ED9A4EDDA@oracle.com>
	<511AEB3C.6050309@CoSoCo.de>
	<0AA1CB21-D478-4FF5-A880-9B01E5052268@oracle.com>
	<511AF9B2.6060601@CoSoCo.de>
	<0D2150A5-DF5A-41CF-8405-C7D19959F3EC@oracle.com>
Message-ID: <17B51C5D-4C36-411A-BC72-1CA2D6C5590D@gmail.com>


On Feb 13, 2013, at 2:45 PM, Mike Duigou  wrote:

> I have updated the patch with some of Ulf's feedback and corrected one cut-and-paste error that I made.
> 
> The updated webrev is at:
> 
> http://cr.openjdk.java.net/~mduigou/JDK-8006627/2/webrev/
> 

One last ping to make sure this doesn't slip through the cracks, as I haven't seen the commit go through the public JDK8 repo?  or maybe I missed it.

Thanks again for looking at this :-)

> Mike
> 
> On Feb 12 2013, at 18:25 , Ulf Zibis wrote:
> 
>> Am 13.02.2013 02:34, schrieb Mike Duigou:
>>> Thank you for the comments Ulf.
>>> 
>>> On Feb 12 2013, at 17:24 , Ulf Zibis wrote:
>>> 
>>>> Am 13.02.2013 00:30, schrieb Mike Duigou:
>>>>> Hi Steven;
>>>>> 
>>>>> I have updated the patch for Java 8. There's somewhat less code sharing and a bit of refactoring than your last version but the performance should be about the same or a little better.
>>>>> 
>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8007398/0/webrev/
>>>> Couldn't you use String(buf, true) for all to(Unsigned)String(...) methods ?
>>> Possibly. I didn't go looking too far with looking for additional improvements.
>>> 
>>>> Instead of calculating the mask each time, you could use:
>>>> 309     private static String toUnsignedString(int i, int shift, int mask) {
>>> I think that would actually be inefficient. I haven't looked at the JITed code but the mask calculation is pretty cheap relative to parameter passing.
>> 
>> I believe, JIT will inline the code, so there would be no parameter passing.
>> 
>> Additionally the calculation of char count could be faster, if you would have short cuts like:
>> numberOfLeading2Zeros(i)
>> numberOfLeading4Zeros(i)
>> numberOfLeading8Zeros(i)
>> ...
>> So the optimum would be with separate toString methods:
>> String toBase2String(int i);
>> String toBase4String(int i);
>> String toBase8String(int i);
>> ...
>> 
>> In any case I would save 2 lines:
>> 
>> 311         int mag = Integer.SIZE - Long.numberOfLeadingZeros(i);
>> 312         int charCount = Math.max(((mag + (shift - 1)) / shift), 1);
>> 313         char[] buf = new char[charCount];
>> 316         int mask = (1 << shift) - 1;
>> 
>> -Ulf
>> 
> 



From mike.duigou at oracle.com  Wed Mar 20 22:47:32 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 20 Mar 2013 15:47:32 -0700
Subject: RFR (S) CR 8006627/8007398: Improve performance of
	Long.toUnsignedString0, Integer.toUnsignedString0,
	UUID(String) and UUID.toString
In-Reply-To: <17B51C5D-4C36-411A-BC72-1CA2D6C5590D@gmail.com>
References: 
	<84A32ABE-B1E7-4E03-9843-DDFE20897B77@oracle.com>
	<0EC036A3-3D11-4F56-B3FD-403CCC610347@gmail.com>
	
	
	<9251F945-7B88-484A-B38F-487A29D66F4D@oracle.com>
	<7DDE01A1-0845-4FE7-9454-958CC5F585FF@gmail.com>
	<9E63A0FB-47D8-4993-94DD-258ED9A4EDDA@oracle.com>
	<511AEB3C.6050309@CoSoCo.de>
	<0AA1CB21-D478-4FF5-A880-9B01E5052268@oracle.com>
	<511AF9B2.6060601@CoSoCo.de>
	<0D2150A5-DF5A-41CF-8405-C7D19959F3EC@oracle.com>
	<17B51C5D-4C36-411A-BC72-1CA2D6C5590D@gmail.com>
Message-ID: <71015412-68D5-48C0-BBED-AE4EB0A9E216@oracle.com>

Hi Steven;

I haven't forgotten and it's still in my queue for Java 8. I haven't had time to respond to Martin Buchholz's feedback.

http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-February/014528.html

I suspect he is right about computing digits vs the table being a better choice but I would want to test that first with a proper microbenchmark (and then fix a bunch of other places that use the same table).

If you have time to follow up on any of this things will go quicker. :-)

Mike

On Mar 20 2013, at 15:39 , Steven Schlansker wrote:

> 
> On Feb 13, 2013, at 2:45 PM, Mike Duigou  wrote:
> 
>> I have updated the patch with some of Ulf's feedback and corrected one cut-and-paste error that I made.
>> 
>> The updated webrev is at:
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-8006627/2/webrev/
>> 
> 
> One last ping to make sure this doesn't slip through the cracks, as I haven't seen the commit go through the public JDK8 repo?  or maybe I missed it.
> 
> Thanks again for looking at this :-)
> 
>> Mike
>> 
>> On Feb 12 2013, at 18:25 , Ulf Zibis wrote:
>> 
>>> Am 13.02.2013 02:34, schrieb Mike Duigou:
>>>> Thank you for the comments Ulf.
>>>> 
>>>> On Feb 12 2013, at 17:24 , Ulf Zibis wrote:
>>>> 
>>>>> Am 13.02.2013 00:30, schrieb Mike Duigou:
>>>>>> Hi Steven;
>>>>>> 
>>>>>> I have updated the patch for Java 8. There's somewhat less code sharing and a bit of refactoring than your last version but the performance should be about the same or a little better.
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8007398/0/webrev/
>>>>> Couldn't you use String(buf, true) for all to(Unsigned)String(...) methods ?
>>>> Possibly. I didn't go looking too far with looking for additional improvements.
>>>> 
>>>>> Instead of calculating the mask each time, you could use:
>>>>> 309     private static String toUnsignedString(int i, int shift, int mask) {
>>>> I think that would actually be inefficient. I haven't looked at the JITed code but the mask calculation is pretty cheap relative to parameter passing.
>>> 
>>> I believe, JIT will inline the code, so there would be no parameter passing.
>>> 
>>> Additionally the calculation of char count could be faster, if you would have short cuts like:
>>> numberOfLeading2Zeros(i)
>>> numberOfLeading4Zeros(i)
>>> numberOfLeading8Zeros(i)
>>> ...
>>> So the optimum would be with separate toString methods:
>>> String toBase2String(int i);
>>> String toBase4String(int i);
>>> String toBase8String(int i);
>>> ...
>>> 
>>> In any case I would save 2 lines:
>>> 
>>> 311         int mag = Integer.SIZE - Long.numberOfLeadingZeros(i);
>>> 312         int charCount = Math.max(((mag + (shift - 1)) / shift), 1);
>>> 313         char[] buf = new char[charCount];
>>> 316         int mask = (1 << shift) - 1;
>>> 
>>> -Ulf
>>> 
>> 
> 



From martinrb at google.com  Wed Mar 20 23:12:31 2013
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 20 Mar 2013 16:12:31 -0700
Subject: RFR-8008118
In-Reply-To: <0520220f-b796-48be-b74a-202b81f2d557@default>
References: <0520220f-b796-48be-b74a-202b81f2d557@default>
Message-ID: 

Hi John,

I wrote this code originally IIRC.  You are correct that the existing code
does not check these allocations for failure.  In practice, it will be very
rare for the failure to be seen, since the allocations are likely to be
small and only occur during program startup.

I commend you for trying to get this right, but if you want to get there, I
think you need to throw OOME and undo all of the existing allocations.  You
can do that by keeping track of how many elements you already allocated,
freeing them, and throwing OOME.  As Alan points out, the exception in the
static initializer shows that recovery is even more problematic than with a
regular OOME.  Nevertheless, throwing OOME is going to be a better result
for the user than uninformative SEGV.

Martin


On Wed, Mar 20, 2013 at 8:22 AM, John Zavgren wrote:

> Greetings:
>
> Please consider the following fix for a minor memory issue that I found in
> the file: src/solaris/native/java/lang/UNIXProcess_md.c.
>
> http://cr.openjdk.java.net/~jzavgren/8008118/webrev.01/
>
> Thanks!
> John Zavgren
>


From martinrb at google.com  Wed Mar 20 23:22:32 2013
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 20 Mar 2013 16:22:32 -0700
Subject: Please review: surrogate fiddle
In-Reply-To: <5149C30E.1080405@CoSoCo.de>
References: 
	
	
	<5147D0F8.3090101@oracle.com>
	
	<51480152.5010102@oracle.com>
	
	
	<5148B539.4020508@oracle.com>
	
	<5149C30E.1080405@CoSoCo.de>
Message-ID: 

On Wed, Mar 20, 2013 at 7:09 AM, Ulf Zibis  wrote:

> Hi Martin,
>
> nice to see you again on board.
>
>
Hi Ulf!


> Am 19.03.2013 20:18, schrieb Martin Buchholz:
>
>> Thanks!  Webrev updated.
>>
>
> Character:
> Maybe I'm blind, is there any semantical difference between
>         char c1 = seq.charAt(index++);
>         if (isHighSurrogate(c1)) {
>             if (index < seq.length()) {
> and
>         char c1 = seq.charAt(index);
>         if (isHighSurrogate(c1) && ++index < seq.length()) {
> , or is it just for beautifying the code?
>
>
No behavior difference, only the principle that one should "obviously" do
no more work than necessary, even if hotspot+CPU will very likely make that
extra work disappear.



> AbstractStringBuilder:
> Instead
>  270     public int codePointBefore(int index) {
>  271         int i = index - 1;
>  272         if ((i < 0) || (i >= count)) {
>  273             throw new StringIndexOutOfBoundsExceptio**n(index);
>  274         }
> I suggest
>  270     public int codePointBefore(int index) {
>  271         if ((--index < 0) || (index >= count)) {
>  272             throw new StringIndexOutOfBoundsExceptio**n(index);
>  273         }
> , because if e.g. the initial value of index is 0, then -1 reflects the
> out-of-bound condition, but not the initial 0 to report in the
> StringIndexOutOfBoundsExceptio**n.
> (Hopefully the following redundant i < 0 bounds check from value[i]
> becomes elimited by JIT.)
>
>
I was impressed that hotspot could indeed remove the redundant bounds
checks.
Only with -Xint was I able to demonstrate a performance win.



> If there is some register pressure, you could avoid potential register
> swapping for temp, temp2, hasSurrogate, j and n - j if you would reorder
> following lines to:
> 1390             char temp = value[j];
> 1391             char temp2 = value[j] = value[n - j];
> 1397             value[n - j] = temp;
> 1392             if (!hasSurrogate) {
> 1393                 hasSurrogate = (Character.isSurrogate(temp) ||
> 1394                                 Character.isSurrogate(temp2));
> 1395             }
> (Nomination for "performance expert II" ?)
>
>
Thanks for making me beat my head against the hotspot optimization wall!
The latest version of reverse in my webrev, after way too much fiddling, is
20% faster,
even though I'm not quite sure why.



>
>  I, ummmm... am a "performance expert".
>>
>> How about, if I can ever measure any performance win in a micro-benchmark,
>> we're allowed to keep the lower-level code?
>>
>
> Yes I remember ;-)
> As IMHO better alternative you could proof the JIT result by hsdis.
>
>
> I think, you independently should test
>     static int codePointAtImpl(char[] a, int index, int limit) {...}
> to don't read out-of-bounds trailing surrogate.
> ... and you additionally should provide a test for
>     static int codePointBeforeImpl(char[] a, int index, int start) {...}
> to don't read out-of-bounds precursory surrogate.



If you write tests, I will incorporate into this changeset!


From chris.hegarty at oracle.com  Wed Mar 20 23:23:57 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 20 Mar 2013 23:23:57 +0000
Subject: RFR-8008118
In-Reply-To: 
References: <0520220f-b796-48be-b74a-202b81f2d557@default>
	
Message-ID: 

Martin,

I take your point about the other allocations, but as you say OOM is better than SEGV. So possibly good enough?

If NEW returns NULL, then there will be a pending OOM on the stack.

-Chris

On 20 Mar 2013, at 23:12, Martin Buchholz  wrote:

> Hi John,
> 
> I wrote this code originally IIRC.  You are correct that the existing code
> does not check these allocations for failure.  In practice, it will be very
> rare for the failure to be seen, since the allocations are likely to be
> small and only occur during program startup.
> 
> I commend you for trying to get this right, but if you want to get there, I
> think you need to throw OOME and undo all of the existing allocations.  You
> can do that by keeping track of how many elements you already allocated,
> freeing them, and throwing OOME.  As Alan points out, the exception in the
> static initializer shows that recovery is even more problematic than with a
> regular OOME.  Nevertheless, throwing OOME is going to be a better result
> for the user than uninformative SEGV.
> 
> Martin
> 
> 
> On Wed, Mar 20, 2013 at 8:22 AM, John Zavgren wrote:
> 
>> Greetings:
>> 
>> Please consider the following fix for a minor memory issue that I found in
>> the file: src/solaris/native/java/lang/UNIXProcess_md.c.
>> 
>> http://cr.openjdk.java.net/~jzavgren/8008118/webrev.01/
>> 
>> Thanks!
>> John Zavgren
>> 


From martinrb at google.com  Wed Mar 20 23:32:36 2013
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 20 Mar 2013 16:32:36 -0700
Subject: RFR-8008118
In-Reply-To: 
References: <0520220f-b796-48be-b74a-202b81f2d557@default>
	
	
Message-ID: 

On Wed, Mar 20, 2013 at 4:23 PM, Chris Hegarty wrote:

> Martin,
>
> I take your point about the other allocations, but as you say OOM is
> better than SEGV. So possibly good enough?
>
>
Ah, Thanks Chris, I had forgotten that NEW *does* throw OOME.


> If NEW returns NULL, then there will be a pending OOM on the stack.
>
>
good point!
In that case, this is indeed a clear improvement, and I leave it to John
whether to undo the allocations in splitPath before returning.

Just add that space after "if", please, before you submit!


From joe.darcy at oracle.com  Thu Mar 21 00:41:53 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Thu, 21 Mar 2013 00:41:53 +0000
Subject: hg: jdk8/tl/langtools: 8010364: Clarify javax.lang.model API for Type
	Annotations
Message-ID: <20130321004156.BF54C482CC@hg.openjdk.java.net>

Changeset: 972474640b7d
Author:    darcy
Date:      2013-03-20 17:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/972474640b7d

8010364: Clarify javax.lang.model API for Type Annotations
Reviewed-by: jjg, abuckley

! src/share/classes/javax/lang/model/AnnotatedConstruct.java
! src/share/classes/javax/lang/model/type/ExecutableType.java



From martinrb at google.com  Thu Mar 21 00:52:26 2013
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 20 Mar 2013 17:52:26 -0700
Subject: Please review: surrogate fiddle
In-Reply-To: <51480152.5010102@oracle.com>
References: 
	
	
	<5147D0F8.3090101@oracle.com>
	
	<51480152.5010102@oracle.com>
Message-ID: 

On Mon, Mar 18, 2013 at 11:10 PM, Masayoshi Okutsu <
masayoshi.okutsu at oracle.com> wrote:

>  On 3/19/2013 3:04 PM, Martin Buchholz wrote:
>
>
> On Mon, Mar 18, 2013 at 7:44 PM, Masayoshi Okutsu <
> masayoshi.okutsu at oracle.com> wrote:
>
>> As for duplicating code, I originally duplicated similar code everywhere
>> for performance. But someone told me probably during code review that
>> hotspot inlining was as good as C/C++ macros, and I agreed to replace the
>> duplicated code with method calls.
>>
>>
>  For classes as important as important as StringBuilder, I think we
> should go the extra mile to ensure best performance,
>
>
> That was exactly the reason why I initially took the same approach. So,
> I'd like to leave the decision to performance experts.
>
>
It suddenly occurred to me that we could use the Impl versions of the
methods, because we are actually in the java.lang package.

-        return Character.codePointAt(value, index);
+        return Character.codePointAtImpl(value, index, count);

-        return Character.codePointBefore(value, index);
+        return Character.codePointBeforeImpl(value, index, 0);

which removes the code duplication, and seems slightly faster in my hacky
benchmarks.

I'm pretty happy with this revision of the change.  Can I have some
ThumbsUps, please?



> Masayoshi
>


From david.holmes at oracle.com  Thu Mar 21 02:40:14 2013
From: david.holmes at oracle.com (david.holmes at oracle.com)
Date: Thu, 21 Mar 2013 02:40:14 +0000
Subject: hg: jdk8/tl/jdk: 8006818: SunEC and SunPKCS11 providers should be in
	all profiles
Message-ID: <20130321024037.46C27482D2@hg.openjdk.java.net>

Changeset: 3c1a4966d901
Author:    dholmes
Date:      2013-03-20 22:39 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c1a4966d901

8006818: SunEC and SunPKCS11 providers should be in all profiles
Reviewed-by: dholmes, alanb, valeriep
Contributed-by: Jen Dority 

! makefiles/profile-includes.txt



From bourges.laurent at gmail.com  Thu Mar 21 11:12:07 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Thu, 21 Mar 2013 12:12:07 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due to
	HashMap leads to Integer allocations (boxing)
Message-ID: 

Here is an improved patch tested on JDK7u13 and JDK8 internal build on my
machine linux x64:
http://jmmc.fr/~bourgesl/share/webrev-8010309/

FYI, I removed completely the Map levelObjects and used
two arrays to perform the PlatformLogger's level (int) to j.u.l.Level
mapping:

I decided to keep it simple as possible (no enum ...) and used a switch
case based on current level occurences:

 510         /**
 511          * Return the corresponding j.u.l.Level instance
 512          * @param level PlatformLogger level as integer
 513          * @return Object (j.u.l.Level instance) or null if no
matching level
 514          */
 515         private static Object getLevel(final int level) {
 516             if (levelObjects == null) {
 517                 return null;
 518             }
 519             // higher occurences first (finest, fine, finer, info)
 520             // based on isLoggable(level) calls (03/20/2013)
 521             // in jdk project only (including generated sources)
 522             switch (level) {
 523                 case FINEST  : return levelObjects[IDX_FINEST];
// 116 + 2257 matches in generated files
 524                 case FINE    : return levelObjects[IDX_FINE];    // 270
 525                 case FINER   : return levelObjects[IDX_FINER];   // 157
 526                 case INFO    : return levelObjects[IDX_INFO];    // 39
 527                 case WARNING : return levelObjects[IDX_WARNING]; // 12
 528                 case CONFIG  : return levelObjects[IDX_CONFIG];  // 6
 529                 case SEVERE  : return levelObjects[IDX_SEVERE];  // 1
 530                 case OFF     : return levelObjects[IDX_OFF];     // 0
 531                 case ALL     : return levelObjects[IDX_ALL];     // 0
 532                 default      : return null;
 533             }
 534         }

I enhanced the PlatformLoggerTest class also and figured out that TLAB
optimized Integer allocations but I think the patch is still useful.

Can you have a look to the patch ?
Should I write a jtreg test  (performance / GC issue) ?

Cheers,
Laurent


2013/3/20 Mandy Chung 

>  Hi Laurent,
>
> Thank you for signing the OCA.  Your contribution is very welcome.  You
> can submit a patch for this bug (see [1]) to Core libraries group which
> owns logging.  Jim Gish and I will sponsor it.
>
> Thanks
> Mandy
> [1] http://openjdk.java.net/contribute/
>
>
> On 3/20/2013 5:45 AM, Laurent Bourg?s wrote:
>
> Hi mandy,
>
> Do you want me to propose an improved patch to remove the former Map and
> fix the getLevel() method ? or you prefer fix on your own ?
>
> Is it better to discuss the fix on the bug database (still not visible) ?
>
> Laurent
>
> 2013/3/19 Mandy Chung 
>
>>  Hi Laurent,
>>
>> Thanks for the contribution.  I agree that the map can be replaced with a
>> direct mapping from a int value to Level object and avoid the autoboxing
>> conversion.
>>
>> I have filed a bug to track this and target this for JDK8:
>>   http://bugs.sun.com/bugdatabase/view_bug.do?bug_id= 8010309
>>
>> Thanks
>> Mandy
>>
>>
>> On 3/19/13 5:19 AM, Laurent Bourg?s wrote:
>>
>> Dear all,
>>
>> I run recently netbeans profiler on my swing application (Aspro2:http://www.jmmc.fr/aspro
>> ) under linux x64 platform and figured out a
>> performance and waste issue related to PlatformLogger.
>>
>> Actually, the JavaLogger implementation uses a Map
>> levelObjects to store mapping between PlatformLogger's levels (int) and JUL
>> Level instances.
>>
>> However, the isLoggable(int level) method is highly used by awt project and
>> other JDK projects and it leads to many Integer allocations as autoboxing
>> converts the level as int to an Integer instance used by the Map.get() call.
>>
>>     /**
>>      * JavaLogger forwards all the calls to its corresponding
>>      * java.util.logging.Logger object.
>>      */
>>     static class JavaLogger extends LoggerProxy {
>>         private static final* Map* levelObjects = new
>> HashMap<>();
>> ...
>>         public boolean isLoggable(*int level*) {
>>             return LoggingSupport.isLoggable(javaLogger, *
>> levelObjects.get(level)*);
>>         }
>>     }
>>
>> I wrote a simple test to illustrate that performance / waste problem:
>> PlatformLoggerTest that simply performs 1 million DISABLED log statements:
>>             if (log.isLoggable(PlatformLogger.FINEST)) {
>>                 log.finest("test PlatformLogger.FINEST");
>>             }
>>
>> As you can see in screenshots:
>> - 5 million Integer instances are allocated
>> - Integer.valueOf(int) is called 5 million times (autoboxing)
>> - HashMap.get() represents 30% of the test time
>> - patched PlatformLogger is 3x times faster
>> [jvm options: -Xms8m -Xmx8m -verbose:gc]
>>
>> I suggest you to use an alternative way to map PlatformLogger's levels
>> (int) and JUL Level instances to fix that performance / memory issue: I
>> added the getLevel(int level) method that performs a switch case to return
>> the corresponding Level object (quick and dirty solution).
>>
>> I advocate this is not a very clean solution but I prefer efficiency here:
>> any better solution may be appropriate to avoid at least Integer allocation
>> and maybe enhance performance.
>>
>> Best regards,
>> Laurent Bourg?s
>>
>> PS: here is the patch as text:
>>
>> # This patch file was generated by NetBeans IDE
>> # It uses platform neutral UTF-8 encoding and \n newlines.
>> --- PlatformLogger.java (6767)
>> +++ PlatformLogger.java (6768)
>> @@ -468,31 +468,13 @@
>>       * java.util.logging.Logger object.
>>       */
>>      static class JavaLogger extends LoggerProxy {
>> -        /** Note: using Integer keys leads to a lot of new Integer
>> instances !! */
>> -        private static final Map levelObjects = new
>> HashMap<>();
>> -        /** fastest mapping to Level instances from PlatformLogger level
>> as integer */
>> -        private static final Object[] fastLevelObjects;
>> -
>> -
>> +        private static final Map levelObjects =
>> +            new HashMap<>();
>> +
>>          static {
>>              if (LoggingSupport.isAvailable()) {
>>                  // initialize the map to Level objects
>>                  getLevelObjects();
>> -
>> -                // initialize the fastLevelObjects:
>> -                fastLevelObjects = new Object[] {
>> -                    LoggingSupport.parseLevel(getLevelName(OFF)),       //
>> 0
>> -                    LoggingSupport.parseLevel(getLevelName(SEVERE)),    //
>> 1
>> -                    LoggingSupport.parseLevel(getLevelName(WARNING)),   //
>> 2
>> -                    LoggingSupport.parseLevel(getLevelName(INFO)),      //
>> 3
>> -                    LoggingSupport.parseLevel(getLevelName(CONFIG)),    //
>> 4
>> -                    LoggingSupport.parseLevel(getLevelName(FINE)),      //
>> 5
>> -                    LoggingSupport.parseLevel(getLevelName(FINER)),     //
>> 6
>> -                    LoggingSupport.parseLevel(getLevelName(FINEST)),    //
>> 7
>> -                    LoggingSupport.parseLevel(getLevelName(ALL))        //
>> 8
>> -                };
>> -            } else {
>> -                fastLevelObjects = null; // check null
>>              }
>>          }
>>
>> @@ -515,7 +497,7 @@
>>              this.javaLogger = LoggingSupport.getLogger(name);
>>              if (level != 0) {
>>                  // level has been updated and so set the Logger's level
>> -                LoggingSupport.setLevel(javaLogger, getLevel(level));
>> +                LoggingSupport.setLevel(javaLogger,
>> levelObjects.get(level));
>>              }
>>          }
>>
>> @@ -526,11 +508,11 @@
>>          * not be updated.
>>          */
>>          void doLog(int level, String msg) {
>> -            LoggingSupport.log(javaLogger, getLevel(level), msg);
>> +            LoggingSupport.log(javaLogger, levelObjects.get(level), msg);
>>          }
>>
>>          void doLog(int level, String msg, Throwable t) {
>> -            LoggingSupport.log(javaLogger, getLevel(level), msg, t);
>> +            LoggingSupport.log(javaLogger, levelObjects.get(level), msg,
>> t);
>>          }
>>
>>          void doLog(int level, String msg, Object... params) {
>> @@ -544,12 +526,12 @@
>>              for (int i = 0; i < len; i++) {
>>                  sparams [i] = String.valueOf(params[i]);
>>              }
>> -            LoggingSupport.log(javaLogger, getLevel(level), msg, sparams);
>> +            LoggingSupport.log(javaLogger, levelObjects.get(level), msg,
>> sparams);
>>          }
>>
>>          boolean isEnabled() {
>>              Object level = LoggingSupport.getLevel(javaLogger);
>> -            return level == null || level.equals(getLevel(OFF)) == false;
>> +            return level == null || level.equals(levelObjects.get(OFF)) ==
>> false;
>>          }
>>
>>          int getLevel() {
>> @@ -566,34 +548,12 @@
>>
>>          void setLevel(int newLevel) {
>>              levelValue = newLevel;
>> -            LoggingSupport.setLevel(javaLogger, getLevel(newLevel));
>> +            LoggingSupport.setLevel(javaLogger,
>> levelObjects.get(newLevel));
>>          }
>>
>>          public boolean isLoggable(int level) {
>> -            return LoggingSupport.isLoggable(javaLogger, getLevel(level));
>> +            return LoggingSupport.isLoggable(javaLogger,
>> levelObjects.get(level));
>>          }
>> -
>> -        /**
>> -         * Return the corresponding level object (fastest implementation)
>> -         * @param level PlatformLogger level as primitive integer
>> -         * @return Object (JUL Level instance)
>> -         */
>> -        private static Object getLevel(final int level) {
>> -            // higher occurences first (finest, fine, finer, info):
>> -            switch (level) {
>> -                case FINEST  : return fastLevelObjects[7];
>> -                case FINE    : return fastLevelObjects[5];
>> -                case FINER   : return fastLevelObjects[6];
>> -                case INFO    : return fastLevelObjects[3];
>> -                case CONFIG  : return fastLevelObjects[4];
>> -                case WARNING : return fastLevelObjects[2];
>> -                case SEVERE  : return fastLevelObjects[1];
>> -                case ALL     : return fastLevelObjects[8];
>> -                case OFF     : return fastLevelObjects[0];
>> -                default      : return null;
>> -            }
>> -        }
>> -
>>      }
>>
>>      private static String getLevelName(int level) {
>>
>>
>>
>
>

From Alan.Bateman at oracle.com  Thu Mar 21 11:27:58 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 21 Mar 2013 11:27:58 +0000
Subject: JAX-WS update coming soon
Message-ID: <514AEEBE.9050406@oracle.com>


Just a heads-up that there is a JAX-WS update coming for jdk8. Miroslav 
Kos will be sending a webrev soon with the changes that update what we 
have in jdk8 from 2.2.7-b09 to 2.2.9-b13922. The patch file is likely be 
 >100k lines so impossible to do a complete review. The tentative plan 
is to push this via jdk8/tl/jaxws and any help with the review would be 
appreciated.

-Alan.


From bourges.laurent at gmail.com  Thu Mar 21 12:05:27 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Thu, 21 Mar 2013 13:05:27 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due to
	HashMap leads to Integer allocations (boxing)
In-Reply-To: 
References: 
Message-ID: 

Here is the test code that was scrubbed in my previous email.

As you can see in my benchmarks:
- TLAB has a major impact on Integer allocation overhead
- patched code is 2x faster (with TLAB enabled)

Test code:

package test;

import java.util.logging.Level;
import java.util.logging.Logger;
import sun.util.logging.LoggingSupport;
import sun.util.logging.PlatformLogger;

/**
 * PlatformLogger patch Test (performance / memory overhead)
 * @author bourgesl
 */
public class PlatformLoggerTest {

    /** logger - enable java.util.logging to enable PlatformLogger using
JUL */
    private final static Logger logger =
Logger.getLogger(PlatformLoggerTest.class.getName());

    public static void main(String[] args) {

        /*
         * 1/ JVM options during tests:
         * -Xms8m -Xmx8m -XX:-UseTLAB -XX:+PrintTLAB
         *
         * JDK7_13 results:
         mars 21, 2013 11:15:07 AM test.PlatformLoggerTest main
         INFO: PlatformLoggerTest: start on JVM1.7.0_13 [Java HotSpot(TM)
64-Bit Server VM 23.7-b01]
         *
         INFO: testPerf[100000 iterations]: duration = 61.536460999999996
ms.
         INFO: PlatformLoggerTest: starting 100000000 iterations ...
         INFO: testPerf[100000000 iterations]: duration = 10485.07581 ms.
         INFO: testPerf[100000000 iterations]: duration = 10639.329926 ms.
         INFO: testPerf[100000000 iterations]: duration = 10903.235198 ms.
         INFO: testPerf[100000000 iterations]: duration = 10728.399372 ms.
         INFO: testPerf[100000000 iterations]: duration = 10643.329983 ms.
         INFO: testPerf[100000000 iterations]: duration = 10720.43687 ms.
         INFO: testPerf[100000000 iterations]: duration =
10864.371595999999 ms.
         INFO: testPerf[100000000 iterations]: duration = 10713.845459 ms.
         INFO: testPerf[100000000 iterations]: duration = 10458.257711 ms.
         INFO: testPerf[100000000 iterations]: duration = 10606.267606 ms.
         *
         * OpenJDK8 (+patch):
         mars 21, 2013 11:19:03 AM test.PlatformLoggerTest main
         Infos: PlatformLoggerTest: start on JVM1.8.0-internal [OpenJDK
64-Bit Server VM 25.0-b22]
         *
         Infos: testPerf[100000 iterations]: duration = 24.862816 ms.
         Infos: PlatformLoggerTest: starting 100000000 iterations ...
         Infos: testPerf[100000000 iterations]: duration = 1043.957166 ms.
         Infos: testPerf[100000000 iterations]: duration = 1013.602486 ms.
         Infos: testPerf[100000000 iterations]: duration =
1018.2792629999999 ms.
         Infos: testPerf[100000000 iterations]: duration = 1073.422125 ms.
         Infos: testPerf[100000000 iterations]: duration = 1024.742149 ms.
         Infos: testPerf[100000000 iterations]: duration =
1021.3166339999999 ms.
         Infos: testPerf[100000000 iterations]: duration = 1014.771751 ms.
         Infos: testPerf[100000000 iterations]: duration =
1017.6148959999999 ms.
         Infos: testPerf[100000000 iterations]: duration =
1021.4425389999999 ms.
         Infos: testPerf[100000000 iterations]: duration = 1020.200104 ms.
         *
         * 2/ JVM options during tests:
         * -Xms8m -Xmx8m -XX:+UseTLAB
         *
         * JDK7_13 results:
         * mars 21, 2013 12:58:37 PM test.PlatformLoggerTest main
         INFO: PlatformLoggerTest: start on JVM1.7.0_13 [Java HotSpot(TM)
64-Bit Server VM 23.7-b01]
         *
         INFO: testPerf[100000 iterations]: duration = 55.329637 ms.
         INFO: PlatformLoggerTest: starting 100000000 iterations ...
         INFO: testPerf[100000000 iterations]: duration = 2553.872667 ms.
         INFO: testPerf[100000000 iterations]: duration = 2327.072791 ms.
         INFO: testPerf[100000000 iterations]: duration = 2324.000677 ms.
         INFO: testPerf[100000000 iterations]: duration =
2326.0859929999997 ms.
         INFO: testPerf[100000000 iterations]: duration = 2325.34332 ms.
         INFO: testPerf[100000000 iterations]: duration = 2322.579729 ms.
         INFO: testPerf[100000000 iterations]: duration = 2322.170814 ms.
         INFO: testPerf[100000000 iterations]: duration = 2324.055535 ms.
         INFO: testPerf[100000000 iterations]: duration =
2432.6784829999997 ms.
         INFO: testPerf[100000000 iterations]: duration = 2335.47692 ms.
         *
         * OpenJDK8 (+patch):
         mars 21, 2013 1:00:30 PM test.PlatformLoggerTest main
         Infos: PlatformLoggerTest: start on JVM1.8.0-internal [OpenJDK
64-Bit Server VM 25.0-b22]
         *
         Infos: testPerf[100000 iterations]: duration = 22.091089999999998
ms.
         Infos: PlatformLoggerTest: starting 100000000 iterations ...
         Infos: testPerf[100000000 iterations]: duration = 1023.84232 ms.
         Infos: testPerf[100000000 iterations]: duration =
1010.5437909999999 ms.
         Infos: testPerf[100000000 iterations]: duration =
1004.6675389999999 ms.
         Infos: testPerf[100000000 iterations]: duration =
1005.2778669999999 ms.
         Infos: testPerf[100000000 iterations]: duration = 1017.892527 ms.
         Infos: testPerf[100000000 iterations]: duration = 1006.359113 ms.
         Infos: testPerf[100000000 iterations]: duration = 1006.2957 ms.
         Infos: testPerf[100000000 iterations]: duration =
1008.3199189999999 ms.
         Infos: testPerf[100000000 iterations]: duration =
1001.7142339999999 ms.
         Infos: testPerf[100000000 iterations]: duration = 997.141141 ms.
         *
         * That's all folks!
         */

        // JVM options: -Xms8m -Xmx8m -verbose:gc -XX:-UseTLAB
-XX:+PrintTLAB

        // Note: -XX:-UseTLAB because Thread local allocator is efficient
to support Integer allocations

        logger.info("PlatformLoggerTest: start on JVM" +
System.getProperty("java.version") + " [" + System.getProperty("java.vm.name")
+ " " + System.getProperty("java.vm.version") + "]");


        logger.info("PlatformLoggerTest: LoggingSupport.isAvailable() = " +
LoggingSupport.isAvailable());

        PlatformLogger.redirectPlatformLoggers();

        final PlatformLogger log = PlatformLogger.getLogger("sun.awt.X11");

        log.setLevel(PlatformLogger.INFO);

        final boolean testEnabledLogs = false;

        logger.info("PlatformLogger: enabled = " + log.isEnabled());
        logger.info("PlatformLogger: level = " + log.getLevel());

        /*
         for (Enumeration e =
LogManager.getLogManager().getLoggerNames(); e.hasMoreElements();) {
         logger.info("PlatformLoggerTest: logger[" + e.nextElement() + "]");
         }
         */

        // Cleanup before test:
        cleanup();


        int nLog = 0;

        final int WARMUP = 100 * 1000;

        long start = System.nanoTime();

        for (int i = 0; i < WARMUP; i++) {

            if (log.isLoggable(PlatformLogger.FINEST)) {
                log.finest("test PlatformLogger.FINEST");
                nLog++; // ensure hotspot do not skip isLoggable()
            } else {
                nLog--;
            }

            if (log.isLoggable(PlatformLogger.FINE)) {
                log.fine("test PlatformLogger.FINE");
                nLog++; // ensure hotspot do not skip isLoggable()
            } else {
                nLog--;
            }

            if (log.isLoggable(PlatformLogger.FINER)) {
                log.finer("test PlatformLogger.FINER");
                nLog++; // ensure hotspot do not skip isLoggable()
            } else {
                nLog--;
            }

            if (log.isLoggable(PlatformLogger.CONFIG)) {
                log.config("test PlatformLogger.CONFIG");
                nLog++; // ensure hotspot do not skip isLoggable()
            } else {
                nLog--;
            }

            if (testEnabledLogs) {
                if (log.isLoggable(PlatformLogger.INFO)) {
                    log.info("test PlatformLogger.INFO");
                    nLog++; // ensure hotspot do not skip isLoggable()
                } else {
                    nLog--;
                }

                if (log.isLoggable(PlatformLogger.WARNING)) {
                    log.warning("test PlatformLogger.WARNING");
                    nLog++; // ensure hotspot do not skip isLoggable()
                } else {
                    nLog--;
                }

                if (log.isLoggable(PlatformLogger.SEVERE)) {
                    log.severe("test PlatformLogger.SEVERE");
                    nLog++; // ensure hotspot do not skip isLoggable()
                } else {
                    nLog--;
                }

                if (log.isLoggable(PlatformLogger.OFF)) {
                    log.severe("test PlatformLogger.OFF");
                    nLog++; // ensure hotspot do not skip isLoggable()
                } else {
                    nLog--;
                }
            }
        }

        log.info("testPerf[" + WARMUP + " iterations]: duration = " +
(1e-6d * (System.nanoTime() - start)) + " ms.");
        log.info("testPerf: nLog = " + nLog);
        cleanup();


        final int PASS = 10;
        final int N = 100 * 1000 * 1000;
        logger.info("PlatformLoggerTest: starting " + N + " iterations
...");

        for (int j = 0; j < PASS; j++) {
            nLog = 0;
            start = System.nanoTime();

            for (int i = 0; i < N; i++) {

                if (log.isLoggable(PlatformLogger.FINEST)) {
                    log.finest("test PlatformLogger.FINEST");
                    nLog++; // ensure hotspot do not skip isLoggable()
                } else {
                    nLog--;
                }

                if (log.isLoggable(PlatformLogger.FINE)) {
                    log.fine("test PlatformLogger.FINE");
                    nLog++; // ensure hotspot do not skip isLoggable()
                } else {
                    nLog--;
                }

                if (log.isLoggable(PlatformLogger.FINER)) {
                    log.finer("test PlatformLogger.FINER");
                    nLog++; // ensure hotspot do not skip isLoggable()
                } else {
                    nLog--;
                }

                if (log.isLoggable(PlatformLogger.CONFIG)) {
                    log.config("test PlatformLogger.CONFIG");
                    nLog++; // ensure hotspot do not skip isLoggable()
                } else {
                    nLog--;
                }

                if (testEnabledLogs) {
                    if (log.isLoggable(PlatformLogger.INFO)) {
                        log.info("test PlatformLogger.INFO");
                        nLog++; // ensure hotspot do not skip isLoggable()
                    } else {
                        nLog--;
                    }

                    if (log.isLoggable(PlatformLogger.WARNING)) {
                        log.warning("test PlatformLogger.WARNING");
                        nLog++; // ensure hotspot do not skip isLoggable()
                    } else {
                        nLog--;
                    }

                    if (log.isLoggable(PlatformLogger.SEVERE)) {
                        log.severe("test PlatformLogger.SEVERE");
                        nLog++; // ensure hotspot do not skip isLoggable()
                    } else {
                        nLog--;
                    }

                    if (log.isLoggable(PlatformLogger.OFF)) {
                        log.severe("test PlatformLogger.OFF");
                        nLog++; // ensure hotspot do not skip isLoggable()
                    } else {
                        nLog--;
                    }
                }
            }

            log.info("testPerf[" + N + " iterations]: duration = " + (1e-6d
* (System.nanoTime() - start)) + " ms.");
            log.info("testPerf: nLog = " + nLog);
            cleanup();
        }

        try {
            Thread.sleep(1000l);
        } catch (InterruptedException ie) {
            logger.log(Level.SEVERE, "Interrupted", ie);
        }

        logger.info("PlatformLoggerTest: exit.");
    }

    /**
     * Cleanup (GC + pause)
     */
    private static void cleanup() {
        // Perform GC:
        System.gc();

        // pause:
        try {
            Thread.sleep(100l);
        } catch (InterruptedException ie) {
        }
    }
}

2013/3/21 Laurent Bourg?s 

> Here is an improved patch tested on JDK7u13 and JDK8 internal build on my
> machine linux x64:
> http://jmmc.fr/~bourgesl/share/webrev-8010309/
>
> FYI, I removed completely the Map levelObjects and used
> two arrays to perform the PlatformLogger's level (int) to j.u.l.Level
> mapping:
>
> I decided to keep it simple as possible (no enum ...) and used a switch
> case based on current level occurences:
>
>  510         /**
>  511          * Return the corresponding j.u.l.Level instance
>  512          * @param level PlatformLogger level as integer
>
>  513          * @return Object (j.u.l.Level instance) or null if no matching level
>  514          */
>  515         private static Object getLevel(final int level) {
>  516             if (levelObjects == null) {
>  517                 return null;
>
>  518             }
>  519             // higher occurences first (finest, fine, finer, info)
>  520             // based on isLoggable(level) calls (03/20/2013)
>  521             // in jdk project only (including generated sources)
>
>  522             switch (level) {
>  523                 case FINEST  : return levelObjects[IDX_FINEST];  // 116 + 2257 matches in generated files
>  524                 case FINE    : return levelObjects[IDX_FINE];    // 270
>
>  525                 case FINER   : return levelObjects[IDX_FINER];   // 157
>  526                 case INFO    : return levelObjects[IDX_INFO];    // 39
>  527                 case WARNING : return levelObjects[IDX_WARNING]; // 12
>
>  528                 case CONFIG  : return levelObjects[IDX_CONFIG];  // 6
>  529                 case SEVERE  : return levelObjects[IDX_SEVERE];  // 1
>  530                 case OFF     : return levelObjects[IDX_OFF];     // 0
>
>  531                 case ALL     : return levelObjects[IDX_ALL];     // 0
>  532                 default      : return null;
>  533             }
>  534         }
>
> I enhanced the PlatformLoggerTest class also and figured out that TLAB
> optimized Integer allocations but I think the patch is still useful.
>
> Can you have a look to the patch ?
> Should I write a jtreg test  (performance / GC issue) ?
>
> Cheers,
> Laurent
>
>
> 2013/3/20 Mandy Chung 
>
>>  Hi Laurent,
>>
>> Thank you for signing the OCA.  Your contribution is very welcome.  You
>> can submit a patch for this bug (see [1]) to Core libraries group which
>> owns logging.  Jim Gish and I will sponsor it.
>>
>> Thanks
>> Mandy
>> [1] http://openjdk.java.net/contribute/
>>
>>
>> On 3/20/2013 5:45 AM, Laurent Bourg?s wrote:
>>
>> Hi mandy,
>>
>> Do you want me to propose an improved patch to remove the former Map and
>> fix the getLevel() method ? or you prefer fix on your own ?
>>
>> Is it better to discuss the fix on the bug database (still not visible) ?
>>
>> Laurent
>>
>> 2013/3/19 Mandy Chung 
>>
>>>  Hi Laurent,
>>>
>>> Thanks for the contribution.  I agree that the map can be replaced with
>>> a direct mapping from a int value to Level object and avoid the autoboxing
>>> conversion.
>>>
>>> I have filed a bug to track this and target this for JDK8:
>>>   http://bugs.sun.com/bugdatabase/view_bug.do?bug_id= 8010309
>>>
>>> Thanks
>>> Mandy
>>>
>>>
>>> On 3/19/13 5:19 AM, Laurent Bourg?s wrote:
>>>
>>> Dear all,
>>>
>>> I run recently netbeans profiler on my swing application (Aspro2:http://www.jmmc.fr/aspro
>>> ) under linux x64 platform and figured out a
>>> performance and waste issue related to PlatformLogger.
>>>
>>> Actually, the JavaLogger implementation uses a Map
>>> levelObjects to store mapping between PlatformLogger's levels (int) and JUL
>>> Level instances.
>>>
>>> However, the isLoggable(int level) method is highly used by awt project and
>>> other JDK projects and it leads to many Integer allocations as autoboxing
>>> converts the level as int to an Integer instance used by the Map.get() call.
>>>
>>>     /**
>>>      * JavaLogger forwards all the calls to its corresponding
>>>      * java.util.logging.Logger object.
>>>      */
>>>     static class JavaLogger extends LoggerProxy {
>>>         private static final* Map* levelObjects = new
>>> HashMap<>();
>>> ...
>>>         public boolean isLoggable(*int level*) {
>>>             return LoggingSupport.isLoggable(javaLogger, *
>>> levelObjects.get(level)*);
>>>         }
>>>     }
>>>
>>> I wrote a simple test to illustrate that performance / waste problem:
>>> PlatformLoggerTest that simply performs 1 million DISABLED log statements:
>>>             if (log.isLoggable(PlatformLogger.FINEST)) {
>>>                 log.finest("test PlatformLogger.FINEST");
>>>             }
>>>
>>> As you can see in screenshots:
>>> - 5 million Integer instances are allocated
>>> - Integer.valueOf(int) is called 5 million times (autoboxing)
>>> - HashMap.get() represents 30% of the test time
>>> - patched PlatformLogger is 3x times faster
>>> [jvm options: -Xms8m -Xmx8m -verbose:gc]
>>>
>>> I suggest you to use an alternative way to map PlatformLogger's levels
>>> (int) and JUL Level instances to fix that performance / memory issue: I
>>> added the getLevel(int level) method that performs a switch case to return
>>> the corresponding Level object (quick and dirty solution).
>>>
>>> I advocate this is not a very clean solution but I prefer efficiency here:
>>> any better solution may be appropriate to avoid at least Integer allocation
>>> and maybe enhance performance.
>>>
>>> Best regards,
>>> Laurent Bourg?s
>>>
>>> PS: here is the patch as text:
>>>
>>> # This patch file was generated by NetBeans IDE
>>> # It uses platform neutral UTF-8 encoding and \n newlines.
>>> --- PlatformLogger.java (6767)
>>> +++ PlatformLogger.java (6768)
>>> @@ -468,31 +468,13 @@
>>>       * java.util.logging.Logger object.
>>>       */
>>>      static class JavaLogger extends LoggerProxy {
>>> -        /** Note: using Integer keys leads to a lot of new Integer
>>> instances !! */
>>> -        private static final Map levelObjects = new
>>> HashMap<>();
>>> -        /** fastest mapping to Level instances from PlatformLogger level
>>> as integer */
>>> -        private static final Object[] fastLevelObjects;
>>> -
>>> -
>>> +        private static final Map levelObjects =
>>> +            new HashMap<>();
>>> +
>>>          static {
>>>              if (LoggingSupport.isAvailable()) {
>>>                  // initialize the map to Level objects
>>>                  getLevelObjects();
>>> -
>>> -                // initialize the fastLevelObjects:
>>> -                fastLevelObjects = new Object[] {
>>> -                    LoggingSupport.parseLevel(getLevelName(OFF)),       //
>>> 0
>>> -                    LoggingSupport.parseLevel(getLevelName(SEVERE)),    //
>>> 1
>>> -                    LoggingSupport.parseLevel(getLevelName(WARNING)),   //
>>> 2
>>> -                    LoggingSupport.parseLevel(getLevelName(INFO)),      //
>>> 3
>>> -                    LoggingSupport.parseLevel(getLevelName(CONFIG)),    //
>>> 4
>>> -                    LoggingSupport.parseLevel(getLevelName(FINE)),      //
>>> 5
>>> -                    LoggingSupport.parseLevel(getLevelName(FINER)),     //
>>> 6
>>> -                    LoggingSupport.parseLevel(getLevelName(FINEST)),    //
>>> 7
>>> -                    LoggingSupport.parseLevel(getLevelName(ALL))        //
>>> 8
>>> -                };
>>> -            } else {
>>> -                fastLevelObjects = null; // check null
>>>              }
>>>          }
>>>
>>> @@ -515,7 +497,7 @@
>>>              this.javaLogger = LoggingSupport.getLogger(name);
>>>              if (level != 0) {
>>>                  // level has been updated and so set the Logger's level
>>> -                LoggingSupport.setLevel(javaLogger, getLevel(level));
>>> +                LoggingSupport.setLevel(javaLogger,
>>> levelObjects.get(level));
>>>              }
>>>          }
>>>
>>> @@ -526,11 +508,11 @@
>>>          * not be updated.
>>>          */
>>>          void doLog(int level, String msg) {
>>> -            LoggingSupport.log(javaLogger, getLevel(level), msg);
>>> +            LoggingSupport.log(javaLogger, levelObjects.get(level), msg);
>>>          }
>>>
>>>          void doLog(int level, String msg, Throwable t) {
>>> -            LoggingSupport.log(javaLogger, getLevel(level), msg, t);
>>> +            LoggingSupport.log(javaLogger, levelObjects.get(level), msg,
>>> t);
>>>          }
>>>
>>>          void doLog(int level, String msg, Object... params) {
>>> @@ -544,12 +526,12 @@
>>>              for (int i = 0; i < len; i++) {
>>>                  sparams [i] = String.valueOf(params[i]);
>>>              }
>>> -            LoggingSupport.log(javaLogger, getLevel(level), msg, sparams);
>>> +            LoggingSupport.log(javaLogger, levelObjects.get(level), msg,
>>> sparams);
>>>          }
>>>
>>>          boolean isEnabled() {
>>>              Object level = LoggingSupport.getLevel(javaLogger);
>>> -            return level == null || level.equals(getLevel(OFF)) == false;
>>> +            return level == null || level.equals(levelObjects.get(OFF)) ==
>>> false;
>>>          }
>>>
>>>          int getLevel() {
>>> @@ -566,34 +548,12 @@
>>>
>>>          void setLevel(int newLevel) {
>>>              levelValue = newLevel;
>>> -            LoggingSupport.setLevel(javaLogger, getLevel(newLevel));
>>> +            LoggingSupport.setLevel(javaLogger,
>>> levelObjects.get(newLevel));
>>>          }
>>>
>>>          public boolean isLoggable(int level) {
>>> -            return LoggingSupport.isLoggable(javaLogger, getLevel(level));
>>> +            return LoggingSupport.isLoggable(javaLogger,
>>> levelObjects.get(level));
>>>          }
>>> -
>>> -        /**
>>> -         * Return the corresponding level object (fastest implementation)
>>> -         * @param level PlatformLogger level as primitive integer
>>> -         * @return Object (JUL Level instance)
>>> -         */
>>> -        private static Object getLevel(final int level) {
>>> -            // higher occurences first (finest, fine, finer, info):
>>> -            switch (level) {
>>> -                case FINEST  : return fastLevelObjects[7];
>>> -                case FINE    : return fastLevelObjects[5];
>>> -                case FINER   : return fastLevelObjects[6];
>>> -                case INFO    : return fastLevelObjects[3];
>>> -                case CONFIG  : return fastLevelObjects[4];
>>> -                case WARNING : return fastLevelObjects[2];
>>> -                case SEVERE  : return fastLevelObjects[1];
>>> -                case ALL     : return fastLevelObjects[8];
>>> -                case OFF     : return fastLevelObjects[0];
>>> -                default      : return null;
>>> -            }
>>> -        }
>>> -
>>>      }
>>>
>>>      private static String getLevelName(int level) {
>>>
>>>
>>>
>>
>>
>


From Ulf.Zibis at CoSoCo.de  Thu Mar 21 12:29:36 2013
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Thu, 21 Mar 2013 13:29:36 +0100
Subject: Please review: surrogate fiddle
In-Reply-To: 
References: 
	
	
	<5147D0F8.3090101@oracle.com>
	
	<51480152.5010102@oracle.com>
	
	
	<5148B539.4020508@oracle.com>
	
	<5149C30E.1080405@CoSoCo.de>
	
Message-ID: <514AFD30.7010602@CoSoCo.de>

Am 21.03.2013 00:22, schrieb Martin Buchholz:
> On Wed, Mar 20, 2013 at 7:09 AM, Ulf Zibis > wrote:
>
>     AbstractStringBuilder:
>     Instead
>      270     public int codePointBefore(int index) {
>      271         int i = index - 1;
>      272         if ((i < 0) || (i >= count)) {
>      273             throw new StringIndexOutOfBoundsException(index);
>      274         }
>     I suggest
>      270     public int codePointBefore(int index) {
>      271         if ((--index < 0) || (index >= count)) {
>      272             throw new StringIndexOutOfBoundsException(index);
>      273         }
>     , because if e.g. the initial value of index is 0, then -1 reflects the out-of-bound
>     condition, but not the initial 0 to report in the StringIndexOutOfBoundsException.
>     (Hopefully the following redundant i < 0 bounds check from value[i] becomes elimited by JIT.)
>
>
> I was impressed that hotspot could indeed remove the redundant bounds checks.
> Only with -Xint was I able to demonstrate a performance win.

Thanks!
But what's about the "wrong" exception index reporting, e.g. 0 as "out of bounds"?


>     If there is some register pressure, you could avoid potential register swapping for temp,
>     temp2, hasSurrogate, j and n - j if you would reorder following lines to:
>     1390             char temp = value[j];
>     1391             char temp2 = value[j] = value[n - j];
>     1397             value[n - j] = temp;
>     1392             if (!hasSurrogate) {
>     1393                 hasSurrogate = (Character.isSurrogate(temp) ||
>     1394 Character.isSurrogate(temp2));
>     1395             }
>     (Nomination for "performance expert II" ?)
>
>
> Thanks for making me beat my head against the hotspot optimization wall!
> The latest version of reverse in my webrev, after way too much fiddling, is 20% faster,
> even though I'm not quite sure why.

No surprise to me. In ordinary strings (no surrogate pairs), always 3 checks should be processed 
each loop:
- if (!hasSurrogate)
- Character.isSurrogate(temp)
- Character.isSurrogate(temp2)

The "if (!hasSurrogate)" only helps a little, if a surrogate pair was found in 1st half of the 
string, but the gain should be small in relation to the extra work, scanning the string again for 
reversing them.

Did you try the more smart syntax? :
     hasSurrogate =
         (Character.isSurrogate(cj) || Character.isSurrogate(ck));


> If you write tests, I will incorporate into this changeset!

I have no java development environment here and small time, so depends on your patience to commit 
the changeset.

-Ulf




From holger.hoffstaette at googlemail.com  Thu Mar 21 12:04:38 2013
From: holger.hoffstaette at googlemail.com (Holger Hoffstaette)
Date: Thu, 21 Mar 2013 13:04:38 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due to
	HashMap leads to Integer allocations (boxing)
References: 
Message-ID: 

On Thu, 21 Mar 2013 12:12:07 +0100, Laurent Bourg?s wrote:

[..]
> FYI, I removed completely the Map levelObjects and used
> two arrays to perform the PlatformLogger's level (int) to j.u.l.Level
> mapping:
[..]

FWIW I know of at least one (quite old) project that declares custom
j.u.l. Levels and which would be broken by this change. I personally don't
care (since I think both j.u.l. and custom log levels are wrong to begin
with :), but it's something to keep in mind. Maybe a Map-based mapping
could be used as fallback, while the array-indexed lookups take the heat
off of the common case. Just a suggestion.

cheers
Holger




From Ulf.Zibis at CoSoCo.de  Thu Mar 21 12:56:11 2013
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Thu, 21 Mar 2013 13:56:11 +0100
Subject: Please review: surrogate fiddle
In-Reply-To: 
References: 
	
	
	<5147D0F8.3090101@oracle.com>
	
	<51480152.5010102@oracle.com>
	
	
	<5148B539.4020508@oracle.com>
	
	<5149C30E.1080405@CoSoCo.de>
	
Message-ID: <514B036B.70408@CoSoCo.de>

Am 21.03.2013 00:22, schrieb Martin Buchholz:

    AbstractStringBuilder:
    Instead
      270     public int codePointBefore(int index) {
      271         int i = index - 1;
      272         if ((i < 0) || (i >= count)) {
      273             throw new StringIndexOutOfBoundsException(index);
      274         }
    I suggest
      270     public int codePointBefore(int index) {
      271         if ((--index < 0) || (index >= count)) {
      272             throw new StringIndexOutOfBoundsException(index);
      273         }
    , because if e.g. the initial value of index is 0, then -1 reflects the out-of-bound condition,
    but not the initial 0 to report in the StringIndexOutOfBoundsException.
    (Hopefully the following redundant i < 0 bounds check from value[i] becomes elimited by JIT.)


Additional suggestions:
  231      * @exception  _String_IndexOutOfBoundsException  ...
  235     public int codePointAt(int index) {

  259      * @exception _String_IndexOutOfBoundsException  ...
  263     public int codePointBefore(int index) {

For what it's worth to throw the more verbose StringIndexOutOfBoundsException, if it's not mentioned 
in the spec?

Additional nit:
In line 231 there is an extra space before and behind IndexOutOfBoundsException (the behind one I 
would like to see everywhere), but in most cases of @param and @exception, the 2nd space is missing. 
Anyway @throws would be better than @exception

-Ulf



From Ulf.Zibis at CoSoCo.de  Thu Mar 21 13:09:10 2013
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Thu, 21 Mar 2013 14:09:10 +0100
Subject: Please review: surrogate fiddle
In-Reply-To: <5149CF25.1000308@oracle.com>
References: 
	
	
	<5147D0F8.3090101@oracle.com>
	
	<51480152.5010102@oracle.com>
	
	
	<5148B539.4020508@oracle.com>
	
	<5149C30E.1080405@CoSoCo.de> <5149CF25.1000308@oracle.com>
Message-ID: <514B0676.7030700@CoSoCo.de>

Am 20.03.2013 16:00, schrieb Alexander Zuev:
>> AbstractStringBuilder:
>> Instead
>> 270 public int codePointBefore(int index) {
>> 271 int i = index - 1;
>> 272 if ((i < 0) || (i >= count)) {
>> 273 throw new StringIndexOutOfBoundsException(index);
>> 274 }
>> I suggest
>> 270 public int codePointBefore(int index) {
>> 271 if ((--index < 0) || (index >= count)) {
>> 272 throw new StringIndexOutOfBoundsException(index);
>> 273 }
>> , because if e.g. the initial value of index is 0, then -1 reflects the out-of-bound condition, 
>> but not the initial 0 to report in the StringIndexOutOfBoundsException.
> OTOH in case of upper index out of bounds with your code we will report exception reporting number 
> laying within the allowed range which may be confusing.

Yes, difficult to decide, but keep in the back of your mind, it's called 
_String_IndexOutOfBoundsException, not _CodepointAt_IndexOutOfBoundsException

> Just my $.02

adding my -,02 ?

-Ulf



From Ulf.Zibis at CoSoCo.de  Thu Mar 21 13:16:19 2013
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Thu, 21 Mar 2013 14:16:19 +0100
Subject: Please review: surrogate fiddle
In-Reply-To: <514B0676.7030700@CoSoCo.de>
References: 
	
	
	<5147D0F8.3090101@oracle.com>
	
	<51480152.5010102@oracle.com>
	
	
	<5148B539.4020508@oracle.com>
	
	<5149C30E.1080405@CoSoCo.de> <5149CF25.1000308@oracle.com>
	<514B0676.7030700@CoSoCo.de>
Message-ID: <514B0823.9050105@CoSoCo.de>

Am 21.03.2013 14:09, schrieb Ulf Zibis:
> Yes, difficult to decide, but keep in the back of your mind, it's called 
> _String_IndexOutOfBoundsException, not _CodepointAt_IndexOutOfBoundsException

Oops, I meant
... _CodePointBefore_IndexOutOfBoundsException



From bourges.laurent at gmail.com  Thu Mar 21 13:33:48 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Thu, 21 Mar 2013 14:33:48 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due to
	HashMap leads to Integer allocations (boxing)
In-Reply-To: 
References: 
	
Message-ID: 

Holger,

you are right: PlatformLogger does not care about custom Level
implementations because it relies on j.u.l.Logger to decide if the message
should be logged or not:

 609         public boolean isLoggable(int level) {
 610             return LoggingSupport.isLoggable(javaLogger, getLevel(level));
 611         }

The former Map levelObjects I removed was only used to get
the j.u.l.Level instance corresponding to a PlatformLogger's level which
are defined as int constants.

FYI, the former map was filled with only j.u.l.Level instances
corresponding to all PlatformLogger's levels:

 481         private static void getLevelObjects() {
 482             // get all java.util.logging.Level objects
 483             int[] levelArray = new int[] {OFF, SEVERE, WARNING,
INFO, CONFIG, FINE, FINER, FINEST, ALL};
 484             for (int l : levelArray) {
 485                 Object level = LoggingSupport.parseLevel(getLevelName(l));
 486                 levelObjects.put(l, level);
 487             }
 488         }

I think I did not change the scope of the mapping i.e. PlatformLogger's
levels.

Cheers,
Laurent

2013/3/21 Laurent Bourg?s 

> Here is the test code that was scrubbed in my previous email.
>
> As you can see in my benchmarks:
> - TLAB has a major impact on Integer allocation overhead
> - patched code is 2x faster (with TLAB enabled)
>
> Test code:
>
> package test;
>
> import java.util.logging.Level;
> import java.util.logging.Logger;
> import sun.util.logging.LoggingSupport;
> import sun.util.logging.PlatformLogger;
>
> /**
>  * PlatformLogger patch Test (performance / memory overhead)
>  * @author bourgesl
>  */
> public class PlatformLoggerTest {
>
>     /** logger - enable java.util.logging to enable PlatformLogger using
> JUL */
>     private final static Logger logger =
> Logger.getLogger(PlatformLoggerTest.class.getName());
>
>     public static void main(String[] args) {
>
>         /*
>          * 1/ JVM options during tests:
>          * -Xms8m -Xmx8m -XX:-UseTLAB -XX:+PrintTLAB
>          *
>          * JDK7_13 results:
>          mars 21, 2013 11:15:07 AM test.PlatformLoggerTest main
>          INFO: PlatformLoggerTest: start on JVM1.7.0_13 [Java HotSpot(TM)
> 64-Bit Server VM 23.7-b01]
>          *
>          INFO: testPerf[100000 iterations]: duration = 61.536460999999996
> ms.
>          INFO: PlatformLoggerTest: starting 100000000 iterations ...
>          INFO: testPerf[100000000 iterations]: duration = 10485.07581 ms.
>          INFO: testPerf[100000000 iterations]: duration = 10639.329926 ms.
>          INFO: testPerf[100000000 iterations]: duration = 10903.235198 ms.
>          INFO: testPerf[100000000 iterations]: duration = 10728.399372 ms.
>          INFO: testPerf[100000000 iterations]: duration = 10643.329983 ms.
>          INFO: testPerf[100000000 iterations]: duration = 10720.43687 ms.
>          INFO: testPerf[100000000 iterations]: duration =
> 10864.371595999999 ms.
>          INFO: testPerf[100000000 iterations]: duration = 10713.845459 ms.
>          INFO: testPerf[100000000 iterations]: duration = 10458.257711 ms.
>          INFO: testPerf[100000000 iterations]: duration = 10606.267606 ms.
>          *
>          * OpenJDK8 (+patch):
>          mars 21, 2013 11:19:03 AM test.PlatformLoggerTest main
>          Infos: PlatformLoggerTest: start on JVM1.8.0-internal [OpenJDK
> 64-Bit Server VM 25.0-b22]
>          *
>          Infos: testPerf[100000 iterations]: duration = 24.862816 ms.
>          Infos: PlatformLoggerTest: starting 100000000 iterations ...
>          Infos: testPerf[100000000 iterations]: duration = 1043.957166 ms.
>          Infos: testPerf[100000000 iterations]: duration = 1013.602486 ms.
>          Infos: testPerf[100000000 iterations]: duration =
> 1018.2792629999999 ms.
>          Infos: testPerf[100000000 iterations]: duration = 1073.422125 ms.
>          Infos: testPerf[100000000 iterations]: duration = 1024.742149 ms.
>          Infos: testPerf[100000000 iterations]: duration =
> 1021.3166339999999 ms.
>          Infos: testPerf[100000000 iterations]: duration = 1014.771751 ms.
>          Infos: testPerf[100000000 iterations]: duration =
> 1017.6148959999999 ms.
>          Infos: testPerf[100000000 iterations]: duration =
> 1021.4425389999999 ms.
>          Infos: testPerf[100000000 iterations]: duration = 1020.200104 ms.
>          *
>          * 2/ JVM options during tests:
>          * -Xms8m -Xmx8m -XX:+UseTLAB
>          *
>          * JDK7_13 results:
>          * mars 21, 2013 12:58:37 PM test.PlatformLoggerTest main
>          INFO: PlatformLoggerTest: start on JVM1.7.0_13 [Java HotSpot(TM)
> 64-Bit Server VM 23.7-b01]
>          *
>          INFO: testPerf[100000 iterations]: duration = 55.329637 ms.
>          INFO: PlatformLoggerTest: starting 100000000 iterations ...
>          INFO: testPerf[100000000 iterations]: duration = 2553.872667 ms.
>          INFO: testPerf[100000000 iterations]: duration = 2327.072791 ms.
>          INFO: testPerf[100000000 iterations]: duration = 2324.000677 ms.
>          INFO: testPerf[100000000 iterations]: duration =
> 2326.0859929999997 ms.
>          INFO: testPerf[100000000 iterations]: duration = 2325.34332 ms.
>          INFO: testPerf[100000000 iterations]: duration = 2322.579729 ms.
>          INFO: testPerf[100000000 iterations]: duration = 2322.170814 ms.
>          INFO: testPerf[100000000 iterations]: duration = 2324.055535 ms.
>          INFO: testPerf[100000000 iterations]: duration =
> 2432.6784829999997 ms.
>          INFO: testPerf[100000000 iterations]: duration = 2335.47692 ms.
>          *
>          * OpenJDK8 (+patch):
>          mars 21, 2013 1:00:30 PM test.PlatformLoggerTest main
>          Infos: PlatformLoggerTest: start on JVM1.8.0-internal [OpenJDK
> 64-Bit Server VM 25.0-b22]
>          *
>          Infos: testPerf[100000 iterations]: duration = 22.091089999999998
> ms.
>          Infos: PlatformLoggerTest: starting 100000000 iterations ...
>          Infos: testPerf[100000000 iterations]: duration = 1023.84232 ms.
>          Infos: testPerf[100000000 iterations]: duration =
> 1010.5437909999999 ms.
>          Infos: testPerf[100000000 iterations]: duration =
> 1004.6675389999999 ms.
>          Infos: testPerf[100000000 iterations]: duration =
> 1005.2778669999999 ms.
>          Infos: testPerf[100000000 iterations]: duration = 1017.892527 ms.
>          Infos: testPerf[100000000 iterations]: duration = 1006.359113 ms.
>          Infos: testPerf[100000000 iterations]: duration = 1006.2957 ms.
>          Infos: testPerf[100000000 iterations]: duration =
> 1008.3199189999999 ms.
>          Infos: testPerf[100000000 iterations]: duration =
> 1001.7142339999999 ms.
>          Infos: testPerf[100000000 iterations]: duration = 997.141141 ms.
>          *
>          * That's all folks!
>          */
>
>         // JVM options: -Xms8m -Xmx8m -verbose:gc -XX:-UseTLAB
> -XX:+PrintTLAB
>
>         // Note: -XX:-UseTLAB because Thread local allocator is efficient
> to support Integer allocations
>
>         logger.info("PlatformLoggerTest: start on JVM" +
> System.getProperty("java.version") + " [" + System.getProperty("
> java.vm.name") + " " + System.getProperty("java.vm.version") + "]");
>
>
>         logger.info("PlatformLoggerTest: LoggingSupport.isAvailable() = "
> + LoggingSupport.isAvailable());
>
>         PlatformLogger.redirectPlatformLoggers();
>
>         final PlatformLogger log = PlatformLogger.getLogger("sun.awt.X11");
>
>         log.setLevel(PlatformLogger.INFO);
>
>         final boolean testEnabledLogs = false;
>
>         logger.info("PlatformLogger: enabled = " + log.isEnabled());
>         logger.info("PlatformLogger: level = " + log.getLevel());
>
>         /*
>          for (Enumeration e =
> LogManager.getLogManager().getLoggerNames(); e.hasMoreElements();) {
>          logger.info("PlatformLoggerTest: logger[" + e.nextElement() +
> "]");
>          }
>          */
>
>         // Cleanup before test:
>         cleanup();
>
>
>         int nLog = 0;
>
>         final int WARMUP = 100 * 1000;
>
>         long start = System.nanoTime();
>
>         for (int i = 0; i < WARMUP; i++) {
>
>
>             if (log.isLoggable(PlatformLogger.FINEST)) {
>                 log.finest("test PlatformLogger.FINEST");
>                 nLog++; // ensure hotspot do not skip isLoggable()
>             } else {
>                 nLog--;
>             }
>
>             if (log.isLoggable(PlatformLogger.FINE)) {
>                 log.fine("test PlatformLogger.FINE");
>                 nLog++; // ensure hotspot do not skip isLoggable()
>             } else {
>                 nLog--;
>             }
>
>             if (log.isLoggable(PlatformLogger.FINER)) {
>                 log.finer("test PlatformLogger.FINER");
>                 nLog++; // ensure hotspot do not skip isLoggable()
>             } else {
>                 nLog--;
>             }
>
>             if (log.isLoggable(PlatformLogger.CONFIG)) {
>                 log.config("test PlatformLogger.CONFIG");
>                 nLog++; // ensure hotspot do not skip isLoggable()
>             } else {
>                 nLog--;
>             }
>
>             if (testEnabledLogs) {
>                 if (log.isLoggable(PlatformLogger.INFO)) {
>                     log.info("test PlatformLogger.INFO");
>                     nLog++; // ensure hotspot do not skip isLoggable()
>                 } else {
>                     nLog--;
>                 }
>
>                 if (log.isLoggable(PlatformLogger.WARNING)) {
>                     log.warning("test PlatformLogger.WARNING");
>                     nLog++; // ensure hotspot do not skip isLoggable()
>                 } else {
>                     nLog--;
>                 }
>
>                 if (log.isLoggable(PlatformLogger.SEVERE)) {
>                     log.severe("test PlatformLogger.SEVERE");
>                     nLog++; // ensure hotspot do not skip isLoggable()
>                 } else {
>                     nLog--;
>                 }
>
>                 if (log.isLoggable(PlatformLogger.OFF)) {
>                     log.severe("test PlatformLogger.OFF");
>                     nLog++; // ensure hotspot do not skip isLoggable()
>                 } else {
>                     nLog--;
>                 }
>             }
>         }
>
>         log.info("testPerf[" + WARMUP + " iterations]: duration = " +
> (1e-6d * (System.nanoTime() - start)) + " ms.");
>         log.info("testPerf: nLog = " + nLog);
>         cleanup();
>
>
>         final int PASS = 10;
>         final int N = 100 * 1000 * 1000;
>         logger.info("PlatformLoggerTest: starting " + N + " iterations
> ...");
>
>         for (int j = 0; j < PASS; j++) {
>             nLog = 0;
>             start = System.nanoTime();
>
>             for (int i = 0; i < N; i++) {
>
>
>                 if (log.isLoggable(PlatformLogger.FINEST)) {
>                     log.finest("test PlatformLogger.FINEST");
>                     nLog++; // ensure hotspot do not skip isLoggable()
>                 } else {
>                     nLog--;
>                 }
>
>                 if (log.isLoggable(PlatformLogger.FINE)) {
>                     log.fine("test PlatformLogger.FINE");
>                     nLog++; // ensure hotspot do not skip isLoggable()
>                 } else {
>                     nLog--;
>                 }
>
>                 if (log.isLoggable(PlatformLogger.FINER)) {
>                     log.finer("test PlatformLogger.FINER");
>                     nLog++; // ensure hotspot do not skip isLoggable()
>                 } else {
>                     nLog--;
>                 }
>
>                 if (log.isLoggable(PlatformLogger.CONFIG)) {
>                     log.config("test PlatformLogger.CONFIG");
>                     nLog++; // ensure hotspot do not skip isLoggable()
>                 } else {
>                     nLog--;
>                 }
>
>                 if (testEnabledLogs) {
>                     if (log.isLoggable(PlatformLogger.INFO)) {
>                         log.info("test PlatformLogger.INFO");
>                         nLog++; // ensure hotspot do not skip isLoggable()
>                     } else {
>                         nLog--;
>                     }
>
>                     if (log.isLoggable(PlatformLogger.WARNING)) {
>                         log.warning("test PlatformLogger.WARNING");
>                         nLog++; // ensure hotspot do not skip isLoggable()
>                     } else {
>                         nLog--;
>                     }
>
>                     if (log.isLoggable(PlatformLogger.SEVERE)) {
>                         log.severe("test PlatformLogger.SEVERE");
>                         nLog++; // ensure hotspot do not skip isLoggable()
>                     } else {
>                         nLog--;
>                     }
>
>                     if (log.isLoggable(PlatformLogger.OFF)) {
>                         log.severe("test PlatformLogger.OFF");
>                         nLog++; // ensure hotspot do not skip isLoggable()
>                     } else {
>                         nLog--;
>                     }
>                 }
>             }
>
>             log.info("testPerf[" + N + " iterations]: duration = " +
> (1e-6d * (System.nanoTime() - start)) + " ms.");
>             log.info("testPerf: nLog = " + nLog);
>             cleanup();
>         }
>
>         try {
>             Thread.sleep(1000l);
>         } catch (InterruptedException ie) {
>             logger.log(Level.SEVERE, "Interrupted", ie);
>         }
>
>         logger.info("PlatformLoggerTest: exit.");
>     }
>
>     /**
>      * Cleanup (GC + pause)
>      */
>     private static void cleanup() {
>         // Perform GC:
>         System.gc();
>
>         // pause:
>         try {
>             Thread.sleep(100l);
>         } catch (InterruptedException ie) {
>
>         }
>     }
> }
>
> 2013/3/21 Laurent Bourg?s 
>
>> Here is an improved patch tested on JDK7u13 and JDK8 internal build on my
>> machine linux x64:
>> http://jmmc.fr/~bourgesl/share/webrev-8010309/
>>
>> FYI, I removed completely the Map levelObjects and used
>> two arrays to perform the PlatformLogger's level (int) to j.u.l.Level
>> mapping:
>>
>> I decided to keep it simple as possible (no enum ...) and used a switch
>> case based on current level occurences:
>>
>>  510         /**
>>  511          * Return the corresponding j.u.l.Level instance
>>  512          * @param level PlatformLogger level as integer
>>
>>
>>  513          * @return Object (j.u.l.Level instance) or null if no matching level
>>  514          */
>>  515         private static Object getLevel(final int level) {
>>  516             if (levelObjects == null) {
>>
>>  517                 return null;
>>
>>  518             }
>>  519             // higher occurences first (finest, fine, finer, info)
>>  520             // based on isLoggable(level) calls (03/20/2013)
>>  521             // in jdk project only (including generated sources)
>>
>>
>>  522             switch (level) {
>>  523                 case FINEST  : return levelObjects[IDX_FINEST];  // 116 + 2257 matches in generated files
>>  524                 case FINE    : return levelObjects[IDX_FINE];    // 270
>>
>>
>>  525                 case FINER   : return levelObjects[IDX_FINER];   // 157
>>  526                 case INFO    : return levelObjects[IDX_INFO];    // 39
>>  527                 case WARNING : return levelObjects[IDX_WARNING]; // 12
>>
>>
>>  528                 case CONFIG  : return levelObjects[IDX_CONFIG];  // 6
>>  529                 case SEVERE  : return levelObjects[IDX_SEVERE];  // 1
>>  530                 case OFF     : return levelObjects[IDX_OFF];     // 0
>>
>>
>>  531                 case ALL     : return levelObjects[IDX_ALL];     // 0
>>  532                 default      : return null;
>>  533             }
>>  534         }
>>
>> I enhanced the PlatformLoggerTest class also and figured out that TLAB
>> optimized Integer allocations but I think the patch is still useful.
>>
>> Can you have a look to the patch ?
>> Should I write a jtreg test  (performance / GC issue) ?
>>
>> Cheers,
>> Laurent
>>
>>
>> 2013/3/20 Mandy Chung 
>>
>>>  Hi Laurent,
>>>
>>> Thank you for signing the OCA.  Your contribution is very welcome.  You
>>> can submit a patch for this bug (see [1]) to Core libraries group which
>>> owns logging.  Jim Gish and I will sponsor it.
>>>
>>> Thanks
>>> Mandy
>>> [1] http://openjdk.java.net/contribute/
>>>
>>>
>>> On 3/20/2013 5:45 AM, Laurent Bourg?s wrote:
>>>
>>> Hi mandy,
>>>
>>> Do you want me to propose an improved patch to remove the former Map and
>>> fix the getLevel() method ? or you prefer fix on your own ?
>>>
>>> Is it better to discuss the fix on the bug database (still not visible) ?
>>>
>>> Laurent
>>>
>>> 2013/3/19 Mandy Chung 
>>>
>>>>  Hi Laurent,
>>>>
>>>> Thanks for the contribution.  I agree that the map can be replaced with
>>>> a direct mapping from a int value to Level object and avoid the autoboxing
>>>> conversion.
>>>>
>>>> I have filed a bug to track this and target this for JDK8:
>>>>   http://bugs.sun.com/bugdatabase/view_bug.do?bug_id= 8010309
>>>>
>>>> Thanks
>>>> Mandy
>>>>
>>>>
>>>> On 3/19/13 5:19 AM, Laurent Bourg?s wrote:
>>>>
>>>> Dear all,
>>>>
>>>> I run recently netbeans profiler on my swing application (Aspro2:http://www.jmmc.fr/aspro
>>>> ) under linux x64 platform and figured out a
>>>> performance and waste issue related to PlatformLogger.
>>>>
>>>> Actually, the JavaLogger implementation uses a Map
>>>> levelObjects to store mapping between PlatformLogger's levels (int) and JUL
>>>> Level instances.
>>>>
>>>> However, the isLoggable(int level) method is highly used by awt project and
>>>> other JDK projects and it leads to many Integer allocations as autoboxing
>>>> converts the level as int to an Integer instance used by the Map.get() call.
>>>>
>>>>     /**
>>>>      * JavaLogger forwards all the calls to its corresponding
>>>>      * java.util.logging.Logger object.
>>>>      */
>>>>     static class JavaLogger extends LoggerProxy {
>>>>         private static final* Map* levelObjects = new
>>>> HashMap<>();
>>>> ...
>>>>         public boolean isLoggable(*int level*) {
>>>>             return LoggingSupport.isLoggable(javaLogger, *
>>>> levelObjects.get(level)*);
>>>>         }
>>>>     }
>>>>
>>>> I wrote a simple test to illustrate that performance / waste problem:
>>>> PlatformLoggerTest that simply performs 1 million DISABLED log statements:
>>>>             if (log.isLoggable(PlatformLogger.FINEST)) {
>>>>                 log.finest("test PlatformLogger.FINEST");
>>>>             }
>>>>
>>>> As you can see in screenshots:
>>>> - 5 million Integer instances are allocated
>>>> - Integer.valueOf(int) is called 5 million times (autoboxing)
>>>> - HashMap.get() represents 30% of the test time
>>>> - patched PlatformLogger is 3x times faster
>>>> [jvm options: -Xms8m -Xmx8m -verbose:gc]
>>>>
>>>> I suggest you to use an alternative way to map PlatformLogger's levels
>>>> (int) and JUL Level instances to fix that performance / memory issue: I
>>>> added the getLevel(int level) method that performs a switch case to return
>>>> the corresponding Level object (quick and dirty solution).
>>>>
>>>> I advocate this is not a very clean solution but I prefer efficiency here:
>>>> any better solution may be appropriate to avoid at least Integer allocation
>>>> and maybe enhance performance.
>>>>
>>>> Best regards,
>>>> Laurent Bourg?s
>>>>
>>>> PS: here is the patch as text:
>>>>
>>>> # This patch file was generated by NetBeans IDE
>>>> # It uses platform neutral UTF-8 encoding and \n newlines.
>>>> --- PlatformLogger.java (6767)
>>>> +++ PlatformLogger.java (6768)
>>>> @@ -468,31 +468,13 @@
>>>>       * java.util.logging.Logger object.
>>>>       */
>>>>      static class JavaLogger extends LoggerProxy {
>>>> -        /** Note: using Integer keys leads to a lot of new Integer
>>>> instances !! */
>>>> -        private static final Map levelObjects = new
>>>> HashMap<>();
>>>> -        /** fastest mapping to Level instances from PlatformLogger level
>>>> as integer */
>>>> -        private static final Object[] fastLevelObjects;
>>>> -
>>>> -
>>>> +        private static final Map levelObjects =
>>>> +            new HashMap<>();
>>>> +
>>>>          static {
>>>>              if (LoggingSupport.isAvailable()) {
>>>>                  // initialize the map to Level objects
>>>>                  getLevelObjects();
>>>> -
>>>> -                // initialize the fastLevelObjects:
>>>> -                fastLevelObjects = new Object[] {
>>>> -                    LoggingSupport.parseLevel(getLevelName(OFF)),       //
>>>> 0
>>>> -                    LoggingSupport.parseLevel(getLevelName(SEVERE)),    //
>>>> 1
>>>> -                    LoggingSupport.parseLevel(getLevelName(WARNING)),   //
>>>> 2
>>>> -                    LoggingSupport.parseLevel(getLevelName(INFO)),      //
>>>> 3
>>>> -                    LoggingSupport.parseLevel(getLevelName(CONFIG)),    //
>>>> 4
>>>> -                    LoggingSupport.parseLevel(getLevelName(FINE)),      //
>>>> 5
>>>> -                    LoggingSupport.parseLevel(getLevelName(FINER)),     //
>>>> 6
>>>> -                    LoggingSupport.parseLevel(getLevelName(FINEST)),    //
>>>> 7
>>>> -                    LoggingSupport.parseLevel(getLevelName(ALL))        //
>>>> 8
>>>> -                };
>>>> -            } else {
>>>> -                fastLevelObjects = null; // check null
>>>>              }
>>>>          }
>>>>
>>>> @@ -515,7 +497,7 @@
>>>>              this.javaLogger = LoggingSupport.getLogger(name);
>>>>              if (level != 0) {
>>>>                  // level has been updated and so set the Logger's level
>>>> -                LoggingSupport.setLevel(javaLogger, getLevel(level));
>>>> +                LoggingSupport.setLevel(javaLogger,
>>>> levelObjects.get(level));
>>>>              }
>>>>          }
>>>>
>>>> @@ -526,11 +508,11 @@
>>>>          * not be updated.
>>>>          */
>>>>          void doLog(int level, String msg) {
>>>> -            LoggingSupport.log(javaLogger, getLevel(level), msg);
>>>> +            LoggingSupport.log(javaLogger, levelObjects.get(level), msg);
>>>>          }
>>>>
>>>>          void doLog(int level, String msg, Throwable t) {
>>>> -            LoggingSupport.log(javaLogger, getLevel(level), msg, t);
>>>> +            LoggingSupport.log(javaLogger, levelObjects.get(level), msg,
>>>> t);
>>>>          }
>>>>
>>>>          void doLog(int level, String msg, Object... params) {
>>>> @@ -544,12 +526,12 @@
>>>>              for (int i = 0; i < len; i++) {
>>>>                  sparams [i] = String.valueOf(params[i]);
>>>>              }
>>>> -            LoggingSupport.log(javaLogger, getLevel(level), msg, sparams);
>>>> +            LoggingSupport.log(javaLogger, levelObjects.get(level), msg,
>>>> sparams);
>>>>          }
>>>>
>>>>          boolean isEnabled() {
>>>>              Object level = LoggingSupport.getLevel(javaLogger);
>>>> -            return level == null || level.equals(getLevel(OFF)) == false;
>>>> +            return level == null || level.equals(levelObjects.get(OFF)) ==
>>>> false;
>>>>          }
>>>>
>>>>          int getLevel() {
>>>> @@ -566,34 +548,12 @@
>>>>
>>>>          void setLevel(int newLevel) {
>>>>              levelValue = newLevel;
>>>> -            LoggingSupport.setLevel(javaLogger, getLevel(newLevel));
>>>> +            LoggingSupport.setLevel(javaLogger,
>>>> levelObjects.get(newLevel));
>>>>          }
>>>>
>>>>          public boolean isLoggable(int level) {
>>>> -            return LoggingSupport.isLoggable(javaLogger, getLevel(level));
>>>> +            return LoggingSupport.isLoggable(javaLogger,
>>>> levelObjects.get(level));
>>>>          }
>>>> -
>>>> -        /**
>>>> -         * Return the corresponding level object (fastest implementation)
>>>> -         * @param level PlatformLogger level as primitive integer
>>>> -         * @return Object (JUL Level instance)
>>>> -         */
>>>> -        private static Object getLevel(final int level) {
>>>> -            // higher occurences first (finest, fine, finer, info):
>>>> -            switch (level) {
>>>> -                case FINEST  : return fastLevelObjects[7];
>>>> -                case FINE    : return fastLevelObjects[5];
>>>> -                case FINER   : return fastLevelObjects[6];
>>>> -                case INFO    : return fastLevelObjects[3];
>>>> -                case CONFIG  : return fastLevelObjects[4];
>>>> -                case WARNING : return fastLevelObjects[2];
>>>> -                case SEVERE  : return fastLevelObjects[1];
>>>> -                case ALL     : return fastLevelObjects[8];
>>>> -                case OFF     : return fastLevelObjects[0];
>>>> -                default      : return null;
>>>> -            }
>>>> -        }
>>>> -
>>>>      }
>>>>
>>>>      private static String getLevelName(int level) {
>>>>
>>>>
>>>>
>>>
>>>
>>
>


From lance.andersen at oracle.com  Thu Mar 21 13:36:05 2013
From: lance.andersen at oracle.com (Lance Andersen - Oracle)
Date: Thu, 21 Mar 2013 09:36:05 -0400
Subject: Review request 8010416  Addition of Driver.deregisterDriver
Message-ID: <1E5BD063-F804-4DAD-858F-3DC0751982BC@oracle.com>

Need a reviewer for 8010416, addition of Driver.deregisterDriver.

The webrev can be found at  http://cr.openjdk.java.net/~lancea/8010416/webrev.00/.

I will be submitting the ccc request later today but want to do this in parallel

Best
Lance

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com



From david.lloyd at redhat.com  Thu Mar 21 13:39:19 2013
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Thu, 21 Mar 2013 13:39:19 +0000
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due
	to HashMap leads to Integer allocations (boxing)
In-Reply-To: 
References: 
	
Message-ID: <514B0D87.60003@redhat.com>

On 3/21/13 12:04 PM, Holger Hoffstaette wrote:
> On Thu, 21 Mar 2013 12:12:07 +0100, Laurent Bourg?s wrote:
>
> [..]
>> FYI, I removed completely the Map levelObjects and used
>> two arrays to perform the PlatformLogger's level (int) to j.u.l.Level
>> mapping:
> [..]
>
> FWIW I know of at least one (quite old) project that declares custom
> j.u.l. Levels and which would be broken by this change. I personally don't
> care (since I think both j.u.l. and custom log levels are wrong to begin
> with :), but it's something to keep in mind. Maybe a Map-based mapping
> could be used as fallback, while the array-indexed lookups take the heat
> off of the common case. Just a suggestion.

Why would the platform logger ever use custom levels though?


-- 
- DML


From sundararajan.athijegannathan at oracle.com  Thu Mar 21 13:50:20 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Thu, 21 Mar 2013 13:50:20 +0000
Subject: hg: jdk8/tl/jdk: 8009869: Need to modify java.security property
	package.access to include nashorn packages
Message-ID: <20130321135033.A694C482E8@hg.openjdk.java.net>

Changeset: 9ee1aff76498
Author:    sundar
Date:      2013-03-21 19:19 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9ee1aff76498

8009869: Need to modify java.security property package.access to include nashorn packages
Reviewed-by: ahgross, jlaskey, lagergren

! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows



From peter.levart at gmail.com  Thu Mar 21 13:59:37 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 21 Mar 2013 14:59:37 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due
	to HashMap leads to Integer allocations (boxing)
In-Reply-To: 
References: 
Message-ID: <514B1249.7010207@gmail.com>

On 03/21/2013 12:12 PM, Laurent Bourg?s wrote:
> Here is an improved patch tested on JDK7u13 and JDK8 internal build on my
> machine linux x64:
> http://jmmc.fr/~bourgesl/share/webrev-8010309/
>
> FYI, I removed completely the Map levelObjects and used
> two arrays to perform the PlatformLogger's level (int) to j.u.l.Level
> mapping:
>
> I decided to keep it simple as possible (no enum ...) and used a switch
> case based on current level occurences:

Hi Laurent,

In my experience enums are just the right and most compact tool for 
coding such constant associations. Here's a quick try (ripping off your 
optimized switch ;-):

http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.01/index.html

...it adds 12 LOC to the original PlatformLogger and is 43 LOC less tha 
your patch. In addition:

- only one switch instead of two (to maintain)
- no parallel IDX_ constants

What do you think?

Regards, Peter

>
>   510         /**
>   511          * Return the corresponding j.u.l.Level instance
>   512          * @param level PlatformLogger level as integer
>   513          * @return Object (j.u.l.Level instance) or null if no
> matching level
>   514          */
>   515         private static Object getLevel(final int level) {
>   516             if (levelObjects == null) {
>   517                 return null;
>   518             }
>   519             // higher occurences first (finest, fine, finer, info)
>   520             // based on isLoggable(level) calls (03/20/2013)
>   521             // in jdk project only (including generated sources)
>   522             switch (level) {
>   523                 case FINEST  : return levelObjects[IDX_FINEST];
> // 116 + 2257 matches in generated files
>   524                 case FINE    : return levelObjects[IDX_FINE];    // 270
>   525                 case FINER   : return levelObjects[IDX_FINER];   // 157
>   526                 case INFO    : return levelObjects[IDX_INFO];    // 39
>   527                 case WARNING : return levelObjects[IDX_WARNING]; // 12
>   528                 case CONFIG  : return levelObjects[IDX_CONFIG];  // 6
>   529                 case SEVERE  : return levelObjects[IDX_SEVERE];  // 1
>   530                 case OFF     : return levelObjects[IDX_OFF];     // 0
>   531                 case ALL     : return levelObjects[IDX_ALL];     // 0
>   532                 default      : return null;
>   533             }
>   534         }
>
> I enhanced the PlatformLoggerTest class also and figured out that TLAB
> optimized Integer allocations but I think the patch is still useful.
>
> Can you have a look to the patch ?
> Should I write a jtreg test  (performance / GC issue) ?
>
> Cheers,
> Laurent
>
>
> 2013/3/20 Mandy Chung 
>
>>   Hi Laurent,
>>
>> Thank you for signing the OCA.  Your contribution is very welcome.  You
>> can submit a patch for this bug (see [1]) to Core libraries group which
>> owns logging.  Jim Gish and I will sponsor it.
>>
>> Thanks
>> Mandy
>> [1] http://openjdk.java.net/contribute/
>>
>>
>> On 3/20/2013 5:45 AM, Laurent Bourg?s wrote:
>>
>> Hi mandy,
>>
>> Do you want me to propose an improved patch to remove the former Map and
>> fix the getLevel() method ? or you prefer fix on your own ?
>>
>> Is it better to discuss the fix on the bug database (still not visible) ?
>>
>> Laurent
>>
>> 2013/3/19 Mandy Chung 
>>
>>>   Hi Laurent,
>>>
>>> Thanks for the contribution.  I agree that the map can be replaced with a
>>> direct mapping from a int value to Level object and avoid the autoboxing
>>> conversion.
>>>
>>> I have filed a bug to track this and target this for JDK8:
>>>    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id= 8010309
>>>
>>> Thanks
>>> Mandy
>>>
>>>
>>> On 3/19/13 5:19 AM, Laurent Bourg?s wrote:
>>>
>>> Dear all,
>>>
>>> I run recently netbeans profiler on my swing application (Aspro2:http://www.jmmc.fr/aspro
>>> ) under linux x64 platform and figured out a
>>> performance and waste issue related to PlatformLogger.
>>>
>>> Actually, the JavaLogger implementation uses a Map
>>> levelObjects to store mapping between PlatformLogger's levels (int) and JUL
>>> Level instances.
>>>
>>> However, the isLoggable(int level) method is highly used by awt project and
>>> other JDK projects and it leads to many Integer allocations as autoboxing
>>> converts the level as int to an Integer instance used by the Map.get() call.
>>>
>>>      /**
>>>       * JavaLogger forwards all the calls to its corresponding
>>>       * java.util.logging.Logger object.
>>>       */
>>>      static class JavaLogger extends LoggerProxy {
>>>          private static final* Map* levelObjects = new
>>> HashMap<>();
>>> ...
>>>          public boolean isLoggable(*int level*) {
>>>              return LoggingSupport.isLoggable(javaLogger, *
>>> levelObjects.get(level)*);
>>>          }
>>>      }
>>>
>>> I wrote a simple test to illustrate that performance / waste problem:
>>> PlatformLoggerTest that simply performs 1 million DISABLED log statements:
>>>              if (log.isLoggable(PlatformLogger.FINEST)) {
>>>                  log.finest("test PlatformLogger.FINEST");
>>>              }
>>>
>>> As you can see in screenshots:
>>> - 5 million Integer instances are allocated
>>> - Integer.valueOf(int) is called 5 million times (autoboxing)
>>> - HashMap.get() represents 30% of the test time
>>> - patched PlatformLogger is 3x times faster
>>> [jvm options: -Xms8m -Xmx8m -verbose:gc]
>>>
>>> I suggest you to use an alternative way to map PlatformLogger's levels
>>> (int) and JUL Level instances to fix that performance / memory issue: I
>>> added the getLevel(int level) method that performs a switch case to return
>>> the corresponding Level object (quick and dirty solution).
>>>
>>> I advocate this is not a very clean solution but I prefer efficiency here:
>>> any better solution may be appropriate to avoid at least Integer allocation
>>> and maybe enhance performance.
>>>
>>> Best regards,
>>> Laurent Bourg?s
>>>
>>> PS: here is the patch as text:
>>>
>>> # This patch file was generated by NetBeans IDE
>>> # It uses platform neutral UTF-8 encoding and \n newlines.
>>> --- PlatformLogger.java (6767)
>>> +++ PlatformLogger.java (6768)
>>> @@ -468,31 +468,13 @@
>>>        * java.util.logging.Logger object.
>>>        */
>>>       static class JavaLogger extends LoggerProxy {
>>> -        /** Note: using Integer keys leads to a lot of new Integer
>>> instances !! */
>>> -        private static final Map levelObjects = new
>>> HashMap<>();
>>> -        /** fastest mapping to Level instances from PlatformLogger level
>>> as integer */
>>> -        private static final Object[] fastLevelObjects;
>>> -
>>> -
>>> +        private static final Map levelObjects =
>>> +            new HashMap<>();
>>> +
>>>           static {
>>>               if (LoggingSupport.isAvailable()) {
>>>                   // initialize the map to Level objects
>>>                   getLevelObjects();
>>> -
>>> -                // initialize the fastLevelObjects:
>>> -                fastLevelObjects = new Object[] {
>>> -                    LoggingSupport.parseLevel(getLevelName(OFF)),       //
>>> 0
>>> -                    LoggingSupport.parseLevel(getLevelName(SEVERE)),    //
>>> 1
>>> -                    LoggingSupport.parseLevel(getLevelName(WARNING)),   //
>>> 2
>>> -                    LoggingSupport.parseLevel(getLevelName(INFO)),      //
>>> 3
>>> -                    LoggingSupport.parseLevel(getLevelName(CONFIG)),    //
>>> 4
>>> -                    LoggingSupport.parseLevel(getLevelName(FINE)),      //
>>> 5
>>> -                    LoggingSupport.parseLevel(getLevelName(FINER)),     //
>>> 6
>>> -                    LoggingSupport.parseLevel(getLevelName(FINEST)),    //
>>> 7
>>> -                    LoggingSupport.parseLevel(getLevelName(ALL))        //
>>> 8
>>> -                };
>>> -            } else {
>>> -                fastLevelObjects = null; // check null
>>>               }
>>>           }
>>>
>>> @@ -515,7 +497,7 @@
>>>               this.javaLogger = LoggingSupport.getLogger(name);
>>>               if (level != 0) {
>>>                   // level has been updated and so set the Logger's level
>>> -                LoggingSupport.setLevel(javaLogger, getLevel(level));
>>> +                LoggingSupport.setLevel(javaLogger,
>>> levelObjects.get(level));
>>>               }
>>>           }
>>>
>>> @@ -526,11 +508,11 @@
>>>           * not be updated.
>>>           */
>>>           void doLog(int level, String msg) {
>>> -            LoggingSupport.log(javaLogger, getLevel(level), msg);
>>> +            LoggingSupport.log(javaLogger, levelObjects.get(level), msg);
>>>           }
>>>
>>>           void doLog(int level, String msg, Throwable t) {
>>> -            LoggingSupport.log(javaLogger, getLevel(level), msg, t);
>>> +            LoggingSupport.log(javaLogger, levelObjects.get(level), msg,
>>> t);
>>>           }
>>>
>>>           void doLog(int level, String msg, Object... params) {
>>> @@ -544,12 +526,12 @@
>>>               for (int i = 0; i < len; i++) {
>>>                   sparams [i] = String.valueOf(params[i]);
>>>               }
>>> -            LoggingSupport.log(javaLogger, getLevel(level), msg, sparams);
>>> +            LoggingSupport.log(javaLogger, levelObjects.get(level), msg,
>>> sparams);
>>>           }
>>>
>>>           boolean isEnabled() {
>>>               Object level = LoggingSupport.getLevel(javaLogger);
>>> -            return level == null || level.equals(getLevel(OFF)) == false;
>>> +            return level == null || level.equals(levelObjects.get(OFF)) ==
>>> false;
>>>           }
>>>
>>>           int getLevel() {
>>> @@ -566,34 +548,12 @@
>>>
>>>           void setLevel(int newLevel) {
>>>               levelValue = newLevel;
>>> -            LoggingSupport.setLevel(javaLogger, getLevel(newLevel));
>>> +            LoggingSupport.setLevel(javaLogger,
>>> levelObjects.get(newLevel));
>>>           }
>>>
>>>           public boolean isLoggable(int level) {
>>> -            return LoggingSupport.isLoggable(javaLogger, getLevel(level));
>>> +            return LoggingSupport.isLoggable(javaLogger,
>>> levelObjects.get(level));
>>>           }
>>> -
>>> -        /**
>>> -         * Return the corresponding level object (fastest implementation)
>>> -         * @param level PlatformLogger level as primitive integer
>>> -         * @return Object (JUL Level instance)
>>> -         */
>>> -        private static Object getLevel(final int level) {
>>> -            // higher occurences first (finest, fine, finer, info):
>>> -            switch (level) {
>>> -                case FINEST  : return fastLevelObjects[7];
>>> -                case FINE    : return fastLevelObjects[5];
>>> -                case FINER   : return fastLevelObjects[6];
>>> -                case INFO    : return fastLevelObjects[3];
>>> -                case CONFIG  : return fastLevelObjects[4];
>>> -                case WARNING : return fastLevelObjects[2];
>>> -                case SEVERE  : return fastLevelObjects[1];
>>> -                case ALL     : return fastLevelObjects[8];
>>> -                case OFF     : return fastLevelObjects[0];
>>> -                default      : return null;
>>> -            }
>>> -        }
>>> -
>>>       }
>>>
>>>       private static String getLevelName(int level) {
>>>
>>>
>>>
>>



From holger.hoffstaette at googlemail.com  Thu Mar 21 14:17:53 2013
From: holger.hoffstaette at googlemail.com (Holger Hoffstaette)
Date: Thu, 21 Mar 2013 15:17:53 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due	to
	HashMap leads to Integer allocations (boxing)
References: 
	
	<514B0D87.60003@redhat.com>
Message-ID: 

On Thu, 21 Mar 2013 13:39:19 +0000, David M. Lloyd wrote:

> On 3/21/13 12:04 PM, Holger Hoffstaette wrote:
>> On Thu, 21 Mar 2013 12:12:07 +0100, Laurent Bourg?s wrote:
>>
>> [..]
>>> FYI, I removed completely the Map levelObjects and
>>> used two arrays to perform the PlatformLogger's level (int) to
>>> j.u.l.Level mapping:
>> [..]
>>
>> FWIW I know of at least one (quite old) project that declares custom
>> j.u.l. Levels and which would be broken by this change. I personally
>> don't care (since I think both j.u.l. and custom log levels are wrong to
>> begin with :), but it's something to keep in mind. Maybe a Map-based
>> mapping could be used as fallback, while the array-indexed lookups take
>> the heat off of the common case. Just a suggestion.
> 
> Why would the platform logger ever use custom levels though?



Absolutely right - "very likely" it would not. "Good point!" :)

-h




From bourges.laurent at gmail.com  Thu Mar 21 14:30:30 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Thu, 21 Mar 2013 15:30:30 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due to
	HashMap leads to Integer allocations (boxing)
In-Reply-To: <514B1249.7010207@gmail.com>
References: 
	<514B1249.7010207@gmail.com>
Message-ID: 

Peter,

your solution looks better; I wanted my patch to be simple, efficient and
only modify the JavaLogger class (localized changes).

In your patch, I have doubts related to lazy and conditional initialization
in JavaLogger (static initialization):

if (LoggingSupport.isAvailable()) {
    // initialize ...
}

Does somebody have the knowledge about LoggingSupport.isAvailable()
and the lazy PlatformLogger initialization (JavaLogger are only used
when j.u.l is initialized) ?

What's happening if LoggingSupport.isAvailable() returns false in your patch ?
- LevelEnum instances are incorrectly initialized: object field is null !
- PlatformLogger is then broken ... as Level object are required by j.u.l calls

To fix both problems, moving the LevelEnum into JavaLogger should help
and check nulls on LevelEnum.object field.

Thanks for your feedback,
Laurent

2013/3/21 Peter Levart 

> On 03/21/2013 12:12 PM, Laurent Bourg?s wrote:
>
>> Here is an improved patch tested on JDK7u13 and JDK8 internal build on my
>> machine linux x64:
>> http://jmmc.fr/~bourgesl/**share/webrev-8010309/
>>
>> FYI, I removed completely the Map levelObjects and used
>> two arrays to perform the PlatformLogger's level (int) to j.u.l.Level
>> mapping:
>>
>> I decided to keep it simple as possible (no enum ...) and used a switch
>> case based on current level occurences:
>>
>
> Hi Laurent,
>
> In my experience enums are just the right and most compact tool for coding
> such constant associations. Here's a quick try (ripping off your optimized
> switch ;-):
>
> http://dl.dropbox.com/u/**101777488/jdk8-tl/**PlatformLogger/webrev.01/**
> index.html
>
> ...it adds 12 LOC to the original PlatformLogger and is 43 LOC less tha
> your patch. In addition:
>
> - only one switch instead of two (to maintain)
> - no parallel IDX_ constants
>
> What do you think?
>
> Regards, Peter
>
>
>
>>   510         /**
>>   511          * Return the corresponding j.u.l.Level instance
>>   512          * @param level PlatformLogger level as integer
>>   513          * @return Object (j.u.l.Level instance) or null if no
>> matching level
>>   514          */
>>   515         private static Object getLevel(final int level) {
>>   516             if (levelObjects == null) {
>>   517                 return null;
>>   518             }
>>   519             // higher occurences first (finest, fine, finer, info)
>>   520             // based on isLoggable(level) calls (03/20/2013)
>>   521             // in jdk project only (including generated sources)
>>   522             switch (level) {
>>   523                 case FINEST  : return levelObjects[IDX_FINEST];
>> // 116 + 2257 matches in generated files
>>   524                 case FINE    : return levelObjects[IDX_FINE];    //
>> 270
>>   525                 case FINER   : return levelObjects[IDX_FINER];   //
>> 157
>>   526                 case INFO    : return levelObjects[IDX_INFO];    //
>> 39
>>   527                 case WARNING : return levelObjects[IDX_WARNING]; //
>> 12
>>   528                 case CONFIG  : return levelObjects[IDX_CONFIG];  //
>> 6
>>   529                 case SEVERE  : return levelObjects[IDX_SEVERE];  //
>> 1
>>   530                 case OFF     : return levelObjects[IDX_OFF];     //
>> 0
>>   531                 case ALL     : return levelObjects[IDX_ALL];     //
>> 0
>>   532                 default      : return null;
>>   533             }
>>   534         }
>>
>> I enhanced the PlatformLoggerTest class also and figured out that TLAB
>> optimized Integer allocations but I think the patch is still useful.
>>
>> Can you have a look to the patch ?
>> Should I write a jtreg test  (performance / GC issue) ?
>>
>> Cheers,
>> Laurent
>>
>>
>> 2013/3/20 Mandy Chung 
>>
>>    Hi Laurent,
>>>
>>> Thank you for signing the OCA.  Your contribution is very welcome.  You
>>> can submit a patch for this bug (see [1]) to Core libraries group which
>>> owns logging.  Jim Gish and I will sponsor it.
>>>
>>> Thanks
>>> Mandy
>>> [1] http://openjdk.java.net/**contribute/
>>>
>>>
>>> On 3/20/2013 5:45 AM, Laurent Bourg?s wrote:
>>>
>>> Hi mandy,
>>>
>>> Do you want me to propose an improved patch to remove the former Map and
>>> fix the getLevel() method ? or you prefer fix on your own ?
>>>
>>> Is it better to discuss the fix on the bug database (still not visible) ?
>>>
>>> Laurent
>>>
>>> 2013/3/19 Mandy Chung 
>>>
>>>    Hi Laurent,
>>>>
>>>> Thanks for the contribution.  I agree that the map can be replaced with
>>>> a
>>>> direct mapping from a int value to Level object and avoid the autoboxing
>>>> conversion.
>>>>
>>>> I have filed a bug to track this and target this for JDK8:
>>>>    http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=8010309
>>>>
>>>> Thanks
>>>> Mandy
>>>>
>>>>
>>>> On 3/19/13 5:19 AM, Laurent Bourg?s wrote:
>>>>
>>>> Dear all,
>>>>
>>>> I run recently netbeans profiler on my swing application (Aspro2:
>>>> http://www.jmmc.fr/**aspro 
>>>> ) under linux x64 platform and figured out a
>>>> performance and waste issue related to PlatformLogger.
>>>>
>>>> Actually, the JavaLogger implementation uses a Map
>>>> levelObjects to store mapping between PlatformLogger's levels (int) and
>>>> JUL
>>>> Level instances.
>>>>
>>>> However, the isLoggable(int level) method is highly used by awt project
>>>> and
>>>> other JDK projects and it leads to many Integer allocations as
>>>> autoboxing
>>>> converts the level as int to an Integer instance used by the Map.get()
>>>> call.
>>>>
>>>>      /**
>>>>       * JavaLogger forwards all the calls to its corresponding
>>>>       * java.util.logging.Logger object.
>>>>       */
>>>>      static class JavaLogger extends LoggerProxy {
>>>>          private static final* Map* levelObjects = new
>>>> HashMap<>();
>>>> ...
>>>>          public boolean isLoggable(*int level*) {
>>>>              return LoggingSupport.isLoggable(**javaLogger, *
>>>> levelObjects.get(level)*);
>>>>          }
>>>>      }
>>>>
>>>> I wrote a simple test to illustrate that performance / waste problem:
>>>> PlatformLoggerTest that simply performs 1 million DISABLED log
>>>> statements:
>>>>              if (log.isLoggable(**PlatformLogger.FINEST)) {
>>>>                  log.finest("test PlatformLogger.FINEST");
>>>>              }
>>>>
>>>> As you can see in screenshots:
>>>> - 5 million Integer instances are allocated
>>>> - Integer.valueOf(int) is called 5 million times (autoboxing)
>>>> - HashMap.get() represents 30% of the test time
>>>> - patched PlatformLogger is 3x times faster
>>>> [jvm options: -Xms8m -Xmx8m -verbose:gc]
>>>>
>>>> I suggest you to use an alternative way to map PlatformLogger's levels
>>>> (int) and JUL Level instances to fix that performance / memory issue: I
>>>> added the getLevel(int level) method that performs a switch case to
>>>> return
>>>> the corresponding Level object (quick and dirty solution).
>>>>
>>>> I advocate this is not a very clean solution but I prefer efficiency
>>>> here:
>>>> any better solution may be appropriate to avoid at least Integer
>>>> allocation
>>>> and maybe enhance performance.
>>>>
>>>> Best regards,
>>>> Laurent Bourg?s
>>>>
>>>> PS: here is the patch as text:
>>>>
>>>> # This patch file was generated by NetBeans IDE
>>>> # It uses platform neutral UTF-8 encoding and \n newlines.
>>>> --- PlatformLogger.java (6767)
>>>> +++ PlatformLogger.java (6768)
>>>> @@ -468,31 +468,13 @@
>>>>        * java.util.logging.Logger object.
>>>>        */
>>>>       static class JavaLogger extends LoggerProxy {
>>>> -        /** Note: using Integer keys leads to a lot of new Integer
>>>> instances !! */
>>>> -        private static final Map levelObjects = new
>>>> HashMap<>();
>>>> -        /** fastest mapping to Level instances from PlatformLogger
>>>> level
>>>> as integer */
>>>> -        private static final Object[] fastLevelObjects;
>>>> -
>>>> -
>>>> +        private static final Map levelObjects =
>>>> +            new HashMap<>();
>>>> +
>>>>           static {
>>>>               if (LoggingSupport.isAvailable()) {
>>>>                   // initialize the map to Level objects
>>>>                   getLevelObjects();
>>>> -
>>>> -                // initialize the fastLevelObjects:
>>>> -                fastLevelObjects = new Object[] {
>>>> -                    LoggingSupport.parseLevel(**getLevelName(OFF)),
>>>>     //
>>>> 0
>>>> -                    LoggingSupport.parseLevel(**getLevelName(SEVERE)),
>>>>    //
>>>> 1
>>>> -                    LoggingSupport.parseLevel(**getLevelName(WARNING)),
>>>>   //
>>>> 2
>>>> -                    LoggingSupport.parseLevel(**getLevelName(INFO)),
>>>>      //
>>>> 3
>>>> -                    LoggingSupport.parseLevel(**getLevelName(CONFIG)),
>>>>    //
>>>> 4
>>>> -                    LoggingSupport.parseLevel(**getLevelName(FINE)),
>>>>      //
>>>> 5
>>>> -                    LoggingSupport.parseLevel(**getLevelName(FINER)),
>>>>     //
>>>> 6
>>>> -                    LoggingSupport.parseLevel(**getLevelName(FINEST)),
>>>>    //
>>>> 7
>>>> -                    LoggingSupport.parseLevel(**getLevelName(ALL))
>>>>      //
>>>> 8
>>>> -                };
>>>> -            } else {
>>>> -                fastLevelObjects = null; // check null
>>>>               }
>>>>           }
>>>>
>>>> @@ -515,7 +497,7 @@
>>>>               this.javaLogger = LoggingSupport.getLogger(name)**;
>>>>               if (level != 0) {
>>>>                   // level has been updated and so set the Logger's
>>>> level
>>>> -                LoggingSupport.setLevel(**javaLogger,
>>>> getLevel(level));
>>>> +                LoggingSupport.setLevel(**javaLogger,
>>>> levelObjects.get(level));
>>>>               }
>>>>           }
>>>>
>>>> @@ -526,11 +508,11 @@
>>>>           * not be updated.
>>>>           */
>>>>           void doLog(int level, String msg) {
>>>> -            LoggingSupport.log(javaLogger, getLevel(level), msg);
>>>> +            LoggingSupport.log(javaLogger, levelObjects.get(level),
>>>> msg);
>>>>           }
>>>>
>>>>           void doLog(int level, String msg, Throwable t) {
>>>> -            LoggingSupport.log(javaLogger, getLevel(level), msg, t);
>>>> +            LoggingSupport.log(javaLogger, levelObjects.get(level),
>>>> msg,
>>>> t);
>>>>           }
>>>>
>>>>           void doLog(int level, String msg, Object... params) {
>>>> @@ -544,12 +526,12 @@
>>>>               for (int i = 0; i < len; i++) {
>>>>                   sparams [i] = String.valueOf(params[i]);
>>>>               }
>>>> -            LoggingSupport.log(javaLogger, getLevel(level), msg,
>>>> sparams);
>>>> +            LoggingSupport.log(javaLogger, levelObjects.get(level),
>>>> msg,
>>>> sparams);
>>>>           }
>>>>
>>>>           boolean isEnabled() {
>>>>               Object level = LoggingSupport.getLevel(**javaLogger);
>>>> -            return level == null || level.equals(getLevel(OFF)) ==
>>>> false;
>>>> +            return level == null || level.equals(levelObjects.get(**OFF))
>>>> ==
>>>> false;
>>>>           }
>>>>
>>>>           int getLevel() {
>>>> @@ -566,34 +548,12 @@
>>>>
>>>>           void setLevel(int newLevel) {
>>>>               levelValue = newLevel;
>>>> -            LoggingSupport.setLevel(**javaLogger, getLevel(newLevel));
>>>> +            LoggingSupport.setLevel(**javaLogger,
>>>> levelObjects.get(newLevel));
>>>>           }
>>>>
>>>>           public boolean isLoggable(int level) {
>>>> -            return LoggingSupport.isLoggable(**javaLogger,
>>>> getLevel(level));
>>>> +            return LoggingSupport.isLoggable(**javaLogger,
>>>> levelObjects.get(level));
>>>>           }
>>>> -
>>>> -        /**
>>>> -         * Return the corresponding level object (fastest
>>>> implementation)
>>>> -         * @param level PlatformLogger level as primitive integer
>>>> -         * @return Object (JUL Level instance)
>>>> -         */
>>>> -        private static Object getLevel(final int level) {
>>>> -            // higher occurences first (finest, fine, finer, info):
>>>> -            switch (level) {
>>>> -                case FINEST  : return fastLevelObjects[7];
>>>> -                case FINE    : return fastLevelObjects[5];
>>>> -                case FINER   : return fastLevelObjects[6];
>>>> -                case INFO    : return fastLevelObjects[3];
>>>> -                case CONFIG  : return fastLevelObjects[4];
>>>> -                case WARNING : return fastLevelObjects[2];
>>>> -                case SEVERE  : return fastLevelObjects[1];
>>>> -                case ALL     : return fastLevelObjects[8];
>>>> -                case OFF     : return fastLevelObjects[0];
>>>> -                default      : return null;
>>>> -            }
>>>> -        }
>>>> -
>>>>       }
>>>>
>>>>       private static String getLevelName(int level) {
>>>>
>>>>
>>>>
>>>>
>>>
>


From peter.levart at gmail.com  Thu Mar 21 14:45:26 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 21 Mar 2013 15:45:26 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due
	to HashMap leads to Integer allocations (boxing)
In-Reply-To: 
References: 
	<514B1249.7010207@gmail.com>
	
Message-ID: <514B1D06.10007@gmail.com>

On 03/21/2013 03:30 PM, Laurent Bourg?s wrote:
> Peter,
>
> your solution looks better; I wanted my patch to be simple, efficient 
> and only modify the JavaLogger class (localized changes).
>
> In your patch, I have doubts related to lazy and conditional 
> initialization in JavaLogger (static initialization):
> if (LoggingSupport.isAvailable()) {
>      // initialize ...
> }

In original code, if LoggingSupport.isAvailable() returned false, 
levelObjects map remained empty and consequently null was used as the 
level object passed to LoggingSupport methods. In LevelEnum I try to 
keep this logic. When LevelEnum is first used, it's constants are 
initialized and level objects with them. If
LoggingSupport.isAvailable() returns false, level objects are 
initialized to null.

I just noticed there's a bug in initialization of the LevelEnum.UNKNOWN 
member constant. It should not try to parse level object. Here's an update:

http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.02/index.html

But your concern might be correct. In my code LevelEnum is also used 
from the LoggerProxy.format() method (in addition to all the places in 
JavaLogger) to obtain the level name for formatting. If this method is 
called the first time while LoggingSupport.isAvailable() returns false 
and that happens before JavaLogger uses LevelEnum for the first time 
(and at that time LoggingSupport.isAvailable() would return true), then 
level objects will not be initialized correctly.

Lazy initialization of level objects might help (for the price of added 
complexity)...

Regards, Peter

> Does somebody have the knowledge about LoggingSupport.isAvailable()
>
> and the lazy PlatformLogger initialization (JavaLogger are only used when j.u.l is initialized) ?
>
>
> What's happening if LoggingSupport.isAvailable() returns false in your patch ?
> - LevelEnum  instances are incorrectly initialized:object field is null !
>
> - PlatformLogger is then broken ... as Level object are required by j.u.l calls
>
>
> To fix both problems, moving theLevelEnum  into JavaLogger should help and check nulls onLevelEnum.object field.
>
>
> Thanks for your feedback,
> Laurent
>
>
> 2013/3/21 Peter Levart  >
>
>     On 03/21/2013 12:12 PM, Laurent Bourg?s wrote:
>
>         Here is an improved patch tested on JDK7u13 and JDK8 internal
>         build on my
>         machine linux x64:
>         http://jmmc.fr/~bourgesl/share/webrev-8010309/
>         
>
>         FYI, I removed completely the Map
>         levelObjects and used
>         two arrays to perform the PlatformLogger's level (int) to
>         j.u.l.Level
>         mapping:
>
>         I decided to keep it simple as possible (no enum ...) and used
>         a switch
>         case based on current level occurences:
>
>
>     Hi Laurent,
>
>     In my experience enums are just the right and most compact tool
>     for coding such constant associations. Here's a quick try (ripping
>     off your optimized switch ;-):
>
>     http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.01/index.html
>
>     ...it adds 12 LOC to the original PlatformLogger and is 43 LOC
>     less tha your patch. In addition:
>
>     - only one switch instead of two (to maintain)
>     - no parallel IDX_ constants
>
>     What do you think?
>
>     Regards, Peter
>
>
>
>           510         /**
>           511          * Return the corresponding j.u.l.Level instance
>           512          * @param level PlatformLogger level as integer
>           513          * @return Object (j.u.l.Level instance) or null
>         if no
>         matching level
>           514          */
>           515         private static Object getLevel(final int level) {
>           516             if (levelObjects == null) {
>           517                 return null;
>           518             }
>           519             // higher occurences first (finest, fine,
>         finer, info)
>           520             // based on isLoggable(level) calls (03/20/2013)
>           521             // in jdk project only (including generated
>         sources)
>           522             switch (level) {
>           523                 case FINEST  : return
>         levelObjects[IDX_FINEST];
>         // 116 + 2257 matches in generated files
>           524                 case FINE    : return
>         levelObjects[IDX_FINE];    // 270
>           525                 case FINER   : return
>         levelObjects[IDX_FINER];   // 157
>           526                 case INFO    : return
>         levelObjects[IDX_INFO];    // 39
>           527                 case WARNING : return
>         levelObjects[IDX_WARNING]; // 12
>           528                 case CONFIG  : return
>         levelObjects[IDX_CONFIG];  // 6
>           529                 case SEVERE  : return
>         levelObjects[IDX_SEVERE];  // 1
>           530                 case OFF     : return
>         levelObjects[IDX_OFF];     // 0
>           531                 case ALL     : return
>         levelObjects[IDX_ALL];     // 0
>           532                 default      : return null;
>           533             }
>           534         }
>
>         I enhanced the PlatformLoggerTest class also and figured out
>         that TLAB
>         optimized Integer allocations but I think the patch is still
>         useful.
>
>         Can you have a look to the patch ?
>         Should I write a jtreg test  (performance / GC issue) ?
>
>         Cheers,
>         Laurent
>
>
>         2013/3/20 Mandy Chung          >
>
>               Hi Laurent,
>
>             Thank you for signing the OCA.  Your contribution is very
>             welcome.  You
>             can submit a patch for this bug (see [1]) to Core
>             libraries group which
>             owns logging.  Jim Gish and I will sponsor it.
>
>             Thanks
>             Mandy
>             [1] http://openjdk.java.net/contribute/
>
>
>             On 3/20/2013 5:45 AM, Laurent Bourg?s wrote:
>
>             Hi mandy,
>
>             Do you want me to propose an improved patch to remove the
>             former Map and
>             fix the getLevel() method ? or you prefer fix on your own ?
>
>             Is it better to discuss the fix on the bug database (still
>             not visible) ?
>
>             Laurent
>
>             2013/3/19 Mandy Chung              >
>
>                   Hi Laurent,
>
>                 Thanks for the contribution.  I agree that the map can
>                 be replaced with a
>                 direct mapping from a int value to Level object and
>                 avoid the autoboxing
>                 conversion.
>
>                 I have filed a bug to track this and target this for JDK8:
>                 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=
>                 8010309
>
>                 Thanks
>                 Mandy
>
>
>                 On 3/19/13 5:19 AM, Laurent Bourg?s wrote:
>
>                 Dear all,
>
>                 I run recently netbeans profiler on my swing
>                 application (Aspro2:http://www.jmmc.fr/aspro
>                 ) under linux x64 platform and figured out a
>                 performance and waste issue related to PlatformLogger.
>
>                 Actually, the JavaLogger implementation uses a
>                 Map
>                 levelObjects to store mapping between PlatformLogger's
>                 levels (int) and JUL
>                 Level instances.
>
>                 However, the isLoggable(int level) method is highly
>                 used by awt project and
>                 other JDK projects and it leads to many Integer
>                 allocations as autoboxing
>                 converts the level as int to an Integer instance used
>                 by the Map.get() call.
>
>                      /**
>                       * JavaLogger forwards all the calls to its
>                 corresponding
>                       * java.util.logging.Logger object.
>                       */
>                      static class JavaLogger extends LoggerProxy {
>                          private static final* Map*
>                 levelObjects = new
>                 HashMap<>();
>                 ...
>                          public boolean isLoggable(*int level*) {
>                              return
>                 LoggingSupport.isLoggable(javaLogger, *
>                 levelObjects.get(level)*);
>                          }
>                      }
>
>                 I wrote a simple test to illustrate that performance /
>                 waste problem:
>                 PlatformLoggerTest that simply performs 1 million
>                 DISABLED log statements:
>                              if (log.isLoggable(PlatformLogger.FINEST)) {
>                                  log.finest("test PlatformLogger.FINEST");
>                              }
>
>                 As you can see in screenshots:
>                 - 5 million Integer instances are allocated
>                 - Integer.valueOf(int) is called 5 million times
>                 (autoboxing)
>                 - HashMap.get() represents 30% of the test time
>                 - patched PlatformLogger is 3x times faster
>                 [jvm options: -Xms8m -Xmx8m -verbose:gc]
>
>                 I suggest you to use an alternative way to map
>                 PlatformLogger's levels
>                 (int) and JUL Level instances to fix that performance
>                 / memory issue: I
>                 added the getLevel(int level) method that performs a
>                 switch case to return
>                 the corresponding Level object (quick and dirty solution).
>
>                 I advocate this is not a very clean solution but I
>                 prefer efficiency here:
>                 any better solution may be appropriate to avoid at
>                 least Integer allocation
>                 and maybe enhance performance.
>
>                 Best regards,
>                 Laurent Bourg?s
>
>                 PS: here is the patch as text:
>
>                 # This patch file was generated by NetBeans IDE
>                 # It uses platform neutral UTF-8 encoding and \n newlines.
>                 --- PlatformLogger.java (6767)
>                 +++ PlatformLogger.java (6768)
>                 @@ -468,31 +468,13 @@
>                        * java.util.logging.Logger object.
>                        */
>                       static class JavaLogger extends LoggerProxy {
>                 -        /** Note: using Integer keys leads to a lot
>                 of new Integer
>                 instances !! */
>                 -        private static final Map
>                 levelObjects = new
>                 HashMap<>();
>                 -        /** fastest mapping to Level instances from
>                 PlatformLogger level
>                 as integer */
>                 -        private static final Object[] fastLevelObjects;
>                 -
>                 -
>                 +        private static final Map
>                 levelObjects =
>                 +            new HashMap<>();
>                 +
>                           static {
>                               if (LoggingSupport.isAvailable()) {
>                                   // initialize the map to Level objects
>                                   getLevelObjects();
>                 -
>                 -                // initialize the fastLevelObjects:
>                 -                fastLevelObjects = new Object[] {
>                 -                  
>                  LoggingSupport.parseLevel(getLevelName(OFF)),       //
>                 0
>                 -                  
>                  LoggingSupport.parseLevel(getLevelName(SEVERE)),    //
>                 1
>                 -                  
>                  LoggingSupport.parseLevel(getLevelName(WARNING)),   //
>                 2
>                 -                  
>                  LoggingSupport.parseLevel(getLevelName(INFO)),      //
>                 3
>                 -                  
>                  LoggingSupport.parseLevel(getLevelName(CONFIG)),    //
>                 4
>                 -                  
>                  LoggingSupport.parseLevel(getLevelName(FINE)),      //
>                 5
>                 -                  
>                  LoggingSupport.parseLevel(getLevelName(FINER)),     //
>                 6
>                 -                  
>                  LoggingSupport.parseLevel(getLevelName(FINEST)),    //
>                 7
>                 -                  
>                  LoggingSupport.parseLevel(getLevelName(ALL))        //
>                 8
>                 -                };
>                 -            } else {
>                 -                fastLevelObjects = null; // check null
>                               }
>                           }
>
>                 @@ -515,7 +497,7 @@
>                               this.javaLogger =
>                 LoggingSupport.getLogger(name);
>                               if (level != 0) {
>                                   // level has been updated and so set
>                 the Logger's level
>                 -                LoggingSupport.setLevel(javaLogger,
>                 getLevel(level));
>                 +                LoggingSupport.setLevel(javaLogger,
>                 levelObjects.get(level));
>                               }
>                           }
>
>                 @@ -526,11 +508,11 @@
>                           * not be updated.
>                           */
>                           void doLog(int level, String msg) {
>                 -            LoggingSupport.log(javaLogger,
>                 getLevel(level), msg);
>                 +            LoggingSupport.log(javaLogger,
>                 levelObjects.get(level), msg);
>                           }
>
>                           void doLog(int level, String msg, Throwable t) {
>                 -            LoggingSupport.log(javaLogger,
>                 getLevel(level), msg, t);
>                 +            LoggingSupport.log(javaLogger,
>                 levelObjects.get(level), msg,
>                 t);
>                           }
>
>                           void doLog(int level, String msg, Object...
>                 params) {
>                 @@ -544,12 +526,12 @@
>                               for (int i = 0; i < len; i++) {
>                                   sparams [i] = String.valueOf(params[i]);
>                               }
>                 -            LoggingSupport.log(javaLogger,
>                 getLevel(level), msg, sparams);
>                 +            LoggingSupport.log(javaLogger,
>                 levelObjects.get(level), msg,
>                 sparams);
>                           }
>
>                           boolean isEnabled() {
>                               Object level =
>                 LoggingSupport.getLevel(javaLogger);
>                 -            return level == null ||
>                 level.equals(getLevel(OFF)) == false;
>                 +            return level == null ||
>                 level.equals(levelObjects.get(OFF)) ==
>                 false;
>                           }
>
>                           int getLevel() {
>                 @@ -566,34 +548,12 @@
>
>                           void setLevel(int newLevel) {
>                               levelValue = newLevel;
>                 -            LoggingSupport.setLevel(javaLogger,
>                 getLevel(newLevel));
>                 +            LoggingSupport.setLevel(javaLogger,
>                 levelObjects.get(newLevel));
>                           }
>
>                           public boolean isLoggable(int level) {
>                 -            return
>                 LoggingSupport.isLoggable(javaLogger, getLevel(level));
>                 +            return LoggingSupport.isLoggable(javaLogger,
>                 levelObjects.get(level));
>                           }
>                 -
>                 -        /**
>                 -         * Return the corresponding level object
>                 (fastest implementation)
>                 -         * @param level PlatformLogger level as
>                 primitive integer
>                 -         * @return Object (JUL Level instance)
>                 -         */
>                 -        private static Object getLevel(final int level) {
>                 -            // higher occurences first (finest, fine,
>                 finer, info):
>                 -            switch (level) {
>                 -                case FINEST  : return
>                 fastLevelObjects[7];
>                 -                case FINE    : return
>                 fastLevelObjects[5];
>                 -                case FINER   : return
>                 fastLevelObjects[6];
>                 -                case INFO    : return
>                 fastLevelObjects[3];
>                 -                case CONFIG  : return
>                 fastLevelObjects[4];
>                 -                case WARNING : return
>                 fastLevelObjects[2];
>                 -                case SEVERE  : return
>                 fastLevelObjects[1];
>                 -                case ALL     : return
>                 fastLevelObjects[8];
>                 -                case OFF     : return
>                 fastLevelObjects[0];
>                 -                default      : return null;
>                 -            }
>                 -        }
>                 -
>                       }
>
>                       private static String getLevelName(int level) {
>
>
>
>
>
>



From mandy.chung at oracle.com  Thu Mar 21 14:54:48 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 21 Mar 2013 07:54:48 -0700
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due
	to HashMap leads to Integer allocations (boxing)
In-Reply-To: <514B1D06.10007@gmail.com>
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com>
Message-ID: <514B1F38.9070604@oracle.com>

Laurent, Peter,

I haven't looked at the patch yet.  One thing worths mentioning is that 
PlatformLogger was added for the platform code to use so as to avoid the 
initialization of java.util.logging since logging is not turned on by 
default and that to reduce the startup overhead.   In addition, it also 
enables the elimination of the core classes dependency from 
java.util.logging for modularization effort. Therefore the 
PlatformLogger only lazily looks up the Level object when 
java.util.logging is present and also has been initialized by 
application code.

Mandy

On 3/21/2013 7:45 AM, Peter Levart wrote:
> On 03/21/2013 03:30 PM, Laurent Bourg?s wrote:
>> Peter,
>>
>> your solution looks better; I wanted my patch to be simple, efficient 
>> and only modify the JavaLogger class (localized changes).
>>
>> In your patch, I have doubts related to lazy and conditional 
>> initialization in JavaLogger (static initialization):
>> if (LoggingSupport.isAvailable()) {
>>      // initialize ...
>> }
>
> In original code, if LoggingSupport.isAvailable() returned false, 
> levelObjects map remained empty and consequently null was used as the 
> level object passed to LoggingSupport methods. In LevelEnum I try to 
> keep this logic. When LevelEnum is first used, it's constants are 
> initialized and level objects with them. If
> LoggingSupport.isAvailable() returns false, level objects are 
> initialized to null.
>
> I just noticed there's a bug in initialization of the 
> LevelEnum.UNKNOWN member constant. It should not try to parse level 
> object. Here's an update:
>
> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.02/index.html
>
> But your concern might be correct. In my code LevelEnum is also used 
> from the LoggerProxy.format() method (in addition to all the places in 
> JavaLogger) to obtain the level name for formatting. If this method is 
> called the first time while LoggingSupport.isAvailable() returns false 
> and that happens before JavaLogger uses LevelEnum for the first time 
> (and at that time LoggingSupport.isAvailable() would return true), 
> then level objects will not be initialized correctly.
>
> Lazy initialization of level objects might help (for the price of 
> added complexity)...
>
> Regards, Peter
>
>> Does somebody have the knowledge about LoggingSupport.isAvailable()
>>
>> and the lazy PlatformLogger initialization (JavaLogger are only used when j.u.l is initialized) ?
>>
>>
>> What's happening if LoggingSupport.isAvailable() returns false in your patch ?
>> - LevelEnum  instances are incorrectly initialized:object field is null !
>>
>> - PlatformLogger is then broken ... as Level object are required by j.u.l calls
>>
>>
>> To fix both problems, moving theLevelEnum  into JavaLogger should help and check nulls onLevelEnum.object field.
>>
>>
>> Thanks for your feedback,
>> Laurent
>>
>>
>> 2013/3/21 Peter Levart > >
>>
>>     On 03/21/2013 12:12 PM, Laurent Bourg?s wrote:
>>
>>         Here is an improved patch tested on JDK7u13 and JDK8 internal
>>         build on my
>>         machine linux x64:
>>         http://jmmc.fr/~bourgesl/share/webrev-8010309/
>>         
>>
>>         FYI, I removed completely the Map
>>         levelObjects and used
>>         two arrays to perform the PlatformLogger's level (int) to
>>         j.u.l.Level
>>         mapping:
>>
>>         I decided to keep it simple as possible (no enum ...) and
>>         used a switch
>>         case based on current level occurences:
>>
>>
>>     Hi Laurent,
>>
>>     In my experience enums are just the right and most compact tool
>>     for coding such constant associations. Here's a quick try
>>     (ripping off your optimized switch ;-):
>>
>>     http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.01/index.html
>>
>>     ...it adds 12 LOC to the original PlatformLogger and is 43 LOC
>>     less tha your patch. In addition:
>>
>>     - only one switch instead of two (to maintain)
>>     - no parallel IDX_ constants
>>
>>     What do you think?
>>
>>     Regards, Peter
>>
>>
>>
>>           510         /**
>>           511          * Return the corresponding j.u.l.Level instance
>>           512          * @param level PlatformLogger level as integer
>>           513          * @return Object (j.u.l.Level instance) or
>>         null if no
>>         matching level
>>           514          */
>>           515         private static Object getLevel(final int level) {
>>           516             if (levelObjects == null) {
>>           517                 return null;
>>           518             }
>>           519             // higher occurences first (finest, fine,
>>         finer, info)
>>           520             // based on isLoggable(level) calls
>>         (03/20/2013)
>>           521             // in jdk project only (including generated
>>         sources)
>>           522             switch (level) {
>>           523                 case FINEST  : return
>>         levelObjects[IDX_FINEST];
>>         // 116 + 2257 matches in generated files
>>           524                 case FINE    : return
>>         levelObjects[IDX_FINE];    // 270
>>           525                 case FINER   : return
>>         levelObjects[IDX_FINER];   // 157
>>           526                 case INFO    : return
>>         levelObjects[IDX_INFO];    // 39
>>           527                 case WARNING : return
>>         levelObjects[IDX_WARNING]; // 12
>>           528                 case CONFIG  : return
>>         levelObjects[IDX_CONFIG];  // 6
>>           529                 case SEVERE  : return
>>         levelObjects[IDX_SEVERE];  // 1
>>           530                 case OFF     : return
>>         levelObjects[IDX_OFF];     // 0
>>           531                 case ALL     : return
>>         levelObjects[IDX_ALL];     // 0
>>           532                 default      : return null;
>>           533             }
>>           534         }
>>
>>         I enhanced the PlatformLoggerTest class also and figured out
>>         that TLAB
>>         optimized Integer allocations but I think the patch is still
>>         useful.
>>
>>         Can you have a look to the patch ?
>>         Should I write a jtreg test  (performance / GC issue) ?
>>
>>         Cheers,
>>         Laurent
>>
>>
>>         2013/3/20 Mandy Chung >         >
>>
>>               Hi Laurent,
>>
>>             Thank you for signing the OCA.  Your contribution is very
>>             welcome.  You
>>             can submit a patch for this bug (see [1]) to Core
>>             libraries group which
>>             owns logging.  Jim Gish and I will sponsor it.
>>
>>             Thanks
>>             Mandy
>>             [1] http://openjdk.java.net/contribute/
>>
>>
>>             On 3/20/2013 5:45 AM, Laurent Bourg?s wrote:
>>
>>             Hi mandy,
>>
>>             Do you want me to propose an improved patch to remove the
>>             former Map and
>>             fix the getLevel() method ? or you prefer fix on your own ?
>>
>>             Is it better to discuss the fix on the bug database
>>             (still not visible) ?
>>
>>             Laurent
>>
>>             2013/3/19 Mandy Chung >             >
>>
>>                   Hi Laurent,
>>
>>                 Thanks for the contribution.  I agree that the map
>>                 can be replaced with a
>>                 direct mapping from a int value to Level object and
>>                 avoid the autoboxing
>>                 conversion.
>>
>>                 I have filed a bug to track this and target this for
>>                 JDK8:
>>                 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=
>>                 8010309
>>
>>                 Thanks
>>                 Mandy
>>
>>
>>                 On 3/19/13 5:19 AM, Laurent Bourg?s wrote:
>>
>>                 Dear all,
>>
>>                 I run recently netbeans profiler on my swing
>>                 application (Aspro2:http://www.jmmc.fr/aspro
>>                 ) under linux x64 platform and figured out a
>>                 performance and waste issue related to PlatformLogger.
>>
>>                 Actually, the JavaLogger implementation uses a
>>                 Map
>>                 levelObjects to store mapping between
>>                 PlatformLogger's levels (int) and JUL
>>                 Level instances.
>>
>>                 However, the isLoggable(int level) method is highly
>>                 used by awt project and
>>                 other JDK projects and it leads to many Integer
>>                 allocations as autoboxing
>>                 converts the level as int to an Integer instance used
>>                 by the Map.get() call.
>>
>>                      /**
>>                       * JavaLogger forwards all the calls to its
>>                 corresponding
>>                       * java.util.logging.Logger object.
>>                       */
>>                      static class JavaLogger extends LoggerProxy {
>>                          private static final* Map*
>>                 levelObjects = new
>>                 HashMap<>();
>>                 ...
>>                          public boolean isLoggable(*int level*) {
>>                              return
>>                 LoggingSupport.isLoggable(javaLogger, *
>>                 levelObjects.get(level)*);
>>                          }
>>                      }
>>
>>                 I wrote a simple test to illustrate that performance
>>                 / waste problem:
>>                 PlatformLoggerTest that simply performs 1 million
>>                 DISABLED log statements:
>>                              if (log.isLoggable(PlatformLogger.FINEST)) {
>>                                  log.finest("test
>>                 PlatformLogger.FINEST");
>>                              }
>>
>>                 As you can see in screenshots:
>>                 - 5 million Integer instances are allocated
>>                 - Integer.valueOf(int) is called 5 million times
>>                 (autoboxing)
>>                 - HashMap.get() represents 30% of the test time
>>                 - patched PlatformLogger is 3x times faster
>>                 [jvm options: -Xms8m -Xmx8m -verbose:gc]
>>
>>                 I suggest you to use an alternative way to map
>>                 PlatformLogger's levels
>>                 (int) and JUL Level instances to fix that performance
>>                 / memory issue: I
>>                 added the getLevel(int level) method that performs a
>>                 switch case to return
>>                 the corresponding Level object (quick and dirty
>>                 solution).
>>
>>                 I advocate this is not a very clean solution but I
>>                 prefer efficiency here:
>>                 any better solution may be appropriate to avoid at
>>                 least Integer allocation
>>                 and maybe enhance performance.
>>
>>                 Best regards,
>>                 Laurent Bourg?s
>>
>>                 PS: here is the patch as text:
>>
>>                 # This patch file was generated by NetBeans IDE
>>                 # It uses platform neutral UTF-8 encoding and \n
>>                 newlines.
>>                 --- PlatformLogger.java (6767)
>>                 +++ PlatformLogger.java (6768)
>>                 @@ -468,31 +468,13 @@
>>                        * java.util.logging.Logger object.
>>                        */
>>                       static class JavaLogger extends LoggerProxy {
>>                 -        /** Note: using Integer keys leads to a lot
>>                 of new Integer
>>                 instances !! */
>>                 -        private static final Map
>>                 levelObjects = new
>>                 HashMap<>();
>>                 -        /** fastest mapping to Level instances from
>>                 PlatformLogger level
>>                 as integer */
>>                 -        private static final Object[] fastLevelObjects;
>>                 -
>>                 -
>>                 +        private static final Map
>>                 levelObjects =
>>                 +            new HashMap<>();
>>                 +
>>                           static {
>>                               if (LoggingSupport.isAvailable()) {
>>                                   // initialize the map to Level objects
>>                                   getLevelObjects();
>>                 -
>>                 -                // initialize the fastLevelObjects:
>>                 -                fastLevelObjects = new Object[] {
>>                 -  LoggingSupport.parseLevel(getLevelName(OFF)),   //
>>                 0
>>                 -  LoggingSupport.parseLevel(getLevelName(SEVERE)),    //
>>                 1
>>                 -  LoggingSupport.parseLevel(getLevelName(WARNING)),   //
>>                 2
>>                 -  LoggingSupport.parseLevel(getLevelName(INFO)),    //
>>                 3
>>                 -  LoggingSupport.parseLevel(getLevelName(CONFIG)),    //
>>                 4
>>                 -  LoggingSupport.parseLevel(getLevelName(FINE)),    //
>>                 5
>>                 -  LoggingSupport.parseLevel(getLevelName(FINER)),   //
>>                 6
>>                 -  LoggingSupport.parseLevel(getLevelName(FINEST)),    //
>>                 7
>>                 -  LoggingSupport.parseLevel(getLevelName(ALL))    //
>>                 8
>>                 -                };
>>                 -            } else {
>>                 -                fastLevelObjects = null; // check null
>>                               }
>>                           }
>>
>>                 @@ -515,7 +497,7 @@
>>                               this.javaLogger =
>>                 LoggingSupport.getLogger(name);
>>                               if (level != 0) {
>>                                   // level has been updated and so
>>                 set the Logger's level
>>                 -  LoggingSupport.setLevel(javaLogger, getLevel(level));
>>                 +  LoggingSupport.setLevel(javaLogger,
>>                 levelObjects.get(level));
>>                               }
>>                           }
>>
>>                 @@ -526,11 +508,11 @@
>>                           * not be updated.
>>                           */
>>                           void doLog(int level, String msg) {
>>                 -            LoggingSupport.log(javaLogger,
>>                 getLevel(level), msg);
>>                 +            LoggingSupport.log(javaLogger,
>>                 levelObjects.get(level), msg);
>>                           }
>>
>>                           void doLog(int level, String msg, Throwable
>>                 t) {
>>                 -            LoggingSupport.log(javaLogger,
>>                 getLevel(level), msg, t);
>>                 +            LoggingSupport.log(javaLogger,
>>                 levelObjects.get(level), msg,
>>                 t);
>>                           }
>>
>>                           void doLog(int level, String msg, Object...
>>                 params) {
>>                 @@ -544,12 +526,12 @@
>>                               for (int i = 0; i < len; i++) {
>>                                   sparams [i] =
>>                 String.valueOf(params[i]);
>>                               }
>>                 -            LoggingSupport.log(javaLogger,
>>                 getLevel(level), msg, sparams);
>>                 +            LoggingSupport.log(javaLogger,
>>                 levelObjects.get(level), msg,
>>                 sparams);
>>                           }
>>
>>                           boolean isEnabled() {
>>                               Object level =
>>                 LoggingSupport.getLevel(javaLogger);
>>                 -            return level == null ||
>>                 level.equals(getLevel(OFF)) == false;
>>                 +            return level == null ||
>>                 level.equals(levelObjects.get(OFF)) ==
>>                 false;
>>                           }
>>
>>                           int getLevel() {
>>                 @@ -566,34 +548,12 @@
>>
>>                           void setLevel(int newLevel) {
>>                               levelValue = newLevel;
>>                 -            LoggingSupport.setLevel(javaLogger,
>>                 getLevel(newLevel));
>>                 +            LoggingSupport.setLevel(javaLogger,
>>                 levelObjects.get(newLevel));
>>                           }
>>
>>                           public boolean isLoggable(int level) {
>>                 -            return
>>                 LoggingSupport.isLoggable(javaLogger, getLevel(level));
>>                 +            return LoggingSupport.isLoggable(javaLogger,
>>                 levelObjects.get(level));
>>                           }
>>                 -
>>                 -        /**
>>                 -         * Return the corresponding level object
>>                 (fastest implementation)
>>                 -         * @param level PlatformLogger level as
>>                 primitive integer
>>                 -         * @return Object (JUL Level instance)
>>                 -         */
>>                 -        private static Object getLevel(final int
>>                 level) {
>>                 -            // higher occurences first (finest,
>>                 fine, finer, info):
>>                 -            switch (level) {
>>                 -                case FINEST  : return
>>                 fastLevelObjects[7];
>>                 -                case FINE    : return
>>                 fastLevelObjects[5];
>>                 -                case FINER   : return
>>                 fastLevelObjects[6];
>>                 -                case INFO    : return
>>                 fastLevelObjects[3];
>>                 -                case CONFIG  : return
>>                 fastLevelObjects[4];
>>                 -                case WARNING : return
>>                 fastLevelObjects[2];
>>                 -                case SEVERE  : return
>>                 fastLevelObjects[1];
>>                 -                case ALL     : return
>>                 fastLevelObjects[8];
>>                 -                case OFF     : return
>>                 fastLevelObjects[0];
>>                 -                default      : return null;
>>                 -            }
>>                 -        }
>>                 -
>>                       }
>>
>>                       private static String getLevelName(int level) {
>>
>>
>>
>>
>>
>>
>



From xueming.shen at oracle.com  Thu Mar 21 15:05:02 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 21 Mar 2013 08:05:02 -0700
Subject: zip64 compatibility problems
In-Reply-To: <51188FE8.40604@oracle.com>
References: 
	<50F6010D.5000806@oracle.com>
	
	
	
	<5100C3D2.6040604@oracle.com>
	
	
	<5113D311.7060006@oracle.com>
	
	<51161BD6.3040608@gmail.com>
	
	<51188FE8.40604@oracle.com>
Message-ID: <514B219E.8080200@oracle.com>

Martin, 8007905 has been approved.

On 2/10/13 10:30 PM, Xueming Shen wrote:
> 8007905.
>
> But you will have to hold the push. I will send it through the CCC.
>
> -Sherman
>
> On 2/10/2013 7:59 PM, Martin Buchholz wrote:
>> On Sat, Feb 9, 2013 at 1:50 AM, Peter Levart  
>> wrote:
>>
>>> Also, this does not disable ZIP64 - it only disables it when it is not
>>> needed (most other zip implementations can still read the output) 
>>> "inhibit"
>>> seems better than "disable".
>>>
>>>
>>> disfavor ?
>>>
>>>
>> I went for "inhibit".
>>
>> There's now a shiny new test case .
>> Same Bat Place:
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/useZip64For64kEntries/ 
>>
>> I am now happy with this change and would like to submit.
>> As always, I need a bug id.



From bourges.laurent at gmail.com  Thu Mar 21 15:06:08 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Thu, 21 Mar 2013 16:06:08 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due to
	HashMap leads to Integer allocations (boxing)
In-Reply-To: <514B1F38.9070604@oracle.com>
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
Message-ID: 

Thanks Mandy for the clarifications !

Peter, I propose to:
- move the LevelEnum into the JavaLogger class in order to initialize it as
later as possible i.e. after j.u.l calls redirectPlatformLoggers()
- only use it in JavaLogger class (private enum) so revert changes to
PlatformLogger and LoggerProxy classes
- add few comments in the code to explain lazy initialization (see mandy's
answer)

Finally, could you keep my comment before the switch case (high occurences
first) ?

+        static LevelEnum forValue(int levelValue) {
+            // higher occurences first (finest, fine, finer, info)
+            // based on isLoggable(level) calls (03/20/2013)
+            // in jdk project only (including generated sources)
+            switch (levelValue) {
+                case PlatformLogger.FINEST:  return FINEST;  // 116 +
2257 matches in generated files
+                case PlatformLogger.FINE:    return FINE;    // 270
+                case PlatformLogger.FINER:   return FINER;   // 157
+                case PlatformLogger.INFO:    return INFO;    // 39
+                case PlatformLogger.WARNING: return WARNING; // 12
+                case PlatformLogger.CONFIG:  return CONFIG;  // 6
+                case PlatformLogger.SEVERE:  return SEVERE;  // 1
+                case PlatformLogger.OFF:     return OFF;     // 0
+                case PlatformLogger.ALL:     return ALL;     // 0
+                default:                     return UNKNOWN;
+            }
+        }

cheers,
Laurent


2013/3/21 Mandy Chung 

>  Laurent, Peter,
>
> I haven't looked at the patch yet.  One thing worths mentioning is that
> PlatformLogger was added for the platform code to use so as to avoid the
> initialization of java.util.logging since logging is not turned on by
> default and that to reduce the startup overhead.   In addition, it also
> enables the elimination of the core classes dependency from
> java.util.logging for modularization effort.  Therefore the PlatformLogger
> only lazily looks up the Level object when java.util.logging is present and
> also has been initialized by application code.
>
> Mandy
>
>
> On 3/21/2013 7:45 AM, Peter Levart wrote:
>
> On 03/21/2013 03:30 PM, Laurent Bourg?s wrote:
>
> Peter,
>
> your solution looks better; I wanted my patch to be simple, efficient and
> only modify the JavaLogger class (localized changes).
>
> In your patch, I have doubts related to lazy and conditional
> initialization in JavaLogger (static initialization):
>
> if (LoggingSupport.isAvailable()) {
>     // initialize ...
> }
>
>
> In original code, if LoggingSupport.isAvailable() returned false, levelObjects
> map remained empty and consequently null was used as the level object
> passed to LoggingSupport methods. In LevelEnum I try to keep this logic.
> When LevelEnum is first used, it's constants are initialized and level
> objects with them. If
> LoggingSupport.isAvailable() returns false, level objects are initialized
> to null.
>
> I just noticed there's a bug in initialization of the LevelEnum.UNKNOWN
> member constant. It should not try to parse level object. Here's an update:
>
>
> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.02/index.html
>
> But your concern might be correct. In my code LevelEnum is also used from
> the LoggerProxy.format() method (in addition to all the places in
> JavaLogger) to obtain the level name for formatting. If this method is
> called the first time while LoggingSupport.isAvailable() returns false
> and that happens before JavaLogger uses LevelEnum for the first time (and
> at that time LoggingSupport.isAvailable() would return true), then level
> objects will not be initialized correctly.
>
> Lazy initialization of level objects might help (for the price of added
> complexity)...
>
> Regards, Peter
>
>  Does somebody have the knowledge about LoggingSupport.isAvailable()
> and the lazy PlatformLogger initialization (JavaLogger are only used when j.u.l is initialized) ?
>
> What's happening if LoggingSupport.isAvailable() returns false in your patch ? - LevelEnum instances are incorrectly initialized: object field is null !
> - PlatformLogger is then broken ... as Level object are required by j.u.l calls
> To fix both problems, moving the LevelEnum into JavaLogger should help and check nulls on LevelEnum.object field.
>
> Thanks for your feedback,Laurent
>
>  2013/3/21 Peter Levart 
>
>> On 03/21/2013 12:12 PM, Laurent Bourg?s wrote:
>>
>>> Here is an improved patch tested on JDK7u13 and JDK8 internal build on my
>>>  machine linux x64:
>>> http://jmmc.fr/~bourgesl/share/webrev-8010309/
>>>
>>> FYI, I removed completely the Map levelObjects and used
>>> two arrays to perform the PlatformLogger's level (int) to j.u.l.Level
>>> mapping:
>>>
>>> I decided to keep it simple as possible (no enum ...) and used a switch
>>> case based on current level occurences:
>>>
>>
>>  Hi Laurent,
>>
>> In my experience enums are just the right and most compact tool for
>> coding such constant associations. Here's a quick try (ripping off your
>> optimized switch ;-):
>>
>>
>> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.01/index.html
>>
>> ...it adds 12 LOC to the original PlatformLogger and is 43 LOC less tha
>> your patch. In addition:
>>
>> - only one switch instead of two (to maintain)
>> - no parallel IDX_ constants
>>
>> What do you think?
>>
>> Regards, Peter
>>
>>
>>
>>>   510         /**
>>>   511          * Return the corresponding j.u.l.Level instance
>>>   512          * @param level PlatformLogger level as integer
>>>   513          * @return Object (j.u.l.Level instance) or null if no
>>> matching level
>>>   514          */
>>>   515         private static Object getLevel(final int level) {
>>>   516             if (levelObjects == null) {
>>>   517                 return null;
>>>   518             }
>>>   519             // higher occurences first (finest, fine, finer, info)
>>>   520             // based on isLoggable(level) calls (03/20/2013)
>>>   521             // in jdk project only (including generated sources)
>>>   522             switch (level) {
>>>   523                 case FINEST  : return levelObjects[IDX_FINEST];
>>> // 116 + 2257 matches in generated files
>>>   524                 case FINE    : return levelObjects[IDX_FINE];
>>>  // 270
>>>   525                 case FINER   : return levelObjects[IDX_FINER];
>>> // 157
>>>   526                 case INFO    : return levelObjects[IDX_INFO];
>>>  // 39
>>>   527                 case WARNING : return levelObjects[IDX_WARNING];
>>> // 12
>>>   528                 case CONFIG  : return levelObjects[IDX_CONFIG];
>>>  // 6
>>>   529                 case SEVERE  : return levelObjects[IDX_SEVERE];
>>>  // 1
>>>   530                 case OFF     : return levelObjects[IDX_OFF];
>>> // 0
>>>   531                 case ALL     : return levelObjects[IDX_ALL];
>>> // 0
>>>   532                 default      : return null;
>>>   533             }
>>>   534         }
>>>
>>> I enhanced the PlatformLoggerTest class also and figured out that TLAB
>>> optimized Integer allocations but I think the patch is still useful.
>>>
>>> Can you have a look to the patch ?
>>> Should I write a jtreg test  (performance / GC issue) ?
>>>
>>> Cheers,
>>> Laurent
>>>
>>>
>>> 2013/3/20 Mandy Chung 
>>>
>>>    Hi Laurent,
>>>>
>>>> Thank you for signing the OCA.  Your contribution is very welcome.  You
>>>> can submit a patch for this bug (see [1]) to Core libraries group which
>>>> owns logging.  Jim Gish and I will sponsor it.
>>>>
>>>> Thanks
>>>> Mandy
>>>> [1] http://openjdk.java.net/contribute/
>>>>
>>>>
>>>> On 3/20/2013 5:45 AM, Laurent Bourg?s wrote:
>>>>
>>>> Hi mandy,
>>>>
>>>> Do you want me to propose an improved patch to remove the former Map and
>>>> fix the getLevel() method ? or you prefer fix on your own ?
>>>>
>>>> Is it better to discuss the fix on the bug database (still not visible)
>>>> ?
>>>>
>>>> Laurent
>>>>
>>>> 2013/3/19 Mandy Chung 
>>>>
>>>>    Hi Laurent,
>>>>>
>>>>> Thanks for the contribution.  I agree that the map can be replaced
>>>>> with a
>>>>> direct mapping from a int value to Level object and avoid the
>>>>> autoboxing
>>>>> conversion.
>>>>>
>>>>> I have filed a bug to track this and target this for JDK8:
>>>>>    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id= 8010309
>>>>>
>>>>> Thanks
>>>>> Mandy
>>>>>
>>>>>
>>>>> On 3/19/13 5:19 AM, Laurent Bourg?s wrote:
>>>>>
>>>>> Dear all,
>>>>>
>>>>> I run recently netbeans profiler on my swing application (Aspro2:
>>>>> http://www.jmmc.fr/aspro
>>>>> ) under linux x64 platform and figured out a
>>>>> performance and waste issue related to PlatformLogger.
>>>>>
>>>>> Actually, the JavaLogger implementation uses a Map
>>>>> levelObjects to store mapping between PlatformLogger's levels (int)
>>>>> and JUL
>>>>> Level instances.
>>>>>
>>>>> However, the isLoggable(int level) method is highly used by awt
>>>>> project and
>>>>> other JDK projects and it leads to many Integer allocations as
>>>>> autoboxing
>>>>> converts the level as int to an Integer instance used by the Map.get()
>>>>> call.
>>>>>
>>>>>      /**
>>>>>       * JavaLogger forwards all the calls to its corresponding
>>>>>       * java.util.logging.Logger object.
>>>>>       */
>>>>>      static class JavaLogger extends LoggerProxy {
>>>>>          private static final* Map* levelObjects = new
>>>>> HashMap<>();
>>>>> ...
>>>>>          public boolean isLoggable(*int level*) {
>>>>>              return LoggingSupport.isLoggable(javaLogger, *
>>>>> levelObjects.get(level)*);
>>>>>          }
>>>>>      }
>>>>>
>>>>> I wrote a simple test to illustrate that performance / waste problem:
>>>>> PlatformLoggerTest that simply performs 1 million DISABLED log
>>>>> statements:
>>>>>              if (log.isLoggable(PlatformLogger.FINEST)) {
>>>>>                  log.finest("test PlatformLogger.FINEST");
>>>>>              }
>>>>>
>>>>> As you can see in screenshots:
>>>>> - 5 million Integer instances are allocated
>>>>> - Integer.valueOf(int) is called 5 million times (autoboxing)
>>>>> - HashMap.get() represents 30% of the test time
>>>>> - patched PlatformLogger is 3x times faster
>>>>> [jvm options: -Xms8m -Xmx8m -verbose:gc]
>>>>>
>>>>> I suggest you to use an alternative way to map PlatformLogger's levels
>>>>> (int) and JUL Level instances to fix that performance / memory issue: I
>>>>> added the getLevel(int level) method that performs a switch case to
>>>>> return
>>>>> the corresponding Level object (quick and dirty solution).
>>>>>
>>>>> I advocate this is not a very clean solution but I prefer efficiency
>>>>> here:
>>>>> any better solution may be appropriate to avoid at least Integer
>>>>> allocation
>>>>> and maybe enhance performance.
>>>>>
>>>>> Best regards,
>>>>> Laurent Bourg?s
>>>>>
>>>>> PS: here is the patch as text:
>>>>>
>>>>> # This patch file was generated by NetBeans IDE
>>>>> # It uses platform neutral UTF-8 encoding and \n newlines.
>>>>> --- PlatformLogger.java (6767)
>>>>> +++ PlatformLogger.java (6768)
>>>>> @@ -468,31 +468,13 @@
>>>>>        * java.util.logging.Logger object.
>>>>>        */
>>>>>       static class JavaLogger extends LoggerProxy {
>>>>> -        /** Note: using Integer keys leads to a lot of new Integer
>>>>> instances !! */
>>>>> -        private static final Map levelObjects = new
>>>>> HashMap<>();
>>>>> -        /** fastest mapping to Level instances from PlatformLogger
>>>>> level
>>>>> as integer */
>>>>> -        private static final Object[] fastLevelObjects;
>>>>> -
>>>>> -
>>>>> +        private static final Map levelObjects =
>>>>> +            new HashMap<>();
>>>>> +
>>>>>           static {
>>>>>               if (LoggingSupport.isAvailable()) {
>>>>>                   // initialize the map to Level objects
>>>>>                   getLevelObjects();
>>>>> -
>>>>> -                // initialize the fastLevelObjects:
>>>>> -                fastLevelObjects = new Object[] {
>>>>> -                    LoggingSupport.parseLevel(getLevelName(OFF)),
>>>>>   //
>>>>> 0
>>>>> -                    LoggingSupport.parseLevel(getLevelName(SEVERE)),
>>>>>    //
>>>>> 1
>>>>> -                    LoggingSupport.parseLevel(getLevelName(WARNING)),
>>>>>   //
>>>>> 2
>>>>> -                    LoggingSupport.parseLevel(getLevelName(INFO)),
>>>>>    //
>>>>> 3
>>>>> -                    LoggingSupport.parseLevel(getLevelName(CONFIG)),
>>>>>    //
>>>>> 4
>>>>> -                    LoggingSupport.parseLevel(getLevelName(FINE)),
>>>>>    //
>>>>> 5
>>>>> -                    LoggingSupport.parseLevel(getLevelName(FINER)),
>>>>>   //
>>>>> 6
>>>>> -                    LoggingSupport.parseLevel(getLevelName(FINEST)),
>>>>>    //
>>>>> 7
>>>>> -                    LoggingSupport.parseLevel(getLevelName(ALL))
>>>>>    //
>>>>> 8
>>>>> -                };
>>>>> -            } else {
>>>>> -                fastLevelObjects = null; // check null
>>>>>               }
>>>>>           }
>>>>>
>>>>> @@ -515,7 +497,7 @@
>>>>>               this.javaLogger = LoggingSupport.getLogger(name);
>>>>>               if (level != 0) {
>>>>>                   // level has been updated and so set the Logger's
>>>>> level
>>>>> -                LoggingSupport.setLevel(javaLogger, getLevel(level));
>>>>> +                LoggingSupport.setLevel(javaLogger,
>>>>> levelObjects.get(level));
>>>>>               }
>>>>>           }
>>>>>
>>>>> @@ -526,11 +508,11 @@
>>>>>           * not be updated.
>>>>>           */
>>>>>           void doLog(int level, String msg) {
>>>>> -            LoggingSupport.log(javaLogger, getLevel(level), msg);
>>>>> +            LoggingSupport.log(javaLogger, levelObjects.get(level),
>>>>> msg);
>>>>>           }
>>>>>
>>>>>           void doLog(int level, String msg, Throwable t) {
>>>>> -            LoggingSupport.log(javaLogger, getLevel(level), msg, t);
>>>>> +            LoggingSupport.log(javaLogger, levelObjects.get(level),
>>>>> msg,
>>>>> t);
>>>>>           }
>>>>>
>>>>>           void doLog(int level, String msg, Object... params) {
>>>>> @@ -544,12 +526,12 @@
>>>>>               for (int i = 0; i < len; i++) {
>>>>>                   sparams [i] = String.valueOf(params[i]);
>>>>>               }
>>>>> -            LoggingSupport.log(javaLogger, getLevel(level), msg,
>>>>> sparams);
>>>>> +            LoggingSupport.log(javaLogger, levelObjects.get(level),
>>>>> msg,
>>>>> sparams);
>>>>>           }
>>>>>
>>>>>           boolean isEnabled() {
>>>>>               Object level = LoggingSupport.getLevel(javaLogger);
>>>>> -            return level == null || level.equals(getLevel(OFF)) ==
>>>>> false;
>>>>> +            return level == null ||
>>>>> level.equals(levelObjects.get(OFF)) ==
>>>>> false;
>>>>>           }
>>>>>
>>>>>           int getLevel() {
>>>>> @@ -566,34 +548,12 @@
>>>>>
>>>>>           void setLevel(int newLevel) {
>>>>>               levelValue = newLevel;
>>>>> -            LoggingSupport.setLevel(javaLogger, getLevel(newLevel));
>>>>> +            LoggingSupport.setLevel(javaLogger,
>>>>> levelObjects.get(newLevel));
>>>>>           }
>>>>>
>>>>>           public boolean isLoggable(int level) {
>>>>> -            return LoggingSupport.isLoggable(javaLogger,
>>>>> getLevel(level));
>>>>> +            return LoggingSupport.isLoggable(javaLogger,
>>>>> levelObjects.get(level));
>>>>>           }
>>>>> -
>>>>> -        /**
>>>>> -         * Return the corresponding level object (fastest
>>>>> implementation)
>>>>> -         * @param level PlatformLogger level as primitive integer
>>>>> -         * @return Object (JUL Level instance)
>>>>> -         */
>>>>> -        private static Object getLevel(final int level) {
>>>>> -            // higher occurences first (finest, fine, finer, info):
>>>>> -            switch (level) {
>>>>> -                case FINEST  : return fastLevelObjects[7];
>>>>> -                case FINE    : return fastLevelObjects[5];
>>>>> -                case FINER   : return fastLevelObjects[6];
>>>>> -                case INFO    : return fastLevelObjects[3];
>>>>> -                case CONFIG  : return fastLevelObjects[4];
>>>>> -                case WARNING : return fastLevelObjects[2];
>>>>> -                case SEVERE  : return fastLevelObjects[1];
>>>>> -                case ALL     : return fastLevelObjects[8];
>>>>> -                case OFF     : return fastLevelObjects[0];
>>>>> -                default      : return null;
>>>>> -            }
>>>>> -        }
>>>>> -
>>>>>       }
>>>>>
>>>>>       private static String getLevelName(int level) {
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>
>
>
>


From peter.levart at gmail.com  Thu Mar 21 15:06:20 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 21 Mar 2013 16:06:20 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due
	to HashMap leads to Integer allocations (boxing)
In-Reply-To: <514B1D06.10007@gmail.com>
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com>
Message-ID: <514B21EC.3040502@gmail.com>

Hi Laurent,

I checked and LoggingSupport.isAvailable() can only return false in two 
situations:

- no "java.util.logging.LoggingProxyImpl" class is found (but that is a 
permanent condition and almost all LoggingSupport methods are 
non-operational in that case)
- there is a circularity of class initialization present and a dependent 
class tries to use LoggingSupport before it's static final field is set. 
That is only possible if java.util.logging.LoggingProxyImpl 
initialization caused that circularity. LoggingProxyImpl is only 
dependent on sun.util.logging.LoggingProxy interface which has no static 
initializers and LoggingProxyImpl has a simple static initializer 
setting static final INSTANCE field to a singleton instance and it has 
an empty private constructor. Therefore no class initialization 
circularity is possible in this situation (I think).

Regards, Peter

On 03/21/2013 03:45 PM, Peter Levart wrote:
> On 03/21/2013 03:30 PM, Laurent Bourg?s wrote:
>> Peter,
>>
>> your solution looks better; I wanted my patch to be simple, efficient 
>> and only modify the JavaLogger class (localized changes).
>>
>> In your patch, I have doubts related to lazy and conditional 
>> initialization in JavaLogger (static initialization):
>> if (LoggingSupport.isAvailable()) {
>>      // initialize ...
>> }
>
> In original code, if LoggingSupport.isAvailable() returned false, 
> levelObjects map remained empty and consequently null was used as the 
> level object passed to LoggingSupport methods. In LevelEnum I try to 
> keep this logic. When LevelEnum is first used, it's constants are 
> initialized and level objects with them. If
> LoggingSupport.isAvailable() returns false, level objects are 
> initialized to null.
>
> I just noticed there's a bug in initialization of the 
> LevelEnum.UNKNOWN member constant. It should not try to parse level 
> object. Here's an update:
>
> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.02/index.html
>
> But your concern might be correct. In my code LevelEnum is also used 
> from the LoggerProxy.format() method (in addition to all the places in 
> JavaLogger) to obtain the level name for formatting. If this method is 
> called the first time while LoggingSupport.isAvailable() returns false 
> and that happens before JavaLogger uses LevelEnum for the first time 
> (and at that time LoggingSupport.isAvailable() would return true), 
> then level objects will not be initialized correctly.
>
> Lazy initialization of level objects might help (for the price of 
> added complexity)...
>
> Regards, Peter
>
>> Does somebody have the knowledge about LoggingSupport.isAvailable()
>>
>> and the lazy PlatformLogger initialization (JavaLogger are only used when j.u.l is initialized) ?
>>
>>
>> What's happening if LoggingSupport.isAvailable() returns false in your patch ?
>> - LevelEnum  instances are incorrectly initialized:object field is null !
>>
>> - PlatformLogger is then broken ... as Level object are required by j.u.l calls
>>
>>
>> To fix both problems, moving theLevelEnum  into JavaLogger should help and check nulls onLevelEnum.object field.
>>
>>
>> Thanks for your feedback,
>> Laurent
>>
>>
>> 2013/3/21 Peter Levart > >
>>
>>     On 03/21/2013 12:12 PM, Laurent Bourg?s wrote:
>>
>>         Here is an improved patch tested on JDK7u13 and JDK8 internal
>>         build on my
>>         machine linux x64:
>>         http://jmmc.fr/~bourgesl/share/webrev-8010309/
>>         
>>
>>         FYI, I removed completely the Map
>>         levelObjects and used
>>         two arrays to perform the PlatformLogger's level (int) to
>>         j.u.l.Level
>>         mapping:
>>
>>         I decided to keep it simple as possible (no enum ...) and
>>         used a switch
>>         case based on current level occurences:
>>
>>
>>     Hi Laurent,
>>
>>     In my experience enums are just the right and most compact tool
>>     for coding such constant associations. Here's a quick try
>>     (ripping off your optimized switch ;-):
>>
>>     http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.01/index.html
>>
>>     ...it adds 12 LOC to the original PlatformLogger and is 43 LOC
>>     less tha your patch. In addition:
>>
>>     - only one switch instead of two (to maintain)
>>     - no parallel IDX_ constants
>>
>>     What do you think?
>>
>>     Regards, Peter
>>
>>
>>
>>           510         /**
>>           511          * Return the corresponding j.u.l.Level instance
>>           512          * @param level PlatformLogger level as integer
>>           513          * @return Object (j.u.l.Level instance) or
>>         null if no
>>         matching level
>>           514          */
>>           515         private static Object getLevel(final int level) {
>>           516             if (levelObjects == null) {
>>           517                 return null;
>>           518             }
>>           519             // higher occurences first (finest, fine,
>>         finer, info)
>>           520             // based on isLoggable(level) calls
>>         (03/20/2013)
>>           521             // in jdk project only (including generated
>>         sources)
>>           522             switch (level) {
>>           523                 case FINEST  : return
>>         levelObjects[IDX_FINEST];
>>         // 116 + 2257 matches in generated files
>>           524                 case FINE    : return
>>         levelObjects[IDX_FINE];    // 270
>>           525                 case FINER   : return
>>         levelObjects[IDX_FINER];   // 157
>>           526                 case INFO    : return
>>         levelObjects[IDX_INFO];    // 39
>>           527                 case WARNING : return
>>         levelObjects[IDX_WARNING]; // 12
>>           528                 case CONFIG  : return
>>         levelObjects[IDX_CONFIG];  // 6
>>           529                 case SEVERE  : return
>>         levelObjects[IDX_SEVERE];  // 1
>>           530                 case OFF     : return
>>         levelObjects[IDX_OFF];     // 0
>>           531                 case ALL     : return
>>         levelObjects[IDX_ALL];     // 0
>>           532                 default      : return null;
>>           533             }
>>           534         }
>>
>>         I enhanced the PlatformLoggerTest class also and figured out
>>         that TLAB
>>         optimized Integer allocations but I think the patch is still
>>         useful.
>>
>>         Can you have a look to the patch ?
>>         Should I write a jtreg test  (performance / GC issue) ?
>>
>>         Cheers,
>>         Laurent
>>
>>
>>         2013/3/20 Mandy Chung >         >
>>
>>               Hi Laurent,
>>
>>             Thank you for signing the OCA.  Your contribution is very
>>             welcome.  You
>>             can submit a patch for this bug (see [1]) to Core
>>             libraries group which
>>             owns logging.  Jim Gish and I will sponsor it.
>>
>>             Thanks
>>             Mandy
>>             [1] http://openjdk.java.net/contribute/
>>
>>
>>             On 3/20/2013 5:45 AM, Laurent Bourg?s wrote:
>>
>>             Hi mandy,
>>
>>             Do you want me to propose an improved patch to remove the
>>             former Map and
>>             fix the getLevel() method ? or you prefer fix on your own ?
>>
>>             Is it better to discuss the fix on the bug database
>>             (still not visible) ?
>>
>>             Laurent
>>
>>             2013/3/19 Mandy Chung >             >
>>
>>                   Hi Laurent,
>>
>>                 Thanks for the contribution.  I agree that the map
>>                 can be replaced with a
>>                 direct mapping from a int value to Level object and
>>                 avoid the autoboxing
>>                 conversion.
>>
>>                 I have filed a bug to track this and target this for
>>                 JDK8:
>>                 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=
>>                 8010309
>>
>>                 Thanks
>>                 Mandy
>>
>>
>>                 On 3/19/13 5:19 AM, Laurent Bourg?s wrote:
>>
>>                 Dear all,
>>
>>                 I run recently netbeans profiler on my swing
>>                 application (Aspro2:http://www.jmmc.fr/aspro
>>                 ) under linux x64 platform and figured out a
>>                 performance and waste issue related to PlatformLogger.
>>
>>                 Actually, the JavaLogger implementation uses a
>>                 Map
>>                 levelObjects to store mapping between
>>                 PlatformLogger's levels (int) and JUL
>>                 Level instances.
>>
>>                 However, the isLoggable(int level) method is highly
>>                 used by awt project and
>>                 other JDK projects and it leads to many Integer
>>                 allocations as autoboxing
>>                 converts the level as int to an Integer instance used
>>                 by the Map.get() call.
>>
>>                      /**
>>                       * JavaLogger forwards all the calls to its
>>                 corresponding
>>                       * java.util.logging.Logger object.
>>                       */
>>                      static class JavaLogger extends LoggerProxy {
>>                          private static final* Map*
>>                 levelObjects = new
>>                 HashMap<>();
>>                 ...
>>                          public boolean isLoggable(*int level*) {
>>                              return
>>                 LoggingSupport.isLoggable(javaLogger, *
>>                 levelObjects.get(level)*);
>>                          }
>>                      }
>>
>>                 I wrote a simple test to illustrate that performance
>>                 / waste problem:
>>                 PlatformLoggerTest that simply performs 1 million
>>                 DISABLED log statements:
>>                              if (log.isLoggable(PlatformLogger.FINEST)) {
>>                                  log.finest("test
>>                 PlatformLogger.FINEST");
>>                              }
>>
>>                 As you can see in screenshots:
>>                 - 5 million Integer instances are allocated
>>                 - Integer.valueOf(int) is called 5 million times
>>                 (autoboxing)
>>                 - HashMap.get() represents 30% of the test time
>>                 - patched PlatformLogger is 3x times faster
>>                 [jvm options: -Xms8m -Xmx8m -verbose:gc]
>>
>>                 I suggest you to use an alternative way to map
>>                 PlatformLogger's levels
>>                 (int) and JUL Level instances to fix that performance
>>                 / memory issue: I
>>                 added the getLevel(int level) method that performs a
>>                 switch case to return
>>                 the corresponding Level object (quick and dirty
>>                 solution).
>>
>>                 I advocate this is not a very clean solution but I
>>                 prefer efficiency here:
>>                 any better solution may be appropriate to avoid at
>>                 least Integer allocation
>>                 and maybe enhance performance.
>>
>>                 Best regards,
>>                 Laurent Bourg?s
>>
>>                 PS: here is the patch as text:
>>
>>                 # This patch file was generated by NetBeans IDE
>>                 # It uses platform neutral UTF-8 encoding and \n
>>                 newlines.
>>                 --- PlatformLogger.java (6767)
>>                 +++ PlatformLogger.java (6768)
>>                 @@ -468,31 +468,13 @@
>>                        * java.util.logging.Logger object.
>>                        */
>>                       static class JavaLogger extends LoggerProxy {
>>                 -        /** Note: using Integer keys leads to a lot
>>                 of new Integer
>>                 instances !! */
>>                 -        private static final Map
>>                 levelObjects = new
>>                 HashMap<>();
>>                 -        /** fastest mapping to Level instances from
>>                 PlatformLogger level
>>                 as integer */
>>                 -        private static final Object[] fastLevelObjects;
>>                 -
>>                 -
>>                 +        private static final Map
>>                 levelObjects =
>>                 +            new HashMap<>();
>>                 +
>>                           static {
>>                               if (LoggingSupport.isAvailable()) {
>>                                   // initialize the map to Level objects
>>                                   getLevelObjects();
>>                 -
>>                 -                // initialize the fastLevelObjects:
>>                 -                fastLevelObjects = new Object[] {
>>                 -  LoggingSupport.parseLevel(getLevelName(OFF)),   //
>>                 0
>>                 -  LoggingSupport.parseLevel(getLevelName(SEVERE)),    //
>>                 1
>>                 -  LoggingSupport.parseLevel(getLevelName(WARNING)),   //
>>                 2
>>                 -  LoggingSupport.parseLevel(getLevelName(INFO)),    //
>>                 3
>>                 -  LoggingSupport.parseLevel(getLevelName(CONFIG)),    //
>>                 4
>>                 -  LoggingSupport.parseLevel(getLevelName(FINE)),    //
>>                 5
>>                 -  LoggingSupport.parseLevel(getLevelName(FINER)),   //
>>                 6
>>                 -  LoggingSupport.parseLevel(getLevelName(FINEST)),    //
>>                 7
>>                 -  LoggingSupport.parseLevel(getLevelName(ALL))    //
>>                 8
>>                 -                };
>>                 -            } else {
>>                 -                fastLevelObjects = null; // check null
>>                               }
>>                           }
>>
>>                 @@ -515,7 +497,7 @@
>>                               this.javaLogger =
>>                 LoggingSupport.getLogger(name);
>>                               if (level != 0) {
>>                                   // level has been updated and so
>>                 set the Logger's level
>>                 -  LoggingSupport.setLevel(javaLogger, getLevel(level));
>>                 +  LoggingSupport.setLevel(javaLogger,
>>                 levelObjects.get(level));
>>                               }
>>                           }
>>
>>                 @@ -526,11 +508,11 @@
>>                           * not be updated.
>>                           */
>>                           void doLog(int level, String msg) {
>>                 -            LoggingSupport.log(javaLogger,
>>                 getLevel(level), msg);
>>                 +            LoggingSupport.log(javaLogger,
>>                 levelObjects.get(level), msg);
>>                           }
>>
>>                           void doLog(int level, String msg, Throwable
>>                 t) {
>>                 -            LoggingSupport.log(javaLogger,
>>                 getLevel(level), msg, t);
>>                 +            LoggingSupport.log(javaLogger,
>>                 levelObjects.get(level), msg,
>>                 t);
>>                           }
>>
>>                           void doLog(int level, String msg, Object...
>>                 params) {
>>                 @@ -544,12 +526,12 @@
>>                               for (int i = 0; i < len; i++) {
>>                                   sparams [i] =
>>                 String.valueOf(params[i]);
>>                               }
>>                 -            LoggingSupport.log(javaLogger,
>>                 getLevel(level), msg, sparams);
>>                 +            LoggingSupport.log(javaLogger,
>>                 levelObjects.get(level), msg,
>>                 sparams);
>>                           }
>>
>>                           boolean isEnabled() {
>>                               Object level =
>>                 LoggingSupport.getLevel(javaLogger);
>>                 -            return level == null ||
>>                 level.equals(getLevel(OFF)) == false;
>>                 +            return level == null ||
>>                 level.equals(levelObjects.get(OFF)) ==
>>                 false;
>>                           }
>>
>>                           int getLevel() {
>>                 @@ -566,34 +548,12 @@
>>
>>                           void setLevel(int newLevel) {
>>                               levelValue = newLevel;
>>                 -            LoggingSupport.setLevel(javaLogger,
>>                 getLevel(newLevel));
>>                 +            LoggingSupport.setLevel(javaLogger,
>>                 levelObjects.get(newLevel));
>>                           }
>>
>>                           public boolean isLoggable(int level) {
>>                 -            return
>>                 LoggingSupport.isLoggable(javaLogger, getLevel(level));
>>                 +            return LoggingSupport.isLoggable(javaLogger,
>>                 levelObjects.get(level));
>>                           }
>>                 -
>>                 -        /**
>>                 -         * Return the corresponding level object
>>                 (fastest implementation)
>>                 -         * @param level PlatformLogger level as
>>                 primitive integer
>>                 -         * @return Object (JUL Level instance)
>>                 -         */
>>                 -        private static Object getLevel(final int
>>                 level) {
>>                 -            // higher occurences first (finest,
>>                 fine, finer, info):
>>                 -            switch (level) {
>>                 -                case FINEST  : return
>>                 fastLevelObjects[7];
>>                 -                case FINE    : return
>>                 fastLevelObjects[5];
>>                 -                case FINER   : return
>>                 fastLevelObjects[6];
>>                 -                case INFO    : return
>>                 fastLevelObjects[3];
>>                 -                case CONFIG  : return
>>                 fastLevelObjects[4];
>>                 -                case WARNING : return
>>                 fastLevelObjects[2];
>>                 -                case SEVERE  : return
>>                 fastLevelObjects[1];
>>                 -                case ALL     : return
>>                 fastLevelObjects[8];
>>                 -                case OFF     : return
>>                 fastLevelObjects[0];
>>                 -                default      : return null;
>>                 -            }
>>                 -        }
>>                 -
>>                       }
>>
>>                       private static String getLevelName(int level) {
>>
>>
>>
>>
>>
>>
>



From peter.levart at gmail.com  Thu Mar 21 15:11:36 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 21 Mar 2013 16:11:36 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due
	to HashMap leads to Integer allocations (boxing)
In-Reply-To: <514B1D06.10007@gmail.com>
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com>
Message-ID: <514B2328.4000400@gmail.com>

On 03/21/2013 03:45 PM, Peter Levart wrote:
> But your concern might be correct. In my code LevelEnum is also used 
> from the LoggerProxy.format() method (in addition to all the places in 
> JavaLogger) to obtain the level name for formatting. If this method is 
> called the first time while LoggingSupport.isAvailable() returns false 
> and that happens before JavaLogger uses LevelEnum for the first time 
> (and at that time LoggingSupport.isAvailable() would return true), 
> then level objects will not be initialized correctly.

Hi Laurent,

In addition, the following sole PlatformLogger constructor:

     private PlatformLogger(String name) {
         if (loggingEnabled) {
             this.logger = new JavaLogger(name);
         } else {
             this.logger = new LoggerProxy(name);
         }
     }


... indicates that either JavaLogger objects or LoggerProxy objects are 
used but not both (since loggingEnabled is static final). So the above 
concern is ungrounded.

Regards, Peter



From peter.levart at gmail.com  Thu Mar 21 15:31:17 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 21 Mar 2013 16:31:17 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due
	to HashMap leads to Integer allocations (boxing)
In-Reply-To: 
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
Message-ID: <514B27C5.1020605@gmail.com>

Hi Laurent, Mandy,

Let me try one more time (it would be less optimal to have 2 switch 
statements instead of one). Here's the 3rd webrev:

http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.03/index.html

The changes:
- added the comments
- made LevelEnum private (to not be tempted to be used from outside the 
PlatformLogger)
- used the loggingEnabled flag as a pre-check when trying to parse the 
level objects

What do you think?

Regards, Peter

On 03/21/2013 04:06 PM, Laurent Bourg?s wrote:
> Thanks Mandy for the clarifications !
>
> Peter, I propose to:
> - move the LevelEnum into the JavaLogger class in order to initialize 
> it as later as possible i.e. after j.u.l calls redirectPlatformLoggers()
> - only use it in JavaLogger class (private enum) so revert changes to 
> PlatformLogger and LoggerProxy classes
> - add few comments in the code to explain lazy initialization (see 
> mandy's answer)
>
> Finally, could you keep my comment before the switch case (high 
> occurences first) ?
> +        static LevelEnum forValue(int levelValue) {
>
> +            // higher occurences first (finest, fine, finer, info)
> +            // based on isLoggable(level) calls (03/20/2013)
> +            // in jdk project only (including generated sources)
>
> +            switch (levelValue) {
> +                case PlatformLogger.FINEST:  return FINEST;  // 116 + 2257 matches in generated files
> +                case PlatformLogger.FINE:    return FINE;    // 270
>
> +                case PlatformLogger.FINER:   return FINER;   // 157
> +                case PlatformLogger.INFO:    return INFO;    // 39
> +                case PlatformLogger.WARNING: return WARNING; // 12
>
> +                case PlatformLogger.CONFIG:  return CONFIG;  // 6
> +                case PlatformLogger.SEVERE:  return SEVERE;  // 1
> +                case PlatformLogger.OFF:     return OFF;     // 0
>
> +                case PlatformLogger.ALL:     return ALL;     // 0
> +                default:                     return UNKNOWN;
> +            }
>
> +        }
>
> cheers,
> Laurent
>
> 2013/3/21 Mandy Chung  >
>
>     Laurent, Peter,
>
>     I haven't looked at the patch yet.  One thing worths mentioning is
>     that PlatformLogger was added for the platform code to use so as
>     to avoid the initialization of java.util.logging since logging is
>     not turned on by default and that to reduce the startup overhead.
>       In addition, it also enables the elimination of the core classes
>     dependency from java.util.logging for modularization effort. 
>     Therefore the PlatformLogger only lazily looks up the Level object
>     when java.util.logging is present and also has been initialized by
>     application code.
>
>     Mandy
>
>
>     On 3/21/2013 7:45 AM, Peter Levart wrote:
>>     On 03/21/2013 03:30 PM, Laurent Bourg?s wrote:
>>>     Peter,
>>>
>>>     your solution looks better; I wanted my patch to be simple,
>>>     efficient and only modify the JavaLogger class (localized changes).
>>>
>>>     In your patch, I have doubts related to lazy and conditional
>>>     initialization in JavaLogger (static initialization):
>>>     if (LoggingSupport.isAvailable()) {
>>>          // initialize ...
>>>     }
>>
>>     In original code, if LoggingSupport.isAvailable() returned false,
>>     levelObjects map remained empty and consequently null was used as
>>     the level object passed to LoggingSupport methods. In LevelEnum I
>>     try to keep this logic. When LevelEnum is first used, it's
>>     constants are initialized and level objects with them. If
>>     LoggingSupport.isAvailable() returns false, level objects are
>>     initialized to null.
>>
>>     I just noticed there's a bug in initialization of the
>>     LevelEnum.UNKNOWN member constant. It should not try to parse
>>     level object. Here's an update:
>>
>>     http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.02/index.html
>>
>>     But your concern might be correct. In my code LevelEnum is also
>>     used from the LoggerProxy.format() method (in addition to all the
>>     places in JavaLogger) to obtain the level name for formatting. If
>>     this method is called the first time while
>>     LoggingSupport.isAvailable() returns false and that happens
>>     before JavaLogger uses LevelEnum for the first time (and at that
>>     time LoggingSupport.isAvailable() would return true), then level
>>     objects will not be initialized correctly.
>>
>>     Lazy initialization of level objects might help (for the price of
>>     added complexity)...
>>
>>     Regards, Peter
>>
>>>     Does somebody have the knowledge about LoggingSupport.isAvailable()
>>>
>>>     and the lazy PlatformLogger initialization (JavaLogger are only used when j.u.l is initialized) ?
>>>
>>>
>>>     What's happening if LoggingSupport.isAvailable() returns false in your patch ?
>>>     - LevelEnum  instances are incorrectly initialized:object field is null !
>>>
>>>     - PlatformLogger is then broken ... as Level object are required by j.u.l calls
>>>
>>>
>>>     To fix both problems, moving theLevelEnum  into JavaLogger should help and check nulls onLevelEnum.object field.
>>>
>>>
>>>     Thanks for your feedback,
>>>     Laurent
>>>
>>>
>>>     2013/3/21 Peter Levart >>     >
>>>
>>>         On 03/21/2013 12:12 PM, Laurent Bourg?s wrote:
>>>
>>>             Here is an improved patch tested on JDK7u13 and JDK8
>>>             internal build on my
>>>             machine linux x64:
>>>             http://jmmc.fr/~bourgesl/share/webrev-8010309/
>>>             
>>>
>>>             FYI, I removed completely the Map
>>>             levelObjects and used
>>>             two arrays to perform the PlatformLogger's level (int)
>>>             to j.u.l.Level
>>>             mapping:
>>>
>>>             I decided to keep it simple as possible (no enum ...)
>>>             and used a switch
>>>             case based on current level occurences:
>>>
>>>
>>>         Hi Laurent,
>>>
>>>         In my experience enums are just the right and most compact
>>>         tool for coding such constant associations. Here's a quick
>>>         try (ripping off your optimized switch ;-):
>>>
>>>         http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.01/index.html
>>>
>>>         ...it adds 12 LOC to the original PlatformLogger and is 43
>>>         LOC less tha your patch. In addition:
>>>
>>>         - only one switch instead of two (to maintain)
>>>         - no parallel IDX_ constants
>>>
>>>         What do you think?
>>>
>>>         Regards, Peter
>>>
>>>
>>>
>>>               510         /**
>>>               511          * Return the corresponding j.u.l.Level
>>>             instance
>>>               512          * @param level PlatformLogger level as
>>>             integer
>>>               513          * @return Object (j.u.l.Level instance)
>>>             or null if no
>>>             matching level
>>>               514          */
>>>               515         private static Object getLevel(final int
>>>             level) {
>>>               516             if (levelObjects == null) {
>>>               517                 return null;
>>>               518             }
>>>               519             // higher occurences first (finest,
>>>             fine, finer, info)
>>>               520             // based on isLoggable(level) calls
>>>             (03/20/2013)
>>>               521             // in jdk project only (including
>>>             generated sources)
>>>               522             switch (level) {
>>>               523                 case FINEST  : return
>>>             levelObjects[IDX_FINEST];
>>>             // 116 + 2257 matches in generated files
>>>               524                 case FINE    : return
>>>             levelObjects[IDX_FINE];    // 270
>>>               525                 case FINER   : return
>>>             levelObjects[IDX_FINER];   // 157
>>>               526                 case INFO    : return
>>>             levelObjects[IDX_INFO];    // 39
>>>               527                 case WARNING : return
>>>             levelObjects[IDX_WARNING]; // 12
>>>               528                 case CONFIG  : return
>>>             levelObjects[IDX_CONFIG];  // 6
>>>               529                 case SEVERE  : return
>>>             levelObjects[IDX_SEVERE];  // 1
>>>               530                 case OFF     : return
>>>             levelObjects[IDX_OFF];     // 0
>>>               531                 case ALL     : return
>>>             levelObjects[IDX_ALL];     // 0
>>>               532                 default      : return null;
>>>               533             }
>>>               534         }
>>>
>>>             I enhanced the PlatformLoggerTest class also and figured
>>>             out that TLAB
>>>             optimized Integer allocations but I think the patch is
>>>             still useful.
>>>
>>>             Can you have a look to the patch ?
>>>             Should I write a jtreg test  (performance / GC issue) ?
>>>
>>>             Cheers,
>>>             Laurent
>>>
>>>
>>>             2013/3/20 Mandy Chung >>             >
>>>
>>>                   Hi Laurent,
>>>
>>>                 Thank you for signing the OCA.  Your contribution is
>>>                 very welcome.  You
>>>                 can submit a patch for this bug (see [1]) to Core
>>>                 libraries group which
>>>                 owns logging.  Jim Gish and I will sponsor it.
>>>
>>>                 Thanks
>>>                 Mandy
>>>                 [1] http://openjdk.java.net/contribute/
>>>
>>>
>>>                 On 3/20/2013 5:45 AM, Laurent Bourg?s wrote:
>>>
>>>                 Hi mandy,
>>>
>>>                 Do you want me to propose an improved patch to
>>>                 remove the former Map and
>>>                 fix the getLevel() method ? or you prefer fix on
>>>                 your own ?
>>>
>>>                 Is it better to discuss the fix on the bug database
>>>                 (still not visible) ?
>>>
>>>                 Laurent
>>>
>>>                 2013/3/19 Mandy Chung >>                 >
>>>
>>>                     Hi Laurent,
>>>
>>>                     Thanks for the contribution.  I agree that the
>>>                     map can be replaced with a
>>>                     direct mapping from a int value to Level object
>>>                     and avoid the autoboxing
>>>                     conversion.
>>>
>>>                     I have filed a bug to track this and target this
>>>                     for JDK8:
>>>                     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=
>>>                     8010309
>>>
>>>                     Thanks
>>>                     Mandy
>>>
>>>
>>>                     On 3/19/13 5:19 AM, Laurent Bourg?s wrote:
>>>
>>>                     Dear all,
>>>
>>>                     I run recently netbeans profiler on my swing
>>>                     application (Aspro2:http://www.jmmc.fr/aspro
>>>                     ) under linux x64 platform and figured out a
>>>                     performance and waste issue related to
>>>                     PlatformLogger.
>>>
>>>                     Actually, the JavaLogger implementation uses a
>>>                     Map
>>>                     levelObjects to store mapping between
>>>                     PlatformLogger's levels (int) and JUL
>>>                     Level instances.
>>>
>>>                     However, the isLoggable(int level) method is
>>>                     highly used by awt project and
>>>                     other JDK projects and it leads to many Integer
>>>                     allocations as autoboxing
>>>                     converts the level as int to an Integer instance
>>>                     used by the Map.get() call.
>>>
>>>                          /**
>>>                           * JavaLogger forwards all the calls to its
>>>                     corresponding
>>>                           * java.util.logging.Logger object.
>>>                           */
>>>                          static class JavaLogger extends LoggerProxy {
>>>                              private static final* Map>>                     Object>* levelObjects = new
>>>                     HashMap<>();
>>>                     ...
>>>                              public boolean isLoggable(*int level*) {
>>>                                  return
>>>                     LoggingSupport.isLoggable(javaLogger, *
>>>                     levelObjects.get(level)*);
>>>                              }
>>>                          }
>>>
>>>                     I wrote a simple test to illustrate that
>>>                     performance / waste problem:
>>>                     PlatformLoggerTest that simply performs 1
>>>                     million DISABLED log statements:
>>>                                  if
>>>                     (log.isLoggable(PlatformLogger.FINEST)) {
>>>                                      log.finest("test
>>>                     PlatformLogger.FINEST");
>>>                                  }
>>>
>>>                     As you can see in screenshots:
>>>                     - 5 million Integer instances are allocated
>>>                     - Integer.valueOf(int) is called 5 million times
>>>                     (autoboxing)
>>>                     - HashMap.get() represents 30% of the test time
>>>                     - patched PlatformLogger is 3x times faster
>>>                     [jvm options: -Xms8m -Xmx8m -verbose:gc]
>>>
>>>                     I suggest you to use an alternative way to map
>>>                     PlatformLogger's levels
>>>                     (int) and JUL Level instances to fix that
>>>                     performance / memory issue: I
>>>                     added the getLevel(int level) method that
>>>                     performs a switch case to return
>>>                     the corresponding Level object (quick and dirty
>>>                     solution).
>>>
>>>                     I advocate this is not a very clean solution but
>>>                     I prefer efficiency here:
>>>                     any better solution may be appropriate to avoid
>>>                     at least Integer allocation
>>>                     and maybe enhance performance.
>>>
>>>                     Best regards,
>>>                     Laurent Bourg?s
>>>
>>>                     PS: here is the patch as text:
>>>
>>>                     # This patch file was generated by NetBeans IDE
>>>                     # It uses platform neutral UTF-8 encoding and \n
>>>                     newlines.
>>>                     --- PlatformLogger.java (6767)
>>>                     +++ PlatformLogger.java (6768)
>>>                     @@ -468,31 +468,13 @@
>>>                            * java.util.logging.Logger object.
>>>                            */
>>>                           static class JavaLogger extends LoggerProxy {
>>>                     -        /** Note: using Integer keys leads to a
>>>                     lot of new Integer
>>>                     instances !! */
>>>                     -        private static final Map>>                     Object> levelObjects = new
>>>                     HashMap<>();
>>>                     -        /** fastest mapping to Level instances
>>>                     from PlatformLogger level
>>>                     as integer */
>>>                     -        private static final Object[]
>>>                     fastLevelObjects;
>>>                     -
>>>                     -
>>>                     +        private static final Map>>                     Object> levelObjects =
>>>                     +            new HashMap<>();
>>>                     +
>>>                               static {
>>>                                   if (LoggingSupport.isAvailable()) {
>>>                                       // initialize the map to Level
>>>                     objects
>>>                                       getLevelObjects();
>>>                     -
>>>                     -                // initialize the fastLevelObjects:
>>>                     -                fastLevelObjects = new Object[] {
>>>                     -  LoggingSupport.parseLevel(getLevelName(OFF)),
>>>                           //
>>>                     0
>>>                     -
>>>                      LoggingSupport.parseLevel(getLevelName(SEVERE)),  
>>>                      //
>>>                     1
>>>                     -
>>>                      LoggingSupport.parseLevel(getLevelName(WARNING)),
>>>                       //
>>>                     2
>>>                     -
>>>                      LoggingSupport.parseLevel(getLevelName(INFO)),
>>>                          //
>>>                     3
>>>                     -
>>>                      LoggingSupport.parseLevel(getLevelName(CONFIG)),  
>>>                      //
>>>                     4
>>>                     -
>>>                      LoggingSupport.parseLevel(getLevelName(FINE)),
>>>                          //
>>>                     5
>>>                     -
>>>                      LoggingSupport.parseLevel(getLevelName(FINER)),
>>>                         //
>>>                     6
>>>                     -
>>>                      LoggingSupport.parseLevel(getLevelName(FINEST)),  
>>>                      //
>>>                     7
>>>                     -  LoggingSupport.parseLevel(getLevelName(ALL))
>>>                            //
>>>                     8
>>>                     -                };
>>>                     -            } else {
>>>                     -                fastLevelObjects = null; //
>>>                     check null
>>>                                   }
>>>                               }
>>>
>>>                     @@ -515,7 +497,7 @@
>>>                                   this.javaLogger =
>>>                     LoggingSupport.getLogger(name);
>>>                                   if (level != 0) {
>>>                                       // level has been updated and
>>>                     so set the Logger's level
>>>                     -  LoggingSupport.setLevel(javaLogger,
>>>                     getLevel(level));
>>>                     +  LoggingSupport.setLevel(javaLogger,
>>>                     levelObjects.get(level));
>>>                                   }
>>>                               }
>>>
>>>                     @@ -526,11 +508,11 @@
>>>                               * not be updated.
>>>                               */
>>>                               void doLog(int level, String msg) {
>>>                     -  LoggingSupport.log(javaLogger,
>>>                     getLevel(level), msg);
>>>                     +  LoggingSupport.log(javaLogger,
>>>                     levelObjects.get(level), msg);
>>>                               }
>>>
>>>                               void doLog(int level, String msg,
>>>                     Throwable t) {
>>>                     -  LoggingSupport.log(javaLogger,
>>>                     getLevel(level), msg, t);
>>>                     +  LoggingSupport.log(javaLogger,
>>>                     levelObjects.get(level), msg,
>>>                     t);
>>>                               }
>>>
>>>                               void doLog(int level, String msg,
>>>                     Object... params) {
>>>                     @@ -544,12 +526,12 @@
>>>                                   for (int i = 0; i < len; i++) {
>>>                                       sparams [i] =
>>>                     String.valueOf(params[i]);
>>>                                   }
>>>                     -  LoggingSupport.log(javaLogger,
>>>                     getLevel(level), msg, sparams);
>>>                     +  LoggingSupport.log(javaLogger,
>>>                     levelObjects.get(level), msg,
>>>                     sparams);
>>>                               }
>>>
>>>                               boolean isEnabled() {
>>>                                   Object level =
>>>                     LoggingSupport.getLevel(javaLogger);
>>>                     -            return level == null ||
>>>                     level.equals(getLevel(OFF)) == false;
>>>                     +            return level == null ||
>>>                     level.equals(levelObjects.get(OFF)) ==
>>>                     false;
>>>                               }
>>>
>>>                               int getLevel() {
>>>                     @@ -566,34 +548,12 @@
>>>
>>>                               void setLevel(int newLevel) {
>>>                                   levelValue = newLevel;
>>>                     -  LoggingSupport.setLevel(javaLogger,
>>>                     getLevel(newLevel));
>>>                     +  LoggingSupport.setLevel(javaLogger,
>>>                     levelObjects.get(newLevel));
>>>                               }
>>>
>>>                               public boolean isLoggable(int level) {
>>>                     -            return
>>>                     LoggingSupport.isLoggable(javaLogger,
>>>                     getLevel(level));
>>>                     +            return
>>>                     LoggingSupport.isLoggable(javaLogger,
>>>                     levelObjects.get(level));
>>>                               }
>>>                     -
>>>                     -        /**
>>>                     -         * Return the corresponding level
>>>                     object (fastest implementation)
>>>                     -         * @param level PlatformLogger level as
>>>                     primitive integer
>>>                     -         * @return Object (JUL Level instance)
>>>                     -         */
>>>                     -        private static Object getLevel(final
>>>                     int level) {
>>>                     -            // higher occurences first (finest,
>>>                     fine, finer, info):
>>>                     -            switch (level) {
>>>                     -                case FINEST  : return
>>>                     fastLevelObjects[7];
>>>                     -                case FINE    : return
>>>                     fastLevelObjects[5];
>>>                     -                case FINER   : return
>>>                     fastLevelObjects[6];
>>>                     -                case INFO    : return
>>>                     fastLevelObjects[3];
>>>                     -                case CONFIG  : return
>>>                     fastLevelObjects[4];
>>>                     -                case WARNING : return
>>>                     fastLevelObjects[2];
>>>                     -                case SEVERE  : return
>>>                     fastLevelObjects[1];
>>>                     -                case ALL     : return
>>>                     fastLevelObjects[8];
>>>                     -                case OFF     : return
>>>                     fastLevelObjects[0];
>>>                     -                default      : return null;
>>>                     -            }
>>>                     -        }
>>>                     -
>>>                           }
>>>
>>>                           private static String getLevelName(int
>>>                     level) {
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>



From john.zavgren at oracle.com  Thu Mar 21 15:53:43 2013
From: john.zavgren at oracle.com (John Zavgren)
Date: Thu, 21 Mar 2013 08:53:43 -0700 (PDT)
Subject: RFR-8008118
Message-ID: <0a02b31c-3f87-43f8-99b4-318cd57fa717@default>

All: 
I modified the splitPath() procedure so that when it encounters an OOM error it frees allocated memory before exiting. 


Thanks! 
John 


http://cr.openjdk.java.net/~jzavgren/8008118/webrev.03/ 
----- Original Message ----- 
From: martinrb at google.com 
To: chris.hegarty at oracle.com 
Cc: john.zavgren at oracle.com, core-libs-dev at openjdk.java.net 
Sent: Wednesday, March 20, 2013 7:32:39 PM GMT -05:00 US/Canada Eastern 
Subject: Re: RFR-8008118 







On Wed, Mar 20, 2013 at 4:23 PM, Chris Hegarty < chris.hegarty at oracle.com > wrote: 


Martin, 

I take your point about the other allocations, but as you say OOM is better than SEGV. So possibly good enough? 




Ah, Thanks Chris, I had forgotten that NEW *does* throw OOME. 


If NEW returns NULL, then there will be a pending OOM on the stack. 




good point! 
In that case, this is indeed a clear improvement, and I leave it to John whether to undo the allocations in splitPath before returning. 


Just add that space after "if", please, before you submit! 




From bourges.laurent at gmail.com  Thu Mar 21 15:57:33 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Thu, 21 Mar 2013 16:57:33 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due to
	HashMap leads to Integer allocations (boxing)
In-Reply-To: <514B27C5.1020605@gmail.com>
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com>
Message-ID: 

Peter,

I am convinced it is better if the LevelEnum belongs to JavaLogger class
(encapsulated so defered initialization).

Here is a typical scenario:
1 - PlatformLogger initialized (not JUL) => LoggerProxy must work so
LevelEnum can not be used and the former getLevelName() (switch case) is
required.
2 - JUL initialized: calls redirectPlatformLogger() => JavaLoggers created
=> LevelEnum initialized (Level object can be retrieved from LoggingSupport)

For example, JUL can be started programmatically so the loggingEnabled flag
is not enough to initialize the LevelEnum.object at step 1 and it will be
null. Then at step 2, LevelEnum.object are null so the JavaLogger is broken.

Here is a test of this scenario:
public static void main(String[] args) {

    final PlatformLogger log = PlatformLogger.getLogger("sun.awt.X11"); //
1: LoggerProxy

    if (log.isLoggable(PlatformLogger.INFO)) {
        log.info("PlatformLogger.INFO: LoggerProxy");
    }

    final Logger logger = Logger.getLogger("test");
//   calls PlatformLogger.redirectPlatformLoggers(); // 2 : JavaLogger

    if (log.isLoggable(PlatformLogger.INFO)) {
        log.info("PlatformLogger.INFO: JavaLogger");
    }

    logger.info("done");
}

Laurent

2013/3/21 Peter Levart 

>  Hi Laurent, Mandy,
>
> Let me try one more time (it would be less optimal to have 2 switch
> statements instead of one). Here's the 3rd webrev:
>
>
> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.03/index.html
>
> The changes:
> - added the comments
> - made LevelEnum private (to not be tempted to be used from outside the
> PlatformLogger)
> - used the loggingEnabled flag as a pre-check when trying to parse the
> level objects
>
>
> What do you think?
>
> Regards, Peter
>
> On 03/21/2013 04:06 PM, Laurent Bourg?s wrote:
>
> Thanks Mandy for the clarifications !
>
> Peter, I propose to:
> - move the LevelEnum into the JavaLogger class in order to initialize it
> as later as possible i.e. after j.u.l calls redirectPlatformLoggers()
> - only use it in JavaLogger class (private enum) so revert changes to
> PlatformLogger and LoggerProxy classes
> - add few comments in the code to explain lazy initialization (see mandy's
> answer)
>
> Finally, could you keep my comment before the switch case (high occurences
> first) ?
>
> +        static LevelEnum forValue(int levelValue) {
> +            // higher occurences first (finest, fine, finer, info)+            // based on isLoggable(level) calls (03/20/2013) +            // in jdk project only (including generated sources)
> +            switch (levelValue) {+                case PlatformLogger.FINEST:  return FINEST;  // 116 + 2257 matches in generated files+                case PlatformLogger.FINE:    return FINE;    // 270
> +                case PlatformLogger.FINER:   return FINER;   // 157+                case PlatformLogger.INFO:    return INFO;    // 39+                case PlatformLogger.WARNING: return WARNING; // 12
> +                case PlatformLogger.CONFIG:  return CONFIG;  // 6+                case PlatformLogger.SEVERE:  return SEVERE;  // 1+                case PlatformLogger.OFF:     return OFF;     // 0
> +                case PlatformLogger.ALL:     return ALL;     // 0+                default:                     return UNKNOWN;+            }
> +        }
> cheers,
> Laurent
>
>
> 2013/3/21 Mandy Chung 
>
>>  Laurent, Peter,
>>
>> I haven't looked at the patch yet.  One thing worths mentioning is that
>> PlatformLogger was added for the platform code to use so as to avoid the
>> initialization of java.util.logging since logging is not turned on by
>> default and that to reduce the startup overhead.   In addition, it also
>> enables the elimination of the core classes dependency from
>> java.util.logging for modularization effort.  Therefore the PlatformLogger
>> only lazily looks up the Level object when java.util.logging is present and
>> also has been initialized by application code.
>>
>> Mandy
>>
>>
>> On 3/21/2013 7:45 AM, Peter Levart wrote:
>>
>> On 03/21/2013 03:30 PM, Laurent Bourg?s wrote:
>>
>> Peter,
>>
>> your solution looks better; I wanted my patch to be simple, efficient and
>> only modify the JavaLogger class (localized changes).
>>
>> In your patch, I have doubts related to lazy and conditional
>> initialization in JavaLogger (static initialization):
>>
>> if (LoggingSupport.isAvailable()) {
>>     // initialize ...
>> }
>>
>>
>> In original code, if LoggingSupport.isAvailable() returned false, levelObjects
>> map remained empty and consequently null was used as the level object
>> passed to LoggingSupport methods. In LevelEnum I try to keep this logic.
>> When LevelEnum is first used, it's constants are initialized and level
>> objects with them. If
>> LoggingSupport.isAvailable() returns false, level objects are initialized
>> to null.
>>
>> I just noticed there's a bug in initialization of the LevelEnum.UNKNOWN
>> member constant. It should not try to parse level object. Here's an update:
>>
>>
>> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.02/index.html
>>
>> But your concern might be correct. In my code LevelEnum is also used
>> from the LoggerProxy.format() method (in addition to all the places in
>> JavaLogger) to obtain the level name for formatting. If this method is
>> called the first time while LoggingSupport.isAvailable() returns false
>> and that happens before JavaLogger uses LevelEnum for the first time
>> (and at that time LoggingSupport.isAvailable() would return true), then
>> level objects will not be initialized correctly.
>>
>> Lazy initialization of level objects might help (for the price of added
>> complexity)...
>>
>> Regards, Peter
>>
>>  Does somebody have the knowledge about LoggingSupport.isAvailable()
>> and the lazy PlatformLogger initialization (JavaLogger are only used when j.u.l is initialized) ?
>>
>> What's happening if LoggingSupport.isAvailable() returns false in your patch ? - LevelEnum instances are incorrectly initialized: object field is null !
>> - PlatformLogger is then broken ... as Level object are required by j.u.l calls
>> To fix both problems, moving the LevelEnum into JavaLogger should help and check nulls on LevelEnum.object field.
>>
>> Thanks for your feedback,Laurent
>>
>>  2013/3/21 Peter Levart 
>>
>>> On 03/21/2013 12:12 PM, Laurent Bourg?s wrote:
>>>
>>>> Here is an improved patch tested on JDK7u13 and JDK8 internal build on
>>>> my
>>>>  machine linux x64:
>>>> http://jmmc.fr/~bourgesl/share/webrev-8010309/
>>>>
>>>> FYI, I removed completely the Map levelObjects and used
>>>> two arrays to perform the PlatformLogger's level (int) to j.u.l.Level
>>>> mapping:
>>>>
>>>> I decided to keep it simple as possible (no enum ...) and used a switch
>>>> case based on current level occurences:
>>>>
>>>
>>>  Hi Laurent,
>>>
>>> In my experience enums are just the right and most compact tool for
>>> coding such constant associations. Here's a quick try (ripping off your
>>> optimized switch ;-):
>>>
>>>
>>> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.01/index.html
>>>
>>> ...it adds 12 LOC to the original PlatformLogger and is 43 LOC less tha
>>> your patch. In addition:
>>>
>>> - only one switch instead of two (to maintain)
>>> - no parallel IDX_ constants
>>>
>>> What do you think?
>>>
>>> Regards, Peter
>>>
>>>
>>>
>>>>   510         /**
>>>>   511          * Return the corresponding j.u.l.Level instance
>>>>   512          * @param level PlatformLogger level as integer
>>>>   513          * @return Object (j.u.l.Level instance) or null if no
>>>> matching level
>>>>   514          */
>>>>   515         private static Object getLevel(final int level) {
>>>>   516             if (levelObjects == null) {
>>>>   517                 return null;
>>>>   518             }
>>>>   519             // higher occurences first (finest, fine, finer, info)
>>>>   520             // based on isLoggable(level) calls (03/20/2013)
>>>>   521             // in jdk project only (including generated sources)
>>>>   522             switch (level) {
>>>>   523                 case FINEST  : return levelObjects[IDX_FINEST];
>>>> // 116 + 2257 matches in generated files
>>>>   524                 case FINE    : return levelObjects[IDX_FINE];
>>>>  // 270
>>>>   525                 case FINER   : return levelObjects[IDX_FINER];
>>>> // 157
>>>>   526                 case INFO    : return levelObjects[IDX_INFO];
>>>>  // 39
>>>>   527                 case WARNING : return levelObjects[IDX_WARNING];
>>>> // 12
>>>>   528                 case CONFIG  : return levelObjects[IDX_CONFIG];
>>>>  // 6
>>>>   529                 case SEVERE  : return levelObjects[IDX_SEVERE];
>>>>  // 1
>>>>   530                 case OFF     : return levelObjects[IDX_OFF];
>>>> // 0
>>>>   531                 case ALL     : return levelObjects[IDX_ALL];
>>>> // 0
>>>>   532                 default      : return null;
>>>>   533             }
>>>>   534         }
>>>>
>>>> I enhanced the PlatformLoggerTest class also and figured out that TLAB
>>>> optimized Integer allocations but I think the patch is still useful.
>>>>
>>>> Can you have a look to the patch ?
>>>> Should I write a jtreg test  (performance / GC issue) ?
>>>>
>>>> Cheers,
>>>> Laurent
>>>>
>>>>
>>>> 2013/3/20 Mandy Chung 
>>>>
>>>>    Hi Laurent,
>>>>>
>>>>> Thank you for signing the OCA.  Your contribution is very welcome.  You
>>>>> can submit a patch for this bug (see [1]) to Core libraries group which
>>>>> owns logging.  Jim Gish and I will sponsor it.
>>>>>
>>>>> Thanks
>>>>> Mandy
>>>>> [1] http://openjdk.java.net/contribute/
>>>>>
>>>>>
>>>>> On 3/20/2013 5:45 AM, Laurent Bourg?s wrote:
>>>>>
>>>>> Hi mandy,
>>>>>
>>>>> Do you want me to propose an improved patch to remove the former Map
>>>>> and
>>>>> fix the getLevel() method ? or you prefer fix on your own ?
>>>>>
>>>>> Is it better to discuss the fix on the bug database (still not
>>>>> visible) ?
>>>>>
>>>>> Laurent
>>>>>
>>>>> 2013/3/19 Mandy Chung 
>>>>>
>>>>>    Hi Laurent,
>>>>>>
>>>>>> Thanks for the contribution.  I agree that the map can be replaced
>>>>>> with a
>>>>>> direct mapping from a int value to Level object and avoid the
>>>>>> autoboxing
>>>>>> conversion.
>>>>>>
>>>>>> I have filed a bug to track this and target this for JDK8:
>>>>>>    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id= 8010309
>>>>>>
>>>>>> Thanks
>>>>>> Mandy
>>>>>>
>>>>>>
>>>>>> On 3/19/13 5:19 AM, Laurent Bourg?s wrote:
>>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>> I run recently netbeans profiler on my swing application (Aspro2:
>>>>>> http://www.jmmc.fr/aspro
>>>>>> ) under linux x64 platform and figured out a
>>>>>> performance and waste issue related to PlatformLogger.
>>>>>>
>>>>>> Actually, the JavaLogger implementation uses a Map
>>>>>> levelObjects to store mapping between PlatformLogger's levels (int)
>>>>>> and JUL
>>>>>> Level instances.
>>>>>>
>>>>>> However, the isLoggable(int level) method is highly used by awt
>>>>>> project and
>>>>>> other JDK projects and it leads to many Integer allocations as
>>>>>> autoboxing
>>>>>> converts the level as int to an Integer instance used by the
>>>>>> Map.get() call.
>>>>>>
>>>>>>      /**
>>>>>>       * JavaLogger forwards all the calls to its corresponding
>>>>>>       * java.util.logging.Logger object.
>>>>>>       */
>>>>>>      static class JavaLogger extends LoggerProxy {
>>>>>>          private static final* Map* levelObjects =
>>>>>> new
>>>>>> HashMap<>();
>>>>>> ...
>>>>>>          public boolean isLoggable(*int level*) {
>>>>>>              return LoggingSupport.isLoggable(javaLogger, *
>>>>>> levelObjects.get(level)*);
>>>>>>          }
>>>>>>      }
>>>>>>
>>>>>> I wrote a simple test to illustrate that performance / waste problem:
>>>>>> PlatformLoggerTest that simply performs 1 million DISABLED log
>>>>>> statements:
>>>>>>              if (log.isLoggable(PlatformLogger.FINEST)) {
>>>>>>                  log.finest("test PlatformLogger.FINEST");
>>>>>>              }
>>>>>>
>>>>>> As you can see in screenshots:
>>>>>> - 5 million Integer instances are allocated
>>>>>> - Integer.valueOf(int) is called 5 million times (autoboxing)
>>>>>> - HashMap.get() represents 30% of the test time
>>>>>> - patched PlatformLogger is 3x times faster
>>>>>> [jvm options: -Xms8m -Xmx8m -verbose:gc]
>>>>>>
>>>>>> I suggest you to use an alternative way to map PlatformLogger's levels
>>>>>> (int) and JUL Level instances to fix that performance / memory issue:
>>>>>> I
>>>>>> added the getLevel(int level) method that performs a switch case to
>>>>>> return
>>>>>> the corresponding Level object (quick and dirty solution).
>>>>>>
>>>>>> I advocate this is not a very clean solution but I prefer efficiency
>>>>>> here:
>>>>>> any better solution may be appropriate to avoid at least Integer
>>>>>> allocation
>>>>>> and maybe enhance performance.
>>>>>>
>>>>>> Best regards,
>>>>>> Laurent Bourg?s
>>>>>>
>>>>>> PS: here is the patch as text:
>>>>>>
>>>>>> # This patch file was generated by NetBeans IDE
>>>>>> # It uses platform neutral UTF-8 encoding and \n newlines.
>>>>>> --- PlatformLogger.java (6767)
>>>>>> +++ PlatformLogger.java (6768)
>>>>>> @@ -468,31 +468,13 @@
>>>>>>        * java.util.logging.Logger object.
>>>>>>        */
>>>>>>       static class JavaLogger extends LoggerProxy {
>>>>>> -        /** Note: using Integer keys leads to a lot of new Integer
>>>>>> instances !! */
>>>>>> -        private static final Map levelObjects = new
>>>>>> HashMap<>();
>>>>>> -        /** fastest mapping to Level instances from PlatformLogger
>>>>>> level
>>>>>> as integer */
>>>>>> -        private static final Object[] fastLevelObjects;
>>>>>> -
>>>>>> -
>>>>>> +        private static final Map levelObjects =
>>>>>> +            new HashMap<>();
>>>>>> +
>>>>>>           static {
>>>>>>               if (LoggingSupport.isAvailable()) {
>>>>>>                   // initialize the map to Level objects
>>>>>>                   getLevelObjects();
>>>>>> -
>>>>>> -                // initialize the fastLevelObjects:
>>>>>> -                fastLevelObjects = new Object[] {
>>>>>> -                    LoggingSupport.parseLevel(getLevelName(OFF)),
>>>>>>     //
>>>>>> 0
>>>>>> -                    LoggingSupport.parseLevel(getLevelName(SEVERE)),
>>>>>>    //
>>>>>> 1
>>>>>> -
>>>>>>  LoggingSupport.parseLevel(getLevelName(WARNING)),   //
>>>>>> 2
>>>>>> -                    LoggingSupport.parseLevel(getLevelName(INFO)),
>>>>>>    //
>>>>>> 3
>>>>>> -                    LoggingSupport.parseLevel(getLevelName(CONFIG)),
>>>>>>    //
>>>>>> 4
>>>>>> -                    LoggingSupport.parseLevel(getLevelName(FINE)),
>>>>>>    //
>>>>>> 5
>>>>>> -                    LoggingSupport.parseLevel(getLevelName(FINER)),
>>>>>>     //
>>>>>> 6
>>>>>> -                    LoggingSupport.parseLevel(getLevelName(FINEST)),
>>>>>>    //
>>>>>> 7
>>>>>> -                    LoggingSupport.parseLevel(getLevelName(ALL))
>>>>>>    //
>>>>>> 8
>>>>>> -                };
>>>>>> -            } else {
>>>>>> -                fastLevelObjects = null; // check null
>>>>>>               }
>>>>>>           }
>>>>>>
>>>>>> @@ -515,7 +497,7 @@
>>>>>>               this.javaLogger = LoggingSupport.getLogger(name);
>>>>>>               if (level != 0) {
>>>>>>                   // level has been updated and so set the Logger's
>>>>>> level
>>>>>> -                LoggingSupport.setLevel(javaLogger, getLevel(level));
>>>>>> +                LoggingSupport.setLevel(javaLogger,
>>>>>> levelObjects.get(level));
>>>>>>               }
>>>>>>           }
>>>>>>
>>>>>> @@ -526,11 +508,11 @@
>>>>>>           * not be updated.
>>>>>>           */
>>>>>>           void doLog(int level, String msg) {
>>>>>> -            LoggingSupport.log(javaLogger, getLevel(level), msg);
>>>>>> +            LoggingSupport.log(javaLogger, levelObjects.get(level),
>>>>>> msg);
>>>>>>           }
>>>>>>
>>>>>>           void doLog(int level, String msg, Throwable t) {
>>>>>> -            LoggingSupport.log(javaLogger, getLevel(level), msg, t);
>>>>>> +            LoggingSupport.log(javaLogger, levelObjects.get(level),
>>>>>> msg,
>>>>>> t);
>>>>>>           }
>>>>>>
>>>>>>           void doLog(int level, String msg, Object... params) {
>>>>>> @@ -544,12 +526,12 @@
>>>>>>               for (int i = 0; i < len; i++) {
>>>>>>                   sparams [i] = String.valueOf(params[i]);
>>>>>>               }
>>>>>> -            LoggingSupport.log(javaLogger, getLevel(level), msg,
>>>>>> sparams);
>>>>>> +            LoggingSupport.log(javaLogger, levelObjects.get(level),
>>>>>> msg,
>>>>>> sparams);
>>>>>>           }
>>>>>>
>>>>>>           boolean isEnabled() {
>>>>>>               Object level = LoggingSupport.getLevel(javaLogger);
>>>>>> -            return level == null || level.equals(getLevel(OFF)) ==
>>>>>> false;
>>>>>> +            return level == null ||
>>>>>> level.equals(levelObjects.get(OFF)) ==
>>>>>> false;
>>>>>>           }
>>>>>>
>>>>>>           int getLevel() {
>>>>>> @@ -566,34 +548,12 @@
>>>>>>
>>>>>>           void setLevel(int newLevel) {
>>>>>>               levelValue = newLevel;
>>>>>> -            LoggingSupport.setLevel(javaLogger, getLevel(newLevel));
>>>>>> +            LoggingSupport.setLevel(javaLogger,
>>>>>> levelObjects.get(newLevel));
>>>>>>           }
>>>>>>
>>>>>>           public boolean isLoggable(int level) {
>>>>>> -            return LoggingSupport.isLoggable(javaLogger,
>>>>>> getLevel(level));
>>>>>> +            return LoggingSupport.isLoggable(javaLogger,
>>>>>> levelObjects.get(level));
>>>>>>           }
>>>>>> -
>>>>>> -        /**
>>>>>> -         * Return the corresponding level object (fastest
>>>>>> implementation)
>>>>>> -         * @param level PlatformLogger level as primitive integer
>>>>>> -         * @return Object (JUL Level instance)
>>>>>> -         */
>>>>>> -        private static Object getLevel(final int level) {
>>>>>> -            // higher occurences first (finest, fine, finer, info):
>>>>>> -            switch (level) {
>>>>>> -                case FINEST  : return fastLevelObjects[7];
>>>>>> -                case FINE    : return fastLevelObjects[5];
>>>>>> -                case FINER   : return fastLevelObjects[6];
>>>>>> -                case INFO    : return fastLevelObjects[3];
>>>>>> -                case CONFIG  : return fastLevelObjects[4];
>>>>>> -                case WARNING : return fastLevelObjects[2];
>>>>>> -                case SEVERE  : return fastLevelObjects[1];
>>>>>> -                case ALL     : return fastLevelObjects[8];
>>>>>> -                case OFF     : return fastLevelObjects[0];
>>>>>> -                default      : return null;
>>>>>> -            }
>>>>>> -        }
>>>>>> -
>>>>>>       }
>>>>>>
>>>>>>       private static String getLevelName(int level) {
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>
>>
>>
>
>


From peter.levart at gmail.com  Thu Mar 21 16:00:13 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 21 Mar 2013 17:00:13 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due
	to HashMap leads to Integer allocations (boxing)
In-Reply-To: <514B27C5.1020605@gmail.com>
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com>
Message-ID: <514B2E8D.8060701@gmail.com>

On 03/21/2013 04:31 PM, Peter Levart wrote:
> Hi Laurent, Mandy,
>
> Let me try one more time (it would be less optimal to have 2 switch 
> statements instead of one). Here's the 3rd webrev:
>
> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.03/index.html
>
> The changes:
> - added the comments
> - made LevelEnum private (to not be tempted to be used from outside 
> the PlatformLogger)

Hi Mandy,

JavaLogger and LoggerProxy are only used from within PlatformLogger. 
Wouldn't it be better to declare them private? Their usage (one or the 
other) depends on the 'loggingSupport' flag that is initialized with 
PlatformLogger class. Usage of JavaLogger or LoggerProxy outside 
PlatformLogger would be wrong, I think.

> - used the loggingEnabled flag as a pre-check when trying to parse the 
> level objects

I think this pre-check is optimal and does not even try to load the 
LoggingSupport class unless loggingEnabled is true. I tried the 
following test:

public class TestLazyClassInit {

     private static final boolean FALSE = 
Boolean.getBoolean("non.existent.property");

     static class Foo {
         static {
             System.out.println("Foo initialized");
         }

         static boolean isOk() {
             return true;
         }
     }

     public static void main(String[] args) {
         if (FALSE && Foo.isOk()) {
             System.out.println("FALSE is true");
         } else {
             System.out.println("FALSE is false");
         }
     }
}


... and it only prints: "FALSE is false"...




Regards, Peter


>
> What do you think?
>
> Regards, Peter
>
> On 03/21/2013 04:06 PM, Laurent Bourg?s wrote:
>> Thanks Mandy for the clarifications !
>>
>> Peter, I propose to:
>> - move the LevelEnum into the JavaLogger class in order to initialize 
>> it as later as possible i.e. after j.u.l calls redirectPlatformLoggers()
>> - only use it in JavaLogger class (private enum) so revert changes to 
>> PlatformLogger and LoggerProxy classes
>> - add few comments in the code to explain lazy initialization (see 
>> mandy's answer)
>>
>> Finally, could you keep my comment before the switch case (high 
>> occurences first) ?
>> +        static LevelEnum forValue(int levelValue) {
>>
>> +            // higher occurences first (finest, fine, finer, info)
>> +            // based on isLoggable(level) calls (03/20/2013)
>> +            // in jdk project only (including generated sources)
>>
>> +            switch (levelValue) {
>> +                case PlatformLogger.FINEST:  return FINEST;  // 116 + 2257 matches in generated files
>> +                case PlatformLogger.FINE:    return FINE;    // 270
>>
>> +                case PlatformLogger.FINER:   return FINER;   // 157
>> +                case PlatformLogger.INFO:    return INFO;    // 39
>> +                case PlatformLogger.WARNING: return WARNING; // 12
>>
>> +                case PlatformLogger.CONFIG:  return CONFIG;  // 6
>> +                case PlatformLogger.SEVERE:  return SEVERE;  // 1
>> +                case PlatformLogger.OFF:     return OFF;     // 0
>>
>> +                case PlatformLogger.ALL:     return ALL;     // 0
>> +                default:                     return UNKNOWN;
>> +            }
>>
>> +        }
>>
>> cheers,
>> Laurent
>>
>> 2013/3/21 Mandy Chung > >
>>
>>     Laurent, Peter,
>>
>>     I haven't looked at the patch yet.  One thing worths mentioning
>>     is that PlatformLogger was added for the platform code to use so
>>     as to avoid the initialization of java.util.logging since logging
>>     is not turned on by default and that to reduce the startup
>>     overhead.   In addition, it also enables the elimination of the
>>     core classes dependency from java.util.logging for modularization
>>     effort.  Therefore the PlatformLogger only lazily looks up the
>>     Level object when java.util.logging is present and also has been
>>     initialized by application code.
>>
>>     Mandy
>>
>>
>>     On 3/21/2013 7:45 AM, Peter Levart wrote:
>>>     On 03/21/2013 03:30 PM, Laurent Bourg?s wrote:
>>>>     Peter,
>>>>
>>>>     your solution looks better; I wanted my patch to be simple,
>>>>     efficient and only modify the JavaLogger class (localized changes).
>>>>
>>>>     In your patch, I have doubts related to lazy and conditional
>>>>     initialization in JavaLogger (static initialization):
>>>>     if (LoggingSupport.isAvailable()) {
>>>>          // initialize ...
>>>>     }
>>>
>>>     In original code, if LoggingSupport.isAvailable() returned
>>>     false, levelObjects map remained empty and consequently null was
>>>     used as the level object passed to LoggingSupport methods. In
>>>     LevelEnum I try to keep this logic. When LevelEnum is first
>>>     used, it's constants are initialized and level objects with
>>>     them. If
>>>     LoggingSupport.isAvailable() returns false, level objects are
>>>     initialized to null.
>>>
>>>     I just noticed there's a bug in initialization of the
>>>     LevelEnum.UNKNOWN member constant. It should not try to parse
>>>     level object. Here's an update:
>>>
>>>     http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.02/index.html
>>>
>>>     But your concern might be correct. In my code LevelEnum is also
>>>     used from the LoggerProxy.format() method (in addition to all
>>>     the places in JavaLogger) to obtain the level name for
>>>     formatting. If this method is called the first time while
>>>     LoggingSupport.isAvailable() returns false and that happens
>>>     before JavaLogger uses LevelEnum for the first time (and at that
>>>     time LoggingSupport.isAvailable() would return true), then level
>>>     objects will not be initialized correctly.
>>>
>>>     Lazy initialization of level objects might help (for the price
>>>     of added complexity)...
>>>
>>>     Regards, Peter
>>>
>>>>     Does somebody have the knowledge about LoggingSupport.isAvailable()
>>>>
>>>>     and the lazy PlatformLogger initialization (JavaLogger are only used when j.u.l is initialized) ?
>>>>
>>>>
>>>>     What's happening if LoggingSupport.isAvailable() returns false in your patch ?
>>>>     - LevelEnum  instances are incorrectly initialized:object field is null !
>>>>
>>>>     - PlatformLogger is then broken ... as Level object are required by j.u.l calls
>>>>
>>>>
>>>>     To fix both problems, moving theLevelEnum  into JavaLogger should help and check nulls onLevelEnum.object field.
>>>>
>>>>
>>>>     Thanks for your feedback,
>>>>     Laurent
>>>>
>>>>
>>>>     2013/3/21 Peter Levart >>>     >
>>>>
>>>>         On 03/21/2013 12:12 PM, Laurent Bourg?s wrote:
>>>>
>>>>             Here is an improved patch tested on JDK7u13 and JDK8
>>>>             internal build on my
>>>>             machine linux x64:
>>>>             http://jmmc.fr/~bourgesl/share/webrev-8010309/
>>>>             
>>>>
>>>>             FYI, I removed completely the Map
>>>>             levelObjects and used
>>>>             two arrays to perform the PlatformLogger's level (int)
>>>>             to j.u.l.Level
>>>>             mapping:
>>>>
>>>>             I decided to keep it simple as possible (no enum ...)
>>>>             and used a switch
>>>>             case based on current level occurences:
>>>>
>>>>
>>>>         Hi Laurent,
>>>>
>>>>         In my experience enums are just the right and most compact
>>>>         tool for coding such constant associations. Here's a quick
>>>>         try (ripping off your optimized switch ;-):
>>>>
>>>>         http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.01/index.html
>>>>
>>>>         ...it adds 12 LOC to the original PlatformLogger and is 43
>>>>         LOC less tha your patch. In addition:
>>>>
>>>>         - only one switch instead of two (to maintain)
>>>>         - no parallel IDX_ constants
>>>>
>>>>         What do you think?
>>>>
>>>>         Regards, Peter
>>>>
>>>>
>>>>
>>>>               510         /**
>>>>               511          * Return the corresponding j.u.l.Level
>>>>             instance
>>>>               512          * @param level PlatformLogger level as
>>>>             integer
>>>>               513          * @return Object (j.u.l.Level instance)
>>>>             or null if no
>>>>             matching level
>>>>               514          */
>>>>               515         private static Object getLevel(final int
>>>>             level) {
>>>>               516             if (levelObjects == null) {
>>>>               517                 return null;
>>>>               518             }
>>>>               519             // higher occurences first (finest,
>>>>             fine, finer, info)
>>>>               520             // based on isLoggable(level) calls
>>>>             (03/20/2013)
>>>>               521             // in jdk project only (including
>>>>             generated sources)
>>>>               522             switch (level) {
>>>>               523                 case FINEST  : return
>>>>             levelObjects[IDX_FINEST];
>>>>             // 116 + 2257 matches in generated files
>>>>               524                 case FINE    : return
>>>>             levelObjects[IDX_FINE];    // 270
>>>>               525                 case FINER   : return
>>>>             levelObjects[IDX_FINER];   // 157
>>>>               526                 case INFO    : return
>>>>             levelObjects[IDX_INFO];    // 39
>>>>               527                 case WARNING : return
>>>>             levelObjects[IDX_WARNING]; // 12
>>>>               528                 case CONFIG  : return
>>>>             levelObjects[IDX_CONFIG];  // 6
>>>>               529                 case SEVERE  : return
>>>>             levelObjects[IDX_SEVERE];  // 1
>>>>               530                 case OFF     : return
>>>>             levelObjects[IDX_OFF];     // 0
>>>>               531                 case ALL     : return
>>>>             levelObjects[IDX_ALL];     // 0
>>>>               532                 default      : return null;
>>>>               533             }
>>>>               534         }
>>>>
>>>>             I enhanced the PlatformLoggerTest class also and
>>>>             figured out that TLAB
>>>>             optimized Integer allocations but I think the patch is
>>>>             still useful.
>>>>
>>>>             Can you have a look to the patch ?
>>>>             Should I write a jtreg test  (performance / GC issue) ?
>>>>
>>>>             Cheers,
>>>>             Laurent
>>>>
>>>>
>>>>             2013/3/20 Mandy Chung >>>             >
>>>>
>>>>                 Hi Laurent,
>>>>
>>>>                 Thank you for signing the OCA.  Your contribution
>>>>                 is very welcome.  You
>>>>                 can submit a patch for this bug (see [1]) to Core
>>>>                 libraries group which
>>>>                 owns logging.  Jim Gish and I will sponsor it.
>>>>
>>>>                 Thanks
>>>>                 Mandy
>>>>                 [1] http://openjdk.java.net/contribute/
>>>>
>>>>
>>>>                 On 3/20/2013 5:45 AM, Laurent Bourg?s wrote:
>>>>
>>>>                 Hi mandy,
>>>>
>>>>                 Do you want me to propose an improved patch to
>>>>                 remove the former Map and
>>>>                 fix the getLevel() method ? or you prefer fix on
>>>>                 your own ?
>>>>
>>>>                 Is it better to discuss the fix on the bug database
>>>>                 (still not visible) ?
>>>>
>>>>                 Laurent
>>>>
>>>>                 2013/3/19 Mandy Chung >>>                 >
>>>>
>>>>                       Hi Laurent,
>>>>
>>>>                     Thanks for the contribution.  I agree that the
>>>>                     map can be replaced with a
>>>>                     direct mapping from a int value to Level object
>>>>                     and avoid the autoboxing
>>>>                     conversion.
>>>>
>>>>                     I have filed a bug to track this and target
>>>>                     this for JDK8:
>>>>                     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=
>>>>                     8010309
>>>>
>>>>                     Thanks
>>>>                     Mandy
>>>>
>>>>
>>>>                     On 3/19/13 5:19 AM, Laurent Bourg?s wrote:
>>>>
>>>>                     Dear all,
>>>>
>>>>                     I run recently netbeans profiler on my swing
>>>>                     application (Aspro2:http://www.jmmc.fr/aspro
>>>>                     ) under linux x64 platform and figured out a
>>>>                     performance and waste issue related to
>>>>                     PlatformLogger.
>>>>
>>>>                     Actually, the JavaLogger implementation uses a
>>>>                     Map
>>>>                     levelObjects to store mapping between
>>>>                     PlatformLogger's levels (int) and JUL
>>>>                     Level instances.
>>>>
>>>>                     However, the isLoggable(int level) method is
>>>>                     highly used by awt project and
>>>>                     other JDK projects and it leads to many Integer
>>>>                     allocations as autoboxing
>>>>                     converts the level as int to an Integer
>>>>                     instance used by the Map.get() call.
>>>>
>>>>                          /**
>>>>                           * JavaLogger forwards all the calls to
>>>>                     its corresponding
>>>>                           * java.util.logging.Logger object.
>>>>                           */
>>>>                          static class JavaLogger extends LoggerProxy {
>>>>                              private static final* Map>>>                     Object>* levelObjects = new
>>>>                     HashMap<>();
>>>>                     ...
>>>>                              public boolean isLoggable(*int level*) {
>>>>                                  return
>>>>                     LoggingSupport.isLoggable(javaLogger, *
>>>>                     levelObjects.get(level)*);
>>>>                              }
>>>>                          }
>>>>
>>>>                     I wrote a simple test to illustrate that
>>>>                     performance / waste problem:
>>>>                     PlatformLoggerTest that simply performs 1
>>>>                     million DISABLED log statements:
>>>>                                  if
>>>>                     (log.isLoggable(PlatformLogger.FINEST)) {
>>>>                                      log.finest("test
>>>>                     PlatformLogger.FINEST");
>>>>                                  }
>>>>
>>>>                     As you can see in screenshots:
>>>>                     - 5 million Integer instances are allocated
>>>>                     - Integer.valueOf(int) is called 5 million
>>>>                     times (autoboxing)
>>>>                     - HashMap.get() represents 30% of the test time
>>>>                     - patched PlatformLogger is 3x times faster
>>>>                     [jvm options: -Xms8m -Xmx8m -verbose:gc]
>>>>
>>>>                     I suggest you to use an alternative way to map
>>>>                     PlatformLogger's levels
>>>>                     (int) and JUL Level instances to fix that
>>>>                     performance / memory issue: I
>>>>                     added the getLevel(int level) method that
>>>>                     performs a switch case to return
>>>>                     the corresponding Level object (quick and dirty
>>>>                     solution).
>>>>
>>>>                     I advocate this is not a very clean solution
>>>>                     but I prefer efficiency here:
>>>>                     any better solution may be appropriate to avoid
>>>>                     at least Integer allocation
>>>>                     and maybe enhance performance.
>>>>
>>>>                     Best regards,
>>>>                     Laurent Bourg?s
>>>>
>>>>                     PS: here is the patch as text:
>>>>
>>>>                     # This patch file was generated by NetBeans IDE
>>>>                     # It uses platform neutral UTF-8 encoding and
>>>>                     \n newlines.
>>>>                     --- PlatformLogger.java (6767)
>>>>                     +++ PlatformLogger.java (6768)
>>>>                     @@ -468,31 +468,13 @@
>>>>                            * java.util.logging.Logger object.
>>>>                            */
>>>>                           static class JavaLogger extends LoggerProxy {
>>>>                     -        /** Note: using Integer keys leads to
>>>>                     a lot of new Integer
>>>>                     instances !! */
>>>>                     -        private static final Map>>>                     Object> levelObjects = new
>>>>                     HashMap<>();
>>>>                     -        /** fastest mapping to Level instances
>>>>                     from PlatformLogger level
>>>>                     as integer */
>>>>                     -        private static final Object[]
>>>>                     fastLevelObjects;
>>>>                     -
>>>>                     -
>>>>                     +        private static final Map>>>                     Object> levelObjects =
>>>>                     +            new HashMap<>();
>>>>                     +
>>>>                               static {
>>>>                                   if (LoggingSupport.isAvailable()) {
>>>>                                       // initialize the map to
>>>>                     Level objects
>>>>                                       getLevelObjects();
>>>>                     -
>>>>                     -                // initialize the
>>>>                     fastLevelObjects:
>>>>                     -                fastLevelObjects = new Object[] {
>>>>                     -
>>>>                      LoggingSupport.parseLevel(getLevelName(OFF)),
>>>>                           //
>>>>                     0
>>>>                     -
>>>>                      LoggingSupport.parseLevel(getLevelName(SEVERE)),
>>>>                        //
>>>>                     1
>>>>                     -
>>>>                      LoggingSupport.parseLevel(getLevelName(WARNING)),
>>>>                       //
>>>>                     2
>>>>                     -
>>>>                      LoggingSupport.parseLevel(getLevelName(INFO)),
>>>>                          //
>>>>                     3
>>>>                     -
>>>>                      LoggingSupport.parseLevel(getLevelName(CONFIG)),
>>>>                        //
>>>>                     4
>>>>                     -
>>>>                      LoggingSupport.parseLevel(getLevelName(FINE)),
>>>>                          //
>>>>                     5
>>>>                     -
>>>>                      LoggingSupport.parseLevel(getLevelName(FINER)),  
>>>>                       //
>>>>                     6
>>>>                     -
>>>>                      LoggingSupport.parseLevel(getLevelName(FINEST)),
>>>>                        //
>>>>                     7
>>>>                     -  LoggingSupport.parseLevel(getLevelName(ALL))
>>>>                            //
>>>>                     8
>>>>                     -                };
>>>>                     -            } else {
>>>>                     -                fastLevelObjects = null; //
>>>>                     check null
>>>>                                   }
>>>>                               }
>>>>
>>>>                     @@ -515,7 +497,7 @@
>>>>                                   this.javaLogger =
>>>>                     LoggingSupport.getLogger(name);
>>>>                                   if (level != 0) {
>>>>                                       // level has been updated and
>>>>                     so set the Logger's level
>>>>                     -  LoggingSupport.setLevel(javaLogger,
>>>>                     getLevel(level));
>>>>                     +  LoggingSupport.setLevel(javaLogger,
>>>>                     levelObjects.get(level));
>>>>                                   }
>>>>                               }
>>>>
>>>>                     @@ -526,11 +508,11 @@
>>>>                               * not be updated.
>>>>                               */
>>>>                               void doLog(int level, String msg) {
>>>>                     -  LoggingSupport.log(javaLogger,
>>>>                     getLevel(level), msg);
>>>>                     +  LoggingSupport.log(javaLogger,
>>>>                     levelObjects.get(level), msg);
>>>>                               }
>>>>
>>>>                               void doLog(int level, String msg,
>>>>                     Throwable t) {
>>>>                     -  LoggingSupport.log(javaLogger,
>>>>                     getLevel(level), msg, t);
>>>>                     +  LoggingSupport.log(javaLogger,
>>>>                     levelObjects.get(level), msg,
>>>>                     t);
>>>>                               }
>>>>
>>>>                               void doLog(int level, String msg,
>>>>                     Object... params) {
>>>>                     @@ -544,12 +526,12 @@
>>>>                                   for (int i = 0; i < len; i++) {
>>>>                                       sparams [i] =
>>>>                     String.valueOf(params[i]);
>>>>                                   }
>>>>                     -  LoggingSupport.log(javaLogger,
>>>>                     getLevel(level), msg, sparams);
>>>>                     +  LoggingSupport.log(javaLogger,
>>>>                     levelObjects.get(level), msg,
>>>>                     sparams);
>>>>                               }
>>>>
>>>>                               boolean isEnabled() {
>>>>                                   Object level =
>>>>                     LoggingSupport.getLevel(javaLogger);
>>>>                     -            return level == null ||
>>>>                     level.equals(getLevel(OFF)) == false;
>>>>                     +            return level == null ||
>>>>                     level.equals(levelObjects.get(OFF)) ==
>>>>                     false;
>>>>                               }
>>>>
>>>>                               int getLevel() {
>>>>                     @@ -566,34 +548,12 @@
>>>>
>>>>                               void setLevel(int newLevel) {
>>>>                                   levelValue = newLevel;
>>>>                     -  LoggingSupport.setLevel(javaLogger,
>>>>                     getLevel(newLevel));
>>>>                     +  LoggingSupport.setLevel(javaLogger,
>>>>                     levelObjects.get(newLevel));
>>>>                               }
>>>>
>>>>                               public boolean isLoggable(int level) {
>>>>                     -            return
>>>>                     LoggingSupport.isLoggable(javaLogger,
>>>>                     getLevel(level));
>>>>                     +            return
>>>>                     LoggingSupport.isLoggable(javaLogger,
>>>>                     levelObjects.get(level));
>>>>                               }
>>>>                     -
>>>>                     -        /**
>>>>                     -         * Return the corresponding level
>>>>                     object (fastest implementation)
>>>>                     -         * @param level PlatformLogger level
>>>>                     as primitive integer
>>>>                     -         * @return Object (JUL Level instance)
>>>>                     -         */
>>>>                     -        private static Object getLevel(final
>>>>                     int level) {
>>>>                     -            // higher occurences first
>>>>                     (finest, fine, finer, info):
>>>>                     -            switch (level) {
>>>>                     -                case FINEST  : return
>>>>                     fastLevelObjects[7];
>>>>                     -                case FINE    : return
>>>>                     fastLevelObjects[5];
>>>>                     -                case FINER   : return
>>>>                     fastLevelObjects[6];
>>>>                     -                case INFO    : return
>>>>                     fastLevelObjects[3];
>>>>                     -                case CONFIG  : return
>>>>                     fastLevelObjects[4];
>>>>                     -                case WARNING : return
>>>>                     fastLevelObjects[2];
>>>>                     -                case SEVERE  : return
>>>>                     fastLevelObjects[1];
>>>>                     -                case ALL     : return
>>>>                     fastLevelObjects[8];
>>>>                     -                case OFF     : return
>>>>                     fastLevelObjects[0];
>>>>                     -                default      : return null;
>>>>                     -            }
>>>>                     -        }
>>>>                     -
>>>>                           }
>>>>
>>>>                           private static String getLevelName(int
>>>>                     level) {
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>



From peter.levart at gmail.com  Thu Mar 21 16:09:21 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 21 Mar 2013 17:09:21 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due
	to HashMap leads to Integer allocations (boxing)
In-Reply-To: 
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com>
	
Message-ID: <514B30B1.2010005@gmail.com>

You're right, loggingEnabled can change afterwards. I'll correct the 
code as suggested...

Peter

On 03/21/2013 04:57 PM, Laurent Bourg?s wrote:
> Peter,
>
> I am convinced it is better if the LevelEnum belongs to JavaLogger 
> class (encapsulated so defered initialization).
>
> Here is a typical scenario:
> 1 - PlatformLogger initialized (not JUL) => LoggerProxy must work so 
> LevelEnum can not be used and the formergetLevelName() (switch case) 
> is required.
> 2 - JUL initialized: calls redirectPlatformLogger() => JavaLoggers 
> created => LevelEnum initialized (Level object can be retrieved from 
> LoggingSupport)
>
> For example, JUL can be started programmatically so the loggingEnabled 
> flag is not enough to initialize the LevelEnum.object at step 1 and it 
> will be null. Then at step 2, LevelEnum.object are null so the 
> JavaLogger is broken.
>
> Here is a test of this scenario:
> public static void main(String[] args) {
>
>     final PlatformLogger log = 
> PlatformLogger.getLogger("sun.awt.X11"); // 1: LoggerProxy
>
>     if (log.isLoggable(PlatformLogger.INFO)) {
> log.info ("PlatformLogger.INFO: LoggerProxy");
>     }
>
>     final Logger logger = Logger.getLogger("test");
> //   calls PlatformLogger.redirectPlatformLoggers(); // 2 : JavaLogger
>
>     if (log.isLoggable(PlatformLogger.INFO)) {
> log.info ("PlatformLogger.INFO: JavaLogger");
>     }
>
> logger.info ("done");
> }
>
> Laurent
>
> 2013/3/21 Peter Levart  >
>
>     Hi Laurent, Mandy,
>
>     Let me try one more time (it would be less optimal to have 2
>     switch statements instead of one). Here's the 3rd webrev:
>
>     http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.03/index.html
>
>     The changes:
>     - added the comments
>     - made LevelEnum private (to not be tempted to be used from
>     outside the PlatformLogger)
>     - used the loggingEnabled flag as a pre-check when trying to parse
>     the level objects
>
>
>     What do you think?
>
>     Regards, Peter
>
>     On 03/21/2013 04:06 PM, Laurent Bourg?s wrote:
>>     Thanks Mandy for the clarifications !
>>
>>     Peter, I propose to:
>>     - move the LevelEnum into the JavaLogger class in order to
>>     initialize it as later as possible i.e. after j.u.l calls
>>     redirectPlatformLoggers()
>>     - only use it in JavaLogger class (private enum) so revert
>>     changes to PlatformLogger and LoggerProxy classes
>>     - add few comments in the code to explain lazy initialization
>>     (see mandy's answer)
>>
>>     Finally, could you keep my comment before the switch case (high
>>     occurences first) ?
>>     +        static LevelEnum forValue(int levelValue) {
>>
>>     +            // higher occurences first (finest, fine, finer, info)
>>     +            // based on isLoggable(level) calls (03/20/2013)
>>     +            // in jdk project only (including generated sources)
>>
>>     +            switch (levelValue) {
>>     +                case PlatformLogger.FINEST:  return FINEST;  // 116 + 2257 matches in generated files
>>     +                case PlatformLogger.FINE:    return FINE;    // 270
>>
>>     +                case PlatformLogger.FINER:   return FINER;   // 157
>>     +                case PlatformLogger.INFO:    return INFO;    // 39
>>     +                case PlatformLogger.WARNING: return WARNING; // 12
>>
>>     +                case PlatformLogger.CONFIG:  return CONFIG;  // 6
>>     +                case PlatformLogger.SEVERE:  return SEVERE;  // 1
>>     +                case PlatformLogger.OFF:     return OFF;     // 0
>>
>>     +                case PlatformLogger.ALL:     return ALL;     // 0
>>     +                default:                     return UNKNOWN;
>>     +            }
>>
>>     +        }
>>
>>     cheers,
>>     Laurent
>>
>>     2013/3/21 Mandy Chung >     >
>>
>>         Laurent, Peter,
>>
>>         I haven't looked at the patch yet.  One thing worths
>>         mentioning is that PlatformLogger was added for the platform
>>         code to use so as to avoid the initialization of
>>         java.util.logging since logging is not turned on by default
>>         and that to reduce the startup overhead.   In addition, it
>>         also enables the elimination of the core classes dependency
>>         from java.util.logging for modularization effort.  Therefore
>>         the PlatformLogger only lazily looks up the Level object when
>>         java.util.logging is present and also has been initialized by
>>         application code.
>>
>>         Mandy
>>
>>
>>         On 3/21/2013 7:45 AM, Peter Levart wrote:
>>>         On 03/21/2013 03:30 PM, Laurent Bourg?s wrote:
>>>>         Peter,
>>>>
>>>>         your solution looks better; I wanted my patch to be simple,
>>>>         efficient and only modify the JavaLogger class (localized
>>>>         changes).
>>>>
>>>>         In your patch, I have doubts related to lazy and
>>>>         conditional initialization in JavaLogger (static
>>>>         initialization):
>>>>         if (LoggingSupport.isAvailable()) {
>>>>              // initialize ...
>>>>         }
>>>
>>>         In original code, if LoggingSupport.isAvailable() returned
>>>         false, levelObjects map remained empty and consequently null
>>>         was used as the level object passed to LoggingSupport
>>>         methods. In LevelEnum I try to keep this logic. When
>>>         LevelEnum is first used, it's constants are initialized and
>>>         level objects with them. If
>>>         LoggingSupport.isAvailable() returns false, level objects
>>>         are initialized to null.
>>>
>>>         I just noticed there's a bug in initialization of the
>>>         LevelEnum.UNKNOWN member constant. It should not try to
>>>         parse level object. Here's an update:
>>>
>>>         http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.02/index.html
>>>
>>>         But your concern might be correct. In my code LevelEnum is
>>>         also used from the LoggerProxy.format() method (in addition
>>>         to all the places in JavaLogger) to obtain the level name
>>>         for formatting. If this method is called the first time
>>>         while LoggingSupport.isAvailable() returns false and that
>>>         happens before JavaLogger uses LevelEnum for the first time
>>>         (and at that time LoggingSupport.isAvailable() would return
>>>         true), then level objects will not be initialized correctly.
>>>
>>>         Lazy initialization of level objects might help (for the
>>>         price of added complexity)...
>>>
>>>         Regards, Peter
>>>
>>>>         Does somebody have the knowledge about LoggingSupport.isAvailable()
>>>>
>>>>         and the lazy PlatformLogger initialization (JavaLogger are only used when j.u.l is initialized) ?
>>>>
>>>>
>>>>         What's happening if LoggingSupport.isAvailable() returns false in your patch ?
>>>>         - LevelEnum  instances are incorrectly initialized:object field is null !
>>>>
>>>>         - PlatformLogger is then broken ... as Level object are required by j.u.l calls
>>>>
>>>>
>>>>         To fix both problems, moving theLevelEnum  into JavaLogger should help and check nulls onLevelEnum.object field.
>>>>
>>>>
>>>>         Thanks for your feedback,
>>>>         Laurent
>>>>
>>>>
>>>>         2013/3/21 Peter Levart >>>         >
>>>>
>>>>             On 03/21/2013 12:12 PM, Laurent Bourg?s wrote:
>>>>
>>>>                 Here is an improved patch tested on JDK7u13 and
>>>>                 JDK8 internal build on my
>>>>                 machine linux x64:
>>>>                 http://jmmc.fr/~bourgesl/share/webrev-8010309/
>>>>                 
>>>>
>>>>                 FYI, I removed completely the Map
>>>>                 levelObjects and used
>>>>                 two arrays to perform the PlatformLogger's level
>>>>                 (int) to j.u.l.Level
>>>>                 mapping:
>>>>
>>>>                 I decided to keep it simple as possible (no enum
>>>>                 ...) and used a switch
>>>>                 case based on current level occurences:
>>>>
>>>>
>>>>             Hi Laurent,
>>>>
>>>>             In my experience enums are just the right and most
>>>>             compact tool for coding such constant associations.
>>>>             Here's a quick try (ripping off your optimized switch ;-):
>>>>
>>>>             http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.01/index.html
>>>>
>>>>             ...it adds 12 LOC to the original PlatformLogger and is
>>>>             43 LOC less tha your patch. In addition:
>>>>
>>>>             - only one switch instead of two (to maintain)
>>>>             - no parallel IDX_ constants
>>>>
>>>>             What do you think?
>>>>
>>>>             Regards, Peter
>>>>
>>>>
>>>>
>>>>                   510         /**
>>>>                   511          * Return the corresponding
>>>>                 j.u.l.Level instance
>>>>                   512          * @param level PlatformLogger level
>>>>                 as integer
>>>>                   513          * @return Object (j.u.l.Level
>>>>                 instance) or null if no
>>>>                 matching level
>>>>                   514          */
>>>>                   515         private static Object getLevel(final
>>>>                 int level) {
>>>>                   516             if (levelObjects == null) {
>>>>                   517                 return null;
>>>>                   518             }
>>>>                   519             // higher occurences first
>>>>                 (finest, fine, finer, info)
>>>>                   520             // based on isLoggable(level)
>>>>                 calls (03/20/2013)
>>>>                   521             // in jdk project only (including
>>>>                 generated sources)
>>>>                   522             switch (level) {
>>>>                   523                 case FINEST  : return
>>>>                 levelObjects[IDX_FINEST];
>>>>                 // 116 + 2257 matches in generated files
>>>>                   524                 case FINE    : return
>>>>                 levelObjects[IDX_FINE];    // 270
>>>>                   525                 case FINER   : return
>>>>                 levelObjects[IDX_FINER];   // 157
>>>>                   526                 case INFO    : return
>>>>                 levelObjects[IDX_INFO];    // 39
>>>>                   527                 case WARNING : return
>>>>                 levelObjects[IDX_WARNING]; // 12
>>>>                   528                 case CONFIG  : return
>>>>                 levelObjects[IDX_CONFIG];  // 6
>>>>                   529                 case SEVERE  : return
>>>>                 levelObjects[IDX_SEVERE];  // 1
>>>>                   530                 case OFF     : return
>>>>                 levelObjects[IDX_OFF];     // 0
>>>>                   531                 case ALL     : return
>>>>                 levelObjects[IDX_ALL];     // 0
>>>>                   532                 default      : return null;
>>>>                   533             }
>>>>                   534         }
>>>>
>>>>                 I enhanced the PlatformLoggerTest class also and
>>>>                 figured out that TLAB
>>>>                 optimized Integer allocations but I think the patch
>>>>                 is still useful.
>>>>
>>>>                 Can you have a look to the patch ?
>>>>                 Should I write a jtreg test  (performance / GC issue) ?
>>>>
>>>>                 Cheers,
>>>>                 Laurent
>>>>
>>>>
>>>>                 2013/3/20 Mandy Chung >>>                 >
>>>>
>>>>                       Hi Laurent,
>>>>
>>>>                     Thank you for signing the OCA.  Your
>>>>                     contribution is very welcome.  You
>>>>                     can submit a patch for this bug (see [1]) to
>>>>                     Core libraries group which
>>>>                     owns logging.  Jim Gish and I will sponsor it.
>>>>
>>>>                     Thanks
>>>>                     Mandy
>>>>                     [1] http://openjdk.java.net/contribute/
>>>>
>>>>
>>>>                     On 3/20/2013 5:45 AM, Laurent Bourg?s wrote:
>>>>
>>>>                     Hi mandy,
>>>>
>>>>                     Do you want me to propose an improved patch to
>>>>                     remove the former Map and
>>>>                     fix the getLevel() method ? or you prefer fix
>>>>                     on your own ?
>>>>
>>>>                     Is it better to discuss the fix on the bug
>>>>                     database (still not visible) ?
>>>>
>>>>                     Laurent
>>>>
>>>>                     2013/3/19 Mandy Chung >>>                     >
>>>>
>>>>                           Hi Laurent,
>>>>
>>>>                         Thanks for the contribution.  I agree that
>>>>                         the map can be replaced with a
>>>>                         direct mapping from a int value to Level
>>>>                         object and avoid the autoboxing
>>>>                         conversion.
>>>>
>>>>                         I have filed a bug to track this and target
>>>>                         this for JDK8:
>>>>                         http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=
>>>>                         8010309
>>>>
>>>>                         Thanks
>>>>                         Mandy
>>>>
>>>>
>>>>                         On 3/19/13 5:19 AM, Laurent Bourg?s wrote:
>>>>
>>>>                         Dear all,
>>>>
>>>>                         I run recently netbeans profiler on my
>>>>                         swing application
>>>>                         (Aspro2:http://www.jmmc.fr/aspro
>>>>                         ) under linux x64 platform and figured out a
>>>>                         performance and waste issue related to
>>>>                         PlatformLogger.
>>>>
>>>>                         Actually, the JavaLogger implementation
>>>>                         uses a Map
>>>>                         levelObjects to store mapping between
>>>>                         PlatformLogger's levels (int) and JUL
>>>>                         Level instances.
>>>>
>>>>                         However, the isLoggable(int level) method
>>>>                         is highly used by awt project and
>>>>                         other JDK projects and it leads to many
>>>>                         Integer allocations as autoboxing
>>>>                         converts the level as int to an Integer
>>>>                         instance used by the Map.get() call.
>>>>
>>>>                              /**
>>>>                               * JavaLogger forwards all the calls
>>>>                         to its corresponding
>>>>                               * java.util.logging.Logger object.
>>>>                               */
>>>>                              static class JavaLogger extends
>>>>                         LoggerProxy {
>>>>                                  private static final* Map>>>                         Object>* levelObjects = new
>>>>                         HashMap<>();
>>>>                         ...
>>>>                                  public boolean isLoggable(*int
>>>>                         level*) {
>>>>                                      return
>>>>                         LoggingSupport.isLoggable(javaLogger, *
>>>>                         levelObjects.get(level)*);
>>>>                                  }
>>>>                              }
>>>>
>>>>                         I wrote a simple test to illustrate that
>>>>                         performance / waste problem:
>>>>                         PlatformLoggerTest that simply performs 1
>>>>                         million DISABLED log statements:
>>>>                                      if
>>>>                         (log.isLoggable(PlatformLogger.FINEST)) {
>>>>                          log.finest("test PlatformLogger.FINEST");
>>>>                                      }
>>>>
>>>>                         As you can see in screenshots:
>>>>                         - 5 million Integer instances are allocated
>>>>                         - Integer.valueOf(int) is called 5 million
>>>>                         times (autoboxing)
>>>>                         - HashMap.get() represents 30% of the test time
>>>>                         - patched PlatformLogger is 3x times faster
>>>>                         [jvm options: -Xms8m -Xmx8m -verbose:gc]
>>>>
>>>>                         I suggest you to use an alternative way to
>>>>                         map PlatformLogger's levels
>>>>                         (int) and JUL Level instances to fix that
>>>>                         performance / memory issue: I
>>>>                         added the getLevel(int level) method that
>>>>                         performs a switch case to return
>>>>                         the corresponding Level object (quick and
>>>>                         dirty solution).
>>>>
>>>>                         I advocate this is not a very clean
>>>>                         solution but I prefer efficiency here:
>>>>                         any better solution may be appropriate to
>>>>                         avoid at least Integer allocation
>>>>                         and maybe enhance performance.
>>>>
>>>>                         Best regards,
>>>>                         Laurent Bourg?s
>>>>
>>>>                         PS: here is the patch as text:
>>>>
>>>>                         # This patch file was generated by NetBeans IDE
>>>>                         # It uses platform neutral UTF-8 encoding
>>>>                         and \n newlines.
>>>>                         --- PlatformLogger.java (6767)
>>>>                         +++ PlatformLogger.java (6768)
>>>>                         @@ -468,31 +468,13 @@
>>>>                                * java.util.logging.Logger object.
>>>>                                */
>>>>                               static class JavaLogger extends
>>>>                         LoggerProxy {
>>>>                         -        /** Note: using Integer keys leads
>>>>                         to a lot of new Integer
>>>>                         instances !! */
>>>>                         -        private static final Map>>>                         Object> levelObjects = new
>>>>                         HashMap<>();
>>>>                         -        /** fastest mapping to Level
>>>>                         instances from PlatformLogger level
>>>>                         as integer */
>>>>                         -        private static final Object[]
>>>>                         fastLevelObjects;
>>>>                         -
>>>>                         -
>>>>                         +        private static final Map>>>                         Object> levelObjects =
>>>>                         +            new HashMap<>();
>>>>                         +
>>>>                                   static {
>>>>                                       if
>>>>                         (LoggingSupport.isAvailable()) {
>>>>                                           // initialize the map to
>>>>                         Level objects
>>>>                         getLevelObjects();
>>>>                         -
>>>>                         -                // initialize the
>>>>                         fastLevelObjects:
>>>>                         -  fastLevelObjects = new Object[] {
>>>>                         -
>>>>                          LoggingSupport.parseLevel(getLevelName(OFF)),
>>>>                               //
>>>>                         0
>>>>                         -
>>>>                          LoggingSupport.parseLevel(getLevelName(SEVERE)),
>>>>                            //
>>>>                         1
>>>>                         -
>>>>                          LoggingSupport.parseLevel(getLevelName(WARNING)),
>>>>                           //
>>>>                         2
>>>>                         -
>>>>                          LoggingSupport.parseLevel(getLevelName(INFO)),
>>>>                              //
>>>>                         3
>>>>                         -
>>>>                          LoggingSupport.parseLevel(getLevelName(CONFIG)),
>>>>                            //
>>>>                         4
>>>>                         -
>>>>                          LoggingSupport.parseLevel(getLevelName(FINE)),
>>>>                              //
>>>>                         5
>>>>                         -
>>>>                          LoggingSupport.parseLevel(getLevelName(FINER)),
>>>>                             //
>>>>                         6
>>>>                         -
>>>>                          LoggingSupport.parseLevel(getLevelName(FINEST)),
>>>>                            //
>>>>                         7
>>>>                         -
>>>>                          LoggingSupport.parseLevel(getLevelName(ALL))
>>>>                                //
>>>>                         8
>>>>                         -                };
>>>>                         -            } else {
>>>>                         -  fastLevelObjects = null; // check null
>>>>                                       }
>>>>                                   }
>>>>
>>>>                         @@ -515,7 +497,7 @@
>>>>                         this.javaLogger =
>>>>                         LoggingSupport.getLogger(name);
>>>>                                       if (level != 0) {
>>>>                                           // level has been updated
>>>>                         and so set the Logger's level
>>>>                         -  LoggingSupport.setLevel(javaLogger,
>>>>                         getLevel(level));
>>>>                         +  LoggingSupport.setLevel(javaLogger,
>>>>                         levelObjects.get(level));
>>>>                                       }
>>>>                                   }
>>>>
>>>>                         @@ -526,11 +508,11 @@
>>>>                                   * not be updated.
>>>>                                   */
>>>>                                   void doLog(int level, String msg) {
>>>>                         -  LoggingSupport.log(javaLogger,
>>>>                         getLevel(level), msg);
>>>>                         +  LoggingSupport.log(javaLogger,
>>>>                         levelObjects.get(level), msg);
>>>>                                   }
>>>>
>>>>                                   void doLog(int level, String msg,
>>>>                         Throwable t) {
>>>>                         -  LoggingSupport.log(javaLogger,
>>>>                         getLevel(level), msg, t);
>>>>                         +  LoggingSupport.log(javaLogger,
>>>>                         levelObjects.get(level), msg,
>>>>                         t);
>>>>                                   }
>>>>
>>>>                                   void doLog(int level, String msg,
>>>>                         Object... params) {
>>>>                         @@ -544,12 +526,12 @@
>>>>                                       for (int i = 0; i < len; i++) {
>>>>                                           sparams [i] =
>>>>                         String.valueOf(params[i]);
>>>>                                       }
>>>>                         -  LoggingSupport.log(javaLogger,
>>>>                         getLevel(level), msg, sparams);
>>>>                         +  LoggingSupport.log(javaLogger,
>>>>                         levelObjects.get(level), msg,
>>>>                         sparams);
>>>>                                   }
>>>>
>>>>                                   boolean isEnabled() {
>>>>                                       Object level =
>>>>                         LoggingSupport.getLevel(javaLogger);
>>>>                         -            return level == null ||
>>>>                         level.equals(getLevel(OFF)) == false;
>>>>                         +            return level == null ||
>>>>                         level.equals(levelObjects.get(OFF)) ==
>>>>                         false;
>>>>                                   }
>>>>
>>>>                                   int getLevel() {
>>>>                         @@ -566,34 +548,12 @@
>>>>
>>>>                                   void setLevel(int newLevel) {
>>>>                                       levelValue = newLevel;
>>>>                         -  LoggingSupport.setLevel(javaLogger,
>>>>                         getLevel(newLevel));
>>>>                         +  LoggingSupport.setLevel(javaLogger,
>>>>                         levelObjects.get(newLevel));
>>>>                                   }
>>>>
>>>>                                   public boolean isLoggable(int
>>>>                         level) {
>>>>                         -            return
>>>>                         LoggingSupport.isLoggable(javaLogger,
>>>>                         getLevel(level));
>>>>                         +            return
>>>>                         LoggingSupport.isLoggable(javaLogger,
>>>>                         levelObjects.get(level));
>>>>                                   }
>>>>                         -
>>>>                         -        /**
>>>>                         -         * Return the corresponding level
>>>>                         object (fastest implementation)
>>>>                         -         * @param level PlatformLogger
>>>>                         level as primitive integer
>>>>                         -         * @return Object (JUL Level instance)
>>>>                         -         */
>>>>                         -        private static Object
>>>>                         getLevel(final int level) {
>>>>                         -            // higher occurences first
>>>>                         (finest, fine, finer, info):
>>>>                         -            switch (level) {
>>>>                         -                case FINEST  : return
>>>>                         fastLevelObjects[7];
>>>>                         -                case FINE    : return
>>>>                         fastLevelObjects[5];
>>>>                         -                case FINER   : return
>>>>                         fastLevelObjects[6];
>>>>                         -                case INFO    : return
>>>>                         fastLevelObjects[3];
>>>>                         -                case CONFIG  : return
>>>>                         fastLevelObjects[4];
>>>>                         -                case WARNING : return
>>>>                         fastLevelObjects[2];
>>>>                         -                case SEVERE  : return
>>>>                         fastLevelObjects[1];
>>>>                         -                case ALL     : return
>>>>                         fastLevelObjects[8];
>>>>                         -                case OFF     : return
>>>>                         fastLevelObjects[0];
>>>>                         -                default    : return null;
>>>>                         -            }
>>>>                         -        }
>>>>                         -
>>>>                               }
>>>>
>>>>                               private static String
>>>>                         getLevelName(int level) {
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
>



From peter.levart at gmail.com  Thu Mar 21 16:57:28 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 21 Mar 2013 17:57:28 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due
	to HashMap leads to Integer allocations (boxing)
In-Reply-To: <514B30B1.2010005@gmail.com>
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com>
	
	<514B30B1.2010005@gmail.com>
Message-ID: <514B3BF8.8090207@gmail.com>

Hi Laurent, Mandy,

I think I've got it now. It's a middle-ground. It would be a shame to 
loose the code-reuse (one switch instead of two). So I only moved the 
levelObjects to JavaLogger, not the entire LevelEnum:

http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.04/index.html

So this is basically similar to original code. It just uses LevelEnum 
instead of java.lang.Integer and EnumMap instead of HashMap. Hopefully 
these perform better. If I moved the LevelEnum into the JavaLogger, I 
would have to re-instate the second switch for LoggerProxy and the 
solution would not be much simpler than your patch, Laurent. This is 
still just 20 LOC more than original code.

Regards, Peter

On 03/21/2013 05:09 PM, Peter Levart wrote:
> You're right, loggingEnabled can change afterwards. I'll correct the 
> code as suggested...
>
> Peter
>
> On 03/21/2013 04:57 PM, Laurent Bourg?s wrote:
>> Peter,
>>
>> I am convinced it is better if the LevelEnum belongs to JavaLogger 
>> class (encapsulated so defered initialization).
>>
>> Here is a typical scenario:
>> 1 - PlatformLogger initialized (not JUL) => LoggerProxy must work so 
>> LevelEnum can not be used and the formergetLevelName() (switch case) 
>> is required.
>> 2 - JUL initialized: calls redirectPlatformLogger() => JavaLoggers 
>> created => LevelEnum initialized (Level object can be retrieved from 
>> LoggingSupport)
>>
>> For example, JUL can be started programmatically so the 
>> loggingEnabled flag is not enough to initialize the LevelEnum.object 
>> at step 1 and it will be null. Then at step 2, LevelEnum.object are 
>> null so the JavaLogger is broken.
>>
>> Here is a test of this scenario:
>> public static void main(String[] args) {
>>
>>     final PlatformLogger log = 
>> PlatformLogger.getLogger("sun.awt.X11"); // 1: LoggerProxy
>>
>>     if (log.isLoggable(PlatformLogger.INFO)) {
>> log.info ("PlatformLogger.INFO: LoggerProxy");
>>     }
>>
>>     final Logger logger = Logger.getLogger("test");
>> //   calls PlatformLogger.redirectPlatformLoggers(); // 2 : JavaLogger
>>
>>     if (log.isLoggable(PlatformLogger.INFO)) {
>> log.info ("PlatformLogger.INFO: JavaLogger");
>>     }
>>
>> logger.info ("done");
>> }
>>
>> Laurent
>>
>> 2013/3/21 Peter Levart > >
>>
>>     Hi Laurent, Mandy,
>>
>>     Let me try one more time (it would be less optimal to have 2
>>     switch statements instead of one). Here's the 3rd webrev:
>>
>>     http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.03/index.html
>>
>>     The changes:
>>     - added the comments
>>     - made LevelEnum private (to not be tempted to be used from
>>     outside the PlatformLogger)
>>     - used the loggingEnabled flag as a pre-check when trying to
>>     parse the level objects
>>
>>
>>     What do you think?
>>
>>     Regards, Peter
>>
>>     On 03/21/2013 04:06 PM, Laurent Bourg?s wrote:
>>>     Thanks Mandy for the clarifications !
>>>
>>>     Peter, I propose to:
>>>     - move the LevelEnum into the JavaLogger class in order to
>>>     initialize it as later as possible i.e. after j.u.l calls
>>>     redirectPlatformLoggers()
>>>     - only use it in JavaLogger class (private enum) so revert
>>>     changes to PlatformLogger and LoggerProxy classes
>>>     - add few comments in the code to explain lazy initialization
>>>     (see mandy's answer)
>>>
>>>     Finally, could you keep my comment before the switch case (high
>>>     occurences first) ?
>>>     +        static LevelEnum forValue(int levelValue) {
>>>
>>>     +            // higher occurences first (finest, fine, finer, info)
>>>     +            // based on isLoggable(level) calls (03/20/2013)
>>>     +            // in jdk project only (including generated sources)
>>>
>>>     +            switch (levelValue) {
>>>     +                case PlatformLogger.FINEST:  return FINEST;  // 116 + 2257 matches in generated files
>>>     +                case PlatformLogger.FINE:    return FINE;    // 270
>>>
>>>     +                case PlatformLogger.FINER:   return FINER;   // 157
>>>     +                case PlatformLogger.INFO:    return INFO;    // 39
>>>     +                case PlatformLogger.WARNING: return WARNING; // 12
>>>
>>>     +                case PlatformLogger.CONFIG:  return CONFIG;  // 6
>>>     +                case PlatformLogger.SEVERE:  return SEVERE;  // 1
>>>     +                case PlatformLogger.OFF:     return OFF;     // 0
>>>
>>>     +                case PlatformLogger.ALL:     return ALL;     // 0
>>>     +                default:                     return UNKNOWN;
>>>     +            }
>>>
>>>     +        }
>>>
>>>     cheers,
>>>     Laurent
>>>
>>>     2013/3/21 Mandy Chung >>     >
>>>
>>>         Laurent, Peter,
>>>
>>>         I haven't looked at the patch yet.  One thing worths
>>>         mentioning is that PlatformLogger was added for the platform
>>>         code to use so as to avoid the initialization of
>>>         java.util.logging since logging is not turned on by default
>>>         and that to reduce the startup overhead.   In addition, it
>>>         also enables the elimination of the core classes dependency
>>>         from java.util.logging for modularization effort. Therefore
>>>         the PlatformLogger only lazily looks up the Level object
>>>         when java.util.logging is present and also has been
>>>         initialized by application code.
>>>
>>>         Mandy
>>>
>>>
>>>         On 3/21/2013 7:45 AM, Peter Levart wrote:
>>>>         On 03/21/2013 03:30 PM, Laurent Bourg?s wrote:
>>>>>         Peter,
>>>>>
>>>>>         your solution looks better; I wanted my patch to be
>>>>>         simple, efficient and only modify the JavaLogger class
>>>>>         (localized changes).
>>>>>
>>>>>         In your patch, I have doubts related to lazy and
>>>>>         conditional initialization in JavaLogger (static
>>>>>         initialization):
>>>>>         if (LoggingSupport.isAvailable()) {
>>>>>              // initialize ...
>>>>>         }
>>>>
>>>>         In original code, if LoggingSupport.isAvailable() returned
>>>>         false, levelObjects map remained empty and consequently
>>>>         null was used as the level object passed to LoggingSupport
>>>>         methods. In LevelEnum I try to keep this logic. When
>>>>         LevelEnum is first used, it's constants are initialized and
>>>>         level objects with them. If
>>>>         LoggingSupport.isAvailable() returns false, level objects
>>>>         are initialized to null.
>>>>
>>>>         I just noticed there's a bug in initialization of the
>>>>         LevelEnum.UNKNOWN member constant. It should not try to
>>>>         parse level object. Here's an update:
>>>>
>>>>         http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.02/index.html
>>>>
>>>>         But your concern might be correct. In my code LevelEnum is
>>>>         also used from the LoggerProxy.format() method (in addition
>>>>         to all the places in JavaLogger) to obtain the level name
>>>>         for formatting. If this method is called the first time
>>>>         while LoggingSupport.isAvailable() returns false and that
>>>>         happens before JavaLogger uses LevelEnum for the first time
>>>>         (and at that time LoggingSupport.isAvailable() would return
>>>>         true), then level objects will not be initialized correctly.
>>>>
>>>>         Lazy initialization of level objects might help (for the
>>>>         price of added complexity)...
>>>>
>>>>         Regards, Peter
>>>>
>>>>>         Does somebody have the knowledge about LoggingSupport.isAvailable()
>>>>>
>>>>>         and the lazy PlatformLogger initialization (JavaLogger are only used when j.u.l is initialized) ?
>>>>>
>>>>>
>>>>>         What's happening if LoggingSupport.isAvailable() returns false in your patch ?
>>>>>         - LevelEnum  instances are incorrectly initialized:object field is null !
>>>>>
>>>>>         - PlatformLogger is then broken ... as Level object are required by j.u.l calls
>>>>>
>>>>>
>>>>>         To fix both problems, moving theLevelEnum  into JavaLogger should help and check nulls onLevelEnum.object field.
>>>>>
>>>>>
>>>>>         Thanks for your feedback,
>>>>>         Laurent
>>>>>
>>>>>
>>>>>         2013/3/21 Peter Levart >>>>         >
>>>>>
>>>>>             On 03/21/2013 12:12 PM, Laurent Bourg?s wrote:
>>>>>
>>>>>                 Here is an improved patch tested on JDK7u13 and
>>>>>                 JDK8 internal build on my
>>>>>                 machine linux x64:
>>>>>                 http://jmmc.fr/~bourgesl/share/webrev-8010309/
>>>>>                 
>>>>>
>>>>>                 FYI, I removed completely the Map
>>>>>                 levelObjects and used
>>>>>                 two arrays to perform the PlatformLogger's level
>>>>>                 (int) to j.u.l.Level
>>>>>                 mapping:
>>>>>
>>>>>                 I decided to keep it simple as possible (no enum
>>>>>                 ...) and used a switch
>>>>>                 case based on current level occurences:
>>>>>
>>>>>
>>>>>             Hi Laurent,
>>>>>
>>>>>             In my experience enums are just the right and most
>>>>>             compact tool for coding such constant associations.
>>>>>             Here's a quick try (ripping off your optimized switch ;-):
>>>>>
>>>>>             http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.01/index.html
>>>>>
>>>>>             ...it adds 12 LOC to the original PlatformLogger and
>>>>>             is 43 LOC less tha your patch. In addition:
>>>>>
>>>>>             - only one switch instead of two (to maintain)
>>>>>             - no parallel IDX_ constants
>>>>>
>>>>>             What do you think?
>>>>>
>>>>>             Regards, Peter
>>>>>
>>>>>
>>>>>
>>>>>                   510         /**
>>>>>                   511          * Return the corresponding
>>>>>                 j.u.l.Level instance
>>>>>                   512          * @param level PlatformLogger level
>>>>>                 as integer
>>>>>                   513          * @return Object (j.u.l.Level
>>>>>                 instance) or null if no
>>>>>                 matching level
>>>>>                   514          */
>>>>>                   515         private static Object getLevel(final
>>>>>                 int level) {
>>>>>                   516             if (levelObjects == null) {
>>>>>                   517                 return null;
>>>>>                   518             }
>>>>>                   519             // higher occurences first
>>>>>                 (finest, fine, finer, info)
>>>>>                   520             // based on isLoggable(level)
>>>>>                 calls (03/20/2013)
>>>>>                   521             // in jdk project only
>>>>>                 (including generated sources)
>>>>>                   522             switch (level) {
>>>>>                   523                 case FINEST  : return
>>>>>                 levelObjects[IDX_FINEST];
>>>>>                 // 116 + 2257 matches in generated files
>>>>>                   524                 case FINE    : return
>>>>>                 levelObjects[IDX_FINE];  // 270
>>>>>                   525                 case FINER   : return
>>>>>                 levelObjects[IDX_FINER]; // 157
>>>>>                   526                 case INFO    : return
>>>>>                 levelObjects[IDX_INFO];  // 39
>>>>>                   527                 case WARNING : return
>>>>>                 levelObjects[IDX_WARNING]; // 12
>>>>>                   528                 case CONFIG  : return
>>>>>                 levelObjects[IDX_CONFIG];  // 6
>>>>>                   529                 case SEVERE  : return
>>>>>                 levelObjects[IDX_SEVERE];  // 1
>>>>>                   530                 case OFF     : return
>>>>>                 levelObjects[IDX_OFF]; // 0
>>>>>                   531                 case ALL     : return
>>>>>                 levelObjects[IDX_ALL]; // 0
>>>>>                   532 default      : return null;
>>>>>                   533             }
>>>>>                   534         }
>>>>>
>>>>>                 I enhanced the PlatformLoggerTest class also and
>>>>>                 figured out that TLAB
>>>>>                 optimized Integer allocations but I think the
>>>>>                 patch is still useful.
>>>>>
>>>>>                 Can you have a look to the patch ?
>>>>>                 Should I write a jtreg test  (performance / GC
>>>>>                 issue) ?
>>>>>
>>>>>                 Cheers,
>>>>>                 Laurent
>>>>>
>>>>>
>>>>>                 2013/3/20 Mandy Chung >>>>                 >
>>>>>
>>>>>                       Hi Laurent,
>>>>>
>>>>>                     Thank you for signing the OCA.  Your
>>>>>                     contribution is very welcome.  You
>>>>>                     can submit a patch for this bug (see [1]) to
>>>>>                     Core libraries group which
>>>>>                     owns logging.  Jim Gish and I will sponsor it.
>>>>>
>>>>>                     Thanks
>>>>>                     Mandy
>>>>>                     [1] http://openjdk.java.net/contribute/
>>>>>
>>>>>
>>>>>                     On 3/20/2013 5:45 AM, Laurent Bourg?s wrote:
>>>>>
>>>>>                     Hi mandy,
>>>>>
>>>>>                     Do you want me to propose an improved patch to
>>>>>                     remove the former Map and
>>>>>                     fix the getLevel() method ? or you prefer fix
>>>>>                     on your own ?
>>>>>
>>>>>                     Is it better to discuss the fix on the bug
>>>>>                     database (still not visible) ?
>>>>>
>>>>>                     Laurent
>>>>>
>>>>>                     2013/3/19 Mandy Chung >>>>                     >
>>>>>
>>>>>                           Hi Laurent,
>>>>>
>>>>>                         Thanks for the contribution.  I agree that
>>>>>                         the map can be replaced with a
>>>>>                         direct mapping from a int value to Level
>>>>>                         object and avoid the autoboxing
>>>>>                         conversion.
>>>>>
>>>>>                         I have filed a bug to track this and
>>>>>                         target this for JDK8:
>>>>>                         http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=
>>>>>                         8010309
>>>>>
>>>>>                         Thanks
>>>>>                         Mandy
>>>>>
>>>>>
>>>>>                         On 3/19/13 5:19 AM, Laurent Bourg?s wrote:
>>>>>
>>>>>                         Dear all,
>>>>>
>>>>>                         I run recently netbeans profiler on my
>>>>>                         swing application
>>>>>                         (Aspro2:http://www.jmmc.fr/aspro
>>>>>                         ) under linux x64 platform and figured out a
>>>>>                         performance and waste issue related to
>>>>>                         PlatformLogger.
>>>>>
>>>>>                         Actually, the JavaLogger implementation
>>>>>                         uses a Map
>>>>>                         levelObjects to store mapping between
>>>>>                         PlatformLogger's levels (int) and JUL
>>>>>                         Level instances.
>>>>>
>>>>>                         However, the isLoggable(int level) method
>>>>>                         is highly used by awt project and
>>>>>                         other JDK projects and it leads to many
>>>>>                         Integer allocations as autoboxing
>>>>>                         converts the level as int to an Integer
>>>>>                         instance used by the Map.get() call.
>>>>>
>>>>>                              /**
>>>>>                               * JavaLogger forwards all the calls
>>>>>                         to its corresponding
>>>>>                               * java.util.logging.Logger object.
>>>>>                               */
>>>>>                              static class JavaLogger extends
>>>>>                         LoggerProxy {
>>>>>                                  private static final*
>>>>>                         Map* levelObjects = new
>>>>>                         HashMap<>();
>>>>>                         ...
>>>>>                                  public boolean isLoggable(*int
>>>>>                         level*) {
>>>>>                                      return
>>>>>                         LoggingSupport.isLoggable(javaLogger, *
>>>>>                         levelObjects.get(level)*);
>>>>>                                  }
>>>>>                              }
>>>>>
>>>>>                         I wrote a simple test to illustrate that
>>>>>                         performance / waste problem:
>>>>>                         PlatformLoggerTest that simply performs 1
>>>>>                         million DISABLED log statements:
>>>>>                                      if
>>>>>                         (log.isLoggable(PlatformLogger.FINEST)) {
>>>>>                          log.finest("test PlatformLogger.FINEST");
>>>>>                                      }
>>>>>
>>>>>                         As you can see in screenshots:
>>>>>                         - 5 million Integer instances are allocated
>>>>>                         - Integer.valueOf(int) is called 5 million
>>>>>                         times (autoboxing)
>>>>>                         - HashMap.get() represents 30% of the test
>>>>>                         time
>>>>>                         - patched PlatformLogger is 3x times faster
>>>>>                         [jvm options: -Xms8m -Xmx8m -verbose:gc]
>>>>>
>>>>>                         I suggest you to use an alternative way to
>>>>>                         map PlatformLogger's levels
>>>>>                         (int) and JUL Level instances to fix that
>>>>>                         performance / memory issue: I
>>>>>                         added the getLevel(int level) method that
>>>>>                         performs a switch case to return
>>>>>                         the corresponding Level object (quick and
>>>>>                         dirty solution).
>>>>>
>>>>>                         I advocate this is not a very clean
>>>>>                         solution but I prefer efficiency here:
>>>>>                         any better solution may be appropriate to
>>>>>                         avoid at least Integer allocation
>>>>>                         and maybe enhance performance.
>>>>>
>>>>>                         Best regards,
>>>>>                         Laurent Bourg?s
>>>>>
>>>>>                         PS: here is the patch as text:
>>>>>
>>>>>                         # This patch file was generated by
>>>>>                         NetBeans IDE
>>>>>                         # It uses platform neutral UTF-8 encoding
>>>>>                         and \n newlines.
>>>>>                         --- PlatformLogger.java (6767)
>>>>>                         +++ PlatformLogger.java (6768)
>>>>>                         @@ -468,31 +468,13 @@
>>>>>                                * java.util.logging.Logger object.
>>>>>                                */
>>>>>                               static class JavaLogger extends
>>>>>                         LoggerProxy {
>>>>>                         -        /** Note: using Integer keys
>>>>>                         leads to a lot of new Integer
>>>>>                         instances !! */
>>>>>                         -        private static final Map>>>>                         Object> levelObjects = new
>>>>>                         HashMap<>();
>>>>>                         -        /** fastest mapping to Level
>>>>>                         instances from PlatformLogger level
>>>>>                         as integer */
>>>>>                         -        private static final Object[]
>>>>>                         fastLevelObjects;
>>>>>                         -
>>>>>                         -
>>>>>                         +        private static final Map>>>>                         Object> levelObjects =
>>>>>                         +            new HashMap<>();
>>>>>                         +
>>>>>                                   static {
>>>>>                                       if
>>>>>                         (LoggingSupport.isAvailable()) {
>>>>>                                           // initialize the map to
>>>>>                         Level objects
>>>>>                         getLevelObjects();
>>>>>                         -
>>>>>                         -                // initialize the
>>>>>                         fastLevelObjects:
>>>>>                         -  fastLevelObjects = new Object[] {
>>>>>                         -
>>>>>                          LoggingSupport.parseLevel(getLevelName(OFF)),
>>>>>                               //
>>>>>                         0
>>>>>                         -
>>>>>                          LoggingSupport.parseLevel(getLevelName(SEVERE)),
>>>>>                            //
>>>>>                         1
>>>>>                         -
>>>>>                          LoggingSupport.parseLevel(getLevelName(WARNING)),
>>>>>                           //
>>>>>                         2
>>>>>                         -
>>>>>                          LoggingSupport.parseLevel(getLevelName(INFO)),
>>>>>                              //
>>>>>                         3
>>>>>                         -
>>>>>                          LoggingSupport.parseLevel(getLevelName(CONFIG)),
>>>>>                            //
>>>>>                         4
>>>>>                         -
>>>>>                          LoggingSupport.parseLevel(getLevelName(FINE)),
>>>>>                              //
>>>>>                         5
>>>>>                         -
>>>>>                          LoggingSupport.parseLevel(getLevelName(FINER)),
>>>>>                             //
>>>>>                         6
>>>>>                         -
>>>>>                          LoggingSupport.parseLevel(getLevelName(FINEST)),
>>>>>                            //
>>>>>                         7
>>>>>                         -
>>>>>                          LoggingSupport.parseLevel(getLevelName(ALL))
>>>>>                                //
>>>>>                         8
>>>>>                         -                };
>>>>>                         -            } else {
>>>>>                         -  fastLevelObjects = null; // check null
>>>>>                                       }
>>>>>                                   }
>>>>>
>>>>>                         @@ -515,7 +497,7 @@
>>>>>                         this.javaLogger =
>>>>>                         LoggingSupport.getLogger(name);
>>>>>                                       if (level != 0) {
>>>>>                                           // level has been
>>>>>                         updated and so set the Logger's level
>>>>>                         -  LoggingSupport.setLevel(javaLogger,
>>>>>                         getLevel(level));
>>>>>                         +  LoggingSupport.setLevel(javaLogger,
>>>>>                         levelObjects.get(level));
>>>>>                                       }
>>>>>                                   }
>>>>>
>>>>>                         @@ -526,11 +508,11 @@
>>>>>                                   * not be updated.
>>>>>                                   */
>>>>>                                   void doLog(int level, String msg) {
>>>>>                         -  LoggingSupport.log(javaLogger,
>>>>>                         getLevel(level), msg);
>>>>>                         +  LoggingSupport.log(javaLogger,
>>>>>                         levelObjects.get(level), msg);
>>>>>                                   }
>>>>>
>>>>>                                   void doLog(int level, String
>>>>>                         msg, Throwable t) {
>>>>>                         -  LoggingSupport.log(javaLogger,
>>>>>                         getLevel(level), msg, t);
>>>>>                         +  LoggingSupport.log(javaLogger,
>>>>>                         levelObjects.get(level), msg,
>>>>>                         t);
>>>>>                                   }
>>>>>
>>>>>                                   void doLog(int level, String
>>>>>                         msg, Object... params) {
>>>>>                         @@ -544,12 +526,12 @@
>>>>>                                       for (int i = 0; i < len; i++) {
>>>>>                         sparams [i] = String.valueOf(params[i]);
>>>>>                                       }
>>>>>                         -  LoggingSupport.log(javaLogger,
>>>>>                         getLevel(level), msg, sparams);
>>>>>                         +  LoggingSupport.log(javaLogger,
>>>>>                         levelObjects.get(level), msg,
>>>>>                         sparams);
>>>>>                                   }
>>>>>
>>>>>                                   boolean isEnabled() {
>>>>>                                       Object level =
>>>>>                         LoggingSupport.getLevel(javaLogger);
>>>>>                         -            return level == null ||
>>>>>                         level.equals(getLevel(OFF)) == false;
>>>>>                         +            return level == null ||
>>>>>                         level.equals(levelObjects.get(OFF)) ==
>>>>>                         false;
>>>>>                                   }
>>>>>
>>>>>                                   int getLevel() {
>>>>>                         @@ -566,34 +548,12 @@
>>>>>
>>>>>                                   void setLevel(int newLevel) {
>>>>>                                       levelValue = newLevel;
>>>>>                         -  LoggingSupport.setLevel(javaLogger,
>>>>>                         getLevel(newLevel));
>>>>>                         +  LoggingSupport.setLevel(javaLogger,
>>>>>                         levelObjects.get(newLevel));
>>>>>                                   }
>>>>>
>>>>>                                   public boolean isLoggable(int
>>>>>                         level) {
>>>>>                         -            return
>>>>>                         LoggingSupport.isLoggable(javaLogger,
>>>>>                         getLevel(level));
>>>>>                         +            return
>>>>>                         LoggingSupport.isLoggable(javaLogger,
>>>>>                         levelObjects.get(level));
>>>>>                                   }
>>>>>                         -
>>>>>                         -        /**
>>>>>                         -         * Return the corresponding level
>>>>>                         object (fastest implementation)
>>>>>                         -         * @param level PlatformLogger
>>>>>                         level as primitive integer
>>>>>                         -         * @return Object (JUL Level
>>>>>                         instance)
>>>>>                         -         */
>>>>>                         -        private static Object
>>>>>                         getLevel(final int level) {
>>>>>                         -            // higher occurences first
>>>>>                         (finest, fine, finer, info):
>>>>>                         -            switch (level) {
>>>>>                         -                case FINEST  : return
>>>>>                         fastLevelObjects[7];
>>>>>                         -                case FINE    : return
>>>>>                         fastLevelObjects[5];
>>>>>                         -                case FINER   : return
>>>>>                         fastLevelObjects[6];
>>>>>                         -                case INFO    : return
>>>>>                         fastLevelObjects[3];
>>>>>                         -                case CONFIG  : return
>>>>>                         fastLevelObjects[4];
>>>>>                         -                case WARNING : return
>>>>>                         fastLevelObjects[2];
>>>>>                         -                case SEVERE  : return
>>>>>                         fastLevelObjects[1];
>>>>>                         -                case ALL     : return
>>>>>                         fastLevelObjects[8];
>>>>>                         -                case OFF     : return
>>>>>                         fastLevelObjects[0];
>>>>>                         -                default      : return null;
>>>>>                         -            }
>>>>>                         -        }
>>>>>                         -
>>>>>                               }
>>>>>
>>>>>                               private static String
>>>>>                         getLevelName(int level) {
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>



From martinrb at google.com  Thu Mar 21 17:10:27 2013
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 21 Mar 2013 10:10:27 -0700
Subject: RFR-8008118
In-Reply-To: <0a02b31c-3f87-43f8-99b4-318cd57fa717@default>
References: <0a02b31c-3f87-43f8-99b4-318cd57fa717@default>
Message-ID: 

Please revert this formatting change:

-        for (q = p; (*q != ':') && (*q != '\0'); q++)
-            ;
+        for (q = p; (*q != ':') && (*q != '\0'); q++);
+

I would not introduce variable k and just count down from i, like this:

if (pathv[i] == NULL) {
  for (i--; i >= 0; i--)
    free(pathv[i]);
  return NULL;
}

which looks a little cleaner.


On Thu, Mar 21, 2013 at 8:53 AM, John Zavgren wrote:

> All:
> I modified the splitPath() procedure so that when it encounters an OOM
> error it frees allocated memory before exiting.
>
> Thanks!
> John
>
> http://cr.openjdk.java.net/~jzavgren/8008118/webrev.03/
>
> ----- Original Message -----
> From: martinrb at google.com
> To: chris.hegarty at oracle.com
> Cc: john.zavgren at oracle.com, core-libs-dev at openjdk.java.net
> Sent: Wednesday, March 20, 2013 7:32:39 PM GMT -05:00 US/Canada Eastern
> Subject: Re: RFR-8008118
>
>
>
>
> On Wed, Mar 20, 2013 at 4:23 PM, Chris Hegarty wrote:
>
>> Martin,
>>
>> I take your point about the other allocations, but as you say OOM is
>> better than SEGV. So possibly good enough?
>>
>>
> Ah, Thanks Chris, I had forgotten that NEW *does* throw OOME.
>
>
>> If NEW returns NULL, then there will be a pending OOM on the stack.
>>
>>
> good point!
> In that case, this is indeed a clear improvement, and I leave it to John
> whether to undo the allocations in splitPath before returning.
>
> Just add that space after "if", please, before you submit!
>
>
>


From Alan.Bateman at oracle.com  Thu Mar 21 17:16:02 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 21 Mar 2013 17:16:02 +0000
Subject: RFR-8008118
In-Reply-To: <0a02b31c-3f87-43f8-99b4-318cd57fa717@default>
References: <0a02b31c-3f87-43f8-99b4-318cd57fa717@default>
Message-ID: <514B4052.1020902@oracle.com>

On 21/03/2013 15:53, John Zavgren wrote:
> All:
> I modified the splitPath() procedure so that when it encounters an OOM error it frees allocated memory before exiting.
>
>
> Thanks!
> John
>
>
> http://cr.openjdk.java.net/~jzavgren/8008118/webrev.03/
>
Will this work with empty path components ("./"), I assume they need to 
be skipped when freeing.

-Alan


From martinrb at google.com  Thu Mar 21 17:26:25 2013
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 21 Mar 2013 10:26:25 -0700
Subject: RFR-8008118
In-Reply-To: 
References: <0a02b31c-3f87-43f8-99b4-318cd57fa717@default>
	
Message-ID: 

On Thu, Mar 21, 2013 at 10:10 AM, Martin Buchholz wrote:

>
> if (pathv[i] == NULL) {
>   for (i--; i >= 0; i--)
>     free(pathv[i]);
>   return NULL;
> }
>
>

Alan correctly points out that you can't free "./".

static const char * const cwd = "./";
...
 if (pathv[i] == NULL) {
  for (i--; i >= 0; i--)
    if (pathv[i] != cwd)
       free(pathv[i]);
  return NULL;
}

Manual memory management is a drag.


From rob.mckenna at oracle.com  Thu Mar 21 17:32:52 2013
From: rob.mckenna at oracle.com (rob.mckenna at oracle.com)
Date: Thu, 21 Mar 2013 17:32:52 +0000
Subject: hg: jdk8/tl/jdk: 8009251: Add proxy handling and keep-alive fixes to
	jsse
Message-ID: <20130321173305.A6311482F0@hg.openjdk.java.net>

Changeset: 3f8fbb0ab155
Author:    robm
Date:      2013-03-21 17:33 +0000
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3f8fbb0ab155

8009251: Add proxy handling and keep-alive fixes to jsse
Reviewed-by: chegar

! src/share/classes/sun/net/www/http/HttpClient.java
! src/share/classes/sun/net/www/protocol/https/AbstractDelegateHttpsURLConnection.java
! src/share/classes/sun/net/www/protocol/https/HttpsClient.java



From martinrb at google.com  Thu Mar 21 17:44:12 2013
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 21 Mar 2013 10:44:12 -0700
Subject: Please review: surrogate fiddle
In-Reply-To: <514AFD30.7010602@CoSoCo.de>
References: 
	
	
	<5147D0F8.3090101@oracle.com>
	
	<51480152.5010102@oracle.com>
	
	
	<5148B539.4020508@oracle.com>
	
	<5149C30E.1080405@CoSoCo.de>
	
	<514AFD30.7010602@CoSoCo.de>
Message-ID: 

On Thu, Mar 21, 2013 at 5:29 AM, Ulf Zibis  wrote:

>
> Thanks!
> But what's about the "wrong" exception index reporting, e.g. 0 as "out of
> bounds"?
>
>
I am not going to change the exceptions thrown from these methods, even
though I agree we could do a little better if this was new code.


From martinrb at google.com  Thu Mar 21 17:47:02 2013
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 21 Mar 2013 10:47:02 -0700
Subject: Please review: surrogate fiddle
In-Reply-To: <514B036B.70408@CoSoCo.de>
References: 
	
	
	<5147D0F8.3090101@oracle.com>
	
	<51480152.5010102@oracle.com>
	
	
	<5148B539.4020508@oracle.com>
	
	<5149C30E.1080405@CoSoCo.de>
	
	<514B036B.70408@CoSoCo.de>
Message-ID: 

On Thu, Mar 21, 2013 at 5:56 AM, Ulf Zibis  wrote:

>  Anyway @throws would be better than @exception
>
>
A JDK-wide cleanup of @exception => @throws (any many similar things) would
be valuable, but I am not going to try here.


From christos at zoulas.com  Thu Mar 21 18:00:06 2013
From: christos at zoulas.com (Christos Zoulas)
Date: Thu, 21 Mar 2013 14:00:06 -0400
Subject: RFR-8008118
In-Reply-To: 
	from Martin Buchholz (Mar 21, 10:10am)
Message-ID: <20130321180006.C12A397129@rebar.astron.com>

On Mar 21, 10:10am, martinrb at google.com (Martin Buchholz) wrote:
-- Subject: Re: RFR-8008118

| Please revert this formatting change:
| 
| -        for (q = p; (*q != ':') && (*q != '\0'); q++)
| -            ;
| +        for (q = p; (*q != ':') && (*q != '\0'); q++);
| +
| 

Stylistically I prefer:

	    for (q = p; (*q != ':') && (*q != '\0'); q++)
		    continue;

so that re-formatting accidents don't happen, and the intent is clearly
communicated.

christos


From mandy.chung at oracle.com  Thu Mar 21 18:11:11 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 21 Mar 2013 11:11:11 -0700
Subject: RFR (M): 7198429: need checked categorization of caller-sensitive
	methods in the JDK
In-Reply-To: <5149825D.1040608@gmail.com>
References: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com>
	<5149825D.1040608@gmail.com>
Message-ID: <514B4D3F.7040600@oracle.com>

Hi Peter,

On 3/20/2013 2:33 AM, Peter Levart wrote:
> Hi,
>
> If I understand correctly, sun.reflect.Reflection.getCallerClass(int) 
> will not be usable by non-system code any more. I know it's not a 
> public API, but it's useful in some situations (not security-related) 
> and there's no public API for that functionality.
>

Do you have any example of existing use of Reflection.getCallerClass to 
find immediate caller class?  or does it need to walk the stack? That'd 
be useful.

> Is there a reason to not "unofficially" support also classes with @CS 
> annotated methods and which are not loaded by bootstrap or extension 
> class-loader ?

We expect that most of the caller-sensitive cases are in the JDK and 
should be rare for non-system libraries to have caller-sensitive code.  
It'd be good to understand the use cases and the requirements to 
determine the appropriate support for it.

Mandy

>
> Regards, Peter
>
> On 03/15/2013 04:31 AM, Christian Thalinger wrote:
>> [This is the HotSpot part of JEP 176]
>>
>> http://cr.openjdk.java.net/~twisti/7198429
>>
>> 7198429: need checked categorization of caller-sensitive methods in 
>> the JDK
>> Reviewed-by:
>>
>> More information in JEP 176:
>>
>> http://openjdk.java.net/jeps/176
>>
>> src/share/vm/ci/ciMethod.cpp
>> src/share/vm/ci/ciMethod.hpp
>> src/share/vm/classfile/classFileParser.cpp
>> src/share/vm/classfile/classFileParser.hpp
>> src/share/vm/classfile/javaClasses.hpp
>> src/share/vm/classfile/systemDictionary.hpp
>> src/share/vm/classfile/vmSymbols.hpp
>> src/share/vm/oops/method.cpp
>> src/share/vm/oops/method.hpp
>> src/share/vm/opto/library_call.cpp
>> src/share/vm/prims/jvm.cpp
>> src/share/vm/prims/methodHandles.cpp
>> src/share/vm/prims/unsafe.cpp
>> src/share/vm/runtime/vframe.cpp
>> src/share/vm/runtime/vframe.hpp
>>
>



From bourges.laurent at gmail.com  Thu Mar 21 18:25:55 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Thu, 21 Mar 2013 19:25:55 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due to
	HashMap leads to Integer allocations (boxing)
In-Reply-To: <514B3BF8.8090207@gmail.com>
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com>
	
	<514B30B1.2010005@gmail.com> <514B3BF8.8090207@gmail.com>
Message-ID: 

Peter,

My last idea for today:
Consider the object field of the LevelEnum as a mutable field (non final),
JavaLogger initialization can then set its value during its initialization
(j.u.l available).

Doing so, it will avoid any Map.get() in isLoggable(int) to improve
performance as done in my patch.

I will test this solution soon...

My previous message I forgot to send to the mailing list:

my last two cents:
 - I prefer having the object()and forObject() methods in the JavaLogger
class because it reduces the risk to use it elsewhere and it avoids double
indirection: JavaLogger calls these methods that call back JavaLogger to
access its fields ... too obfuscated for me

+
+        // the following two methods are (and should only be) called
from JavaLogger...
+
+        Object object() {
+            return JavaLogger.levelObjects.get(this);
+        }
+
+        static LevelEnum forObject(Object levelObject) {
+            LevelEnum levelEnum = JavaLogger.levelEnums.get(levelObject);
+            return levelEnum == null ? UNKNOWN : levelEnum;
+        }
+    }
- take the opportunity to replace repeated lines in
LoggerProxy.doLog() methods by isLoggable(level):
            if (level < levelValue || levelValue == OFF) {

                return;
            }

Great job anyway,
Cheers,
Laurent



2013/3/21 Peter Levart 

>  Hi Laurent, Mandy,
>
> I think I've got it now. It's a middle-ground. It would be a shame to
> loose the code-reuse (one switch instead of two). So I only moved the
> levelObjects to JavaLogger, not the entire LevelEnum:
>
>
> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.04/index.html
>
> So this is basically similar to original code. It just uses LevelEnum
> instead of java.lang.Integer and EnumMap instead of HashMap. Hopefully
> these perform better. If I moved the LevelEnum into the JavaLogger, I would
> have to re-instate the second switch for LoggerProxy and the solution would
> not be much simpler than your patch, Laurent. This is still just 20 LOC
> more than original code.
>
> Regards, Peter
>
>
> On 03/21/2013 05:09 PM, Peter Levart wrote:
>
> You're right, loggingEnabled can change afterwards. I'll correct the code
> as suggested...
>
> Peter
>
> On 03/21/2013 04:57 PM, Laurent Bourg?s wrote:
>
> Peter,
>
> I am convinced it is better if the LevelEnum belongs to JavaLogger class
> (encapsulated so defered initialization).
>
> Here is a typical scenario:
> 1 - PlatformLogger initialized (not JUL) => LoggerProxy must work so
> LevelEnum can not be used and the former getLevelName() (switch case) is
> required.
> 2 - JUL initialized: calls redirectPlatformLogger() => JavaLoggers created
> => LevelEnum initialized (Level object can be retrieved from LoggingSupport)
>
> For example, JUL can be started programmatically so the loggingEnabled
> flag is not enough to initialize the LevelEnum.object at step 1 and it
> will be null. Then at step 2, LevelEnum.object are null so the JavaLogger
> is broken.
>
> Here is a test of this scenario:
> public static void main(String[] args) {
>
>     final PlatformLogger log = PlatformLogger.getLogger("sun.awt.X11"); //
> 1: LoggerProxy
>
>     if (log.isLoggable(PlatformLogger.INFO)) {
>         log.info("PlatformLogger.INFO: LoggerProxy");
>     }
>
>     final Logger logger = Logger.getLogger("test");
> //   calls PlatformLogger.redirectPlatformLoggers(); // 2 : JavaLogger
>
>     if (log.isLoggable(PlatformLogger.INFO)) {
>         log.info("PlatformLogger.INFO: JavaLogger");
>     }
>
>     logger.info("done");
> }
>
> Laurent
>
> 2013/3/21 Peter Levart 
>
>>  Hi Laurent, Mandy,
>>
>> Let me try one more time (it would be less optimal to have 2 switch
>> statements instead of one). Here's the 3rd webrev:
>>
>>
>> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.03/index.html
>>
>> The changes:
>> - added the comments
>> - made LevelEnum private (to not be tempted to be used from outside the
>> PlatformLogger)
>> - used the loggingEnabled flag as a pre-check when trying to parse the
>> level objects
>>
>>
>> What do you think?
>>
>> Regards, Peter
>>
>>   On 03/21/2013 04:06 PM, Laurent Bourg?s wrote:
>>
>> Thanks Mandy for the clarifications !
>>
>> Peter, I propose to:
>> - move the LevelEnum into the JavaLogger class in order to initialize it
>> as later as possible i.e. after j.u.l calls redirectPlatformLoggers()
>> - only use it in JavaLogger class (private enum) so revert changes to
>> PlatformLogger and LoggerProxy classes
>> - add few comments in the code to explain lazy initialization (see
>> mandy's answer)
>>
>> Finally, could you keep my comment before the switch case (high
>> occurences first) ?
>>
>> +        static LevelEnum forValue(int levelValue) {
>> +            // higher occurences first (finest, fine, finer, info)+            // based on isLoggable(level) calls (03/20/2013) +            // in jdk project only (including generated sources)
>> +            switch (levelValue) {+                case PlatformLogger.FINEST:  return FINEST;  // 116 + 2257 matches in generated files+                case PlatformLogger.FINE:    return FINE;    // 270
>> +                case PlatformLogger.FINER:   return FINER;   // 157+                case PlatformLogger.INFO:    return INFO;    // 39+                case PlatformLogger.WARNING: return WARNING; // 12
>> +                case PlatformLogger.CONFIG:  return CONFIG;  // 6+                case PlatformLogger.SEVERE:  return SEVERE;  // 1+                case PlatformLogger.OFF:     return OFF;     // 0
>> +                case PlatformLogger.ALL:     return ALL;     // 0+                default:                     return UNKNOWN;+            }
>> +        }
>> cheers,
>> Laurent
>>
>>
>> 2013/3/21 Mandy Chung 
>>
>>>  Laurent, Peter,
>>>
>>> I haven't looked at the patch yet.  One thing worths mentioning is that
>>> PlatformLogger was added for the platform code to use so as to avoid the
>>> initialization of java.util.logging since logging is not turned on by
>>> default and that to reduce the startup overhead.   In addition, it also
>>> enables the elimination of the core classes dependency from
>>> java.util.logging for modularization effort.  Therefore the PlatformLogger
>>> only lazily looks up the Level object when java.util.logging is present and
>>> also has been initialized by application code.
>>>
>>> Mandy
>>>
>>>
>>> On 3/21/2013 7:45 AM, Peter Levart wrote:
>>>
>>> On 03/21/2013 03:30 PM, Laurent Bourg?s wrote:
>>>
>>> Peter,
>>>
>>> your solution looks better; I wanted my patch to be simple, efficient
>>> and only modify the JavaLogger class (localized changes).
>>>
>>> In your patch, I have doubts related to lazy and conditional
>>> initialization in JavaLogger (static initialization):
>>>
>>> if (LoggingSupport.isAvailable()) {
>>>     // initialize ...
>>> }
>>>
>>>
>>> In original code, if LoggingSupport.isAvailable() returned false, levelObjects
>>> map remained empty and consequently null was used as the level object
>>> passed to LoggingSupport methods. In LevelEnum I try to keep this logic.
>>> When LevelEnum is first used, it's constants are initialized and level
>>> objects with them. If
>>> LoggingSupport.isAvailable() returns false, level objects are
>>> initialized to null.
>>>
>>> I just noticed there's a bug in initialization of the LevelEnum.UNKNOWN
>>> member constant. It should not try to parse level object. Here's an update:
>>>
>>>
>>> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.02/index.html
>>>
>>> But your concern might be correct. In my code LevelEnum is also used
>>> from the LoggerProxy.format() method (in addition to all the places in
>>> JavaLogger) to obtain the level name for formatting. If this method is
>>> called the first time while LoggingSupport.isAvailable() returns false
>>> and that happens before JavaLogger uses LevelEnum for the first time
>>> (and at that time LoggingSupport.isAvailable() would return true), then
>>> level objects will not be initialized correctly.
>>>
>>> Lazy initialization of level objects might help (for the price of added
>>> complexity)...
>>>
>>> Regards, Peter
>>>
>>>  Does somebody have the knowledge about LoggingSupport.isAvailable()
>>> and the lazy PlatformLogger initialization (JavaLogger are only used when j.u.l is initialized) ?
>>>
>>> What's happening if LoggingSupport.isAvailable() returns false in your patch ? - LevelEnum instances are incorrectly initialized: object field is null !
>>> - PlatformLogger is then broken ... as Level object are required by j.u.l calls
>>> To fix both problems, moving the LevelEnum into JavaLogger should help and check nulls on LevelEnum.object field.
>>>
>>> Thanks for your feedback,Laurent
>>>
>>>  2013/3/21 Peter Levart 
>>>
>>>> On 03/21/2013 12:12 PM, Laurent Bourg?s wrote:
>>>>
>>>>> Here is an improved patch tested on JDK7u13 and JDK8 internal build on
>>>>> my
>>>>>  machine linux x64:
>>>>> http://jmmc.fr/~bourgesl/share/webrev-8010309/
>>>>>
>>>>> FYI, I removed completely the Map levelObjects and
>>>>> used
>>>>> two arrays to perform the PlatformLogger's level (int) to j.u.l.Level
>>>>> mapping:
>>>>>
>>>>> I decided to keep it simple as possible (no enum ...) and used a switch
>>>>> case based on current level occurences:
>>>>>
>>>>
>>>>  Hi Laurent,
>>>>
>>>> In my experience enums are just the right and most compact tool for
>>>> coding such constant associations. Here's a quick try (ripping off your
>>>> optimized switch ;-):
>>>>
>>>>
>>>> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.01/index.html
>>>>
>>>> ...it adds 12 LOC to the original PlatformLogger and is 43 LOC less tha
>>>> your patch. In addition:
>>>>
>>>> - only one switch instead of two (to maintain)
>>>> - no parallel IDX_ constants
>>>>
>>>> What do you think?
>>>>
>>>> Regards, Peter
>>>>
>>>>
>>>>
>>>>>   510         /**
>>>>>   511          * Return the corresponding j.u.l.Level instance
>>>>>   512          * @param level PlatformLogger level as integer
>>>>>   513          * @return Object (j.u.l.Level instance) or null if no
>>>>> matching level
>>>>>   514          */
>>>>>   515         private static Object getLevel(final int level) {
>>>>>   516             if (levelObjects == null) {
>>>>>   517                 return null;
>>>>>   518             }
>>>>>   519             // higher occurences first (finest, fine, finer,
>>>>> info)
>>>>>   520             // based on isLoggable(level) calls (03/20/2013)
>>>>>   521             // in jdk project only (including generated sources)
>>>>>   522             switch (level) {
>>>>>   523                 case FINEST  : return levelObjects[IDX_FINEST];
>>>>> // 116 + 2257 matches in generated files
>>>>>   524                 case FINE    : return levelObjects[IDX_FINE];
>>>>>  // 270
>>>>>   525                 case FINER   : return levelObjects[IDX_FINER];
>>>>> // 157
>>>>>   526                 case INFO    : return levelObjects[IDX_INFO];
>>>>>  // 39
>>>>>   527                 case WARNING : return levelObjects[IDX_WARNING];
>>>>> // 12
>>>>>   528                 case CONFIG  : return levelObjects[IDX_CONFIG];
>>>>>  // 6
>>>>>   529                 case SEVERE  : return levelObjects[IDX_SEVERE];
>>>>>  // 1
>>>>>   530                 case OFF     : return levelObjects[IDX_OFF];
>>>>> // 0
>>>>>   531                 case ALL     : return levelObjects[IDX_ALL];
>>>>> // 0
>>>>>   532                 default      : return null;
>>>>>   533             }
>>>>>   534         }
>>>>>
>>>>> I enhanced the PlatformLoggerTest class also and figured out that TLAB
>>>>> optimized Integer allocations but I think the patch is still useful.
>>>>>
>>>>> Can you have a look to the patch ?
>>>>> Should I write a jtreg test  (performance / GC issue) ?
>>>>>
>>>>> Cheers,
>>>>> Laurent
>>>>>
>>>>>
>>>>> 2013/3/20 Mandy Chung 
>>>>>
>>>>>    Hi Laurent,
>>>>>>
>>>>>> Thank you for signing the OCA.  Your contribution is very welcome.
>>>>>>  You
>>>>>> can submit a patch for this bug (see [1]) to Core libraries group
>>>>>> which
>>>>>> owns logging.  Jim Gish and I will sponsor it.
>>>>>>
>>>>>> Thanks
>>>>>> Mandy
>>>>>> [1] http://openjdk.java.net/contribute/
>>>>>>
>>>>>>
>>>>>> On 3/20/2013 5:45 AM, Laurent Bourg?s wrote:
>>>>>>
>>>>>> Hi mandy,
>>>>>>
>>>>>> Do you want me to propose an improved patch to remove the former Map
>>>>>> and
>>>>>> fix the getLevel() method ? or you prefer fix on your own ?
>>>>>>
>>>>>> Is it better to discuss the fix on the bug database (still not
>>>>>> visible) ?
>>>>>>
>>>>>> Laurent
>>>>>>
>>>>>> 2013/3/19 Mandy Chung 
>>>>>>
>>>>>>    Hi Laurent,
>>>>>>>
>>>>>>> Thanks for the contribution.  I agree that the map can be replaced
>>>>>>> with a
>>>>>>> direct mapping from a int value to Level object and avoid the
>>>>>>> autoboxing
>>>>>>> conversion.
>>>>>>>
>>>>>>> I have filed a bug to track this and target this for JDK8:
>>>>>>>    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id= 8010309
>>>>>>>
>>>>>>> Thanks
>>>>>>> Mandy
>>>>>>>
>>>>>>>
>>>>>>> On 3/19/13 5:19 AM, Laurent Bourg?s wrote:
>>>>>>>
>>>>>>> Dear all,
>>>>>>>
>>>>>>> I run recently netbeans profiler on my swing application (Aspro2:
>>>>>>> http://www.jmmc.fr/aspro
>>>>>>> ) under linux x64 platform and figured out a
>>>>>>> performance and waste issue related to PlatformLogger.
>>>>>>>
>>>>>>> Actually, the JavaLogger implementation uses a Map
>>>>>>> levelObjects to store mapping between PlatformLogger's levels (int)
>>>>>>> and JUL
>>>>>>> Level instances.
>>>>>>>
>>>>>>> However, the isLoggable(int level) method is highly used by awt
>>>>>>> project and
>>>>>>> other JDK projects and it leads to many Integer allocations as
>>>>>>> autoboxing
>>>>>>> converts the level as int to an Integer instance used by the
>>>>>>> Map.get() call.
>>>>>>>
>>>>>>>      /**
>>>>>>>       * JavaLogger forwards all the calls to its corresponding
>>>>>>>       * java.util.logging.Logger object.
>>>>>>>       */
>>>>>>>      static class JavaLogger extends LoggerProxy {
>>>>>>>          private static final* Map* levelObjects =
>>>>>>> new
>>>>>>> HashMap<>();
>>>>>>> ...
>>>>>>>          public boolean isLoggable(*int level*) {
>>>>>>>              return LoggingSupport.isLoggable(javaLogger, *
>>>>>>> levelObjects.get(level)*);
>>>>>>>          }
>>>>>>>      }
>>>>>>>
>>>>>>> I wrote a simple test to illustrate that performance / waste problem:
>>>>>>> PlatformLoggerTest that simply performs 1 million DISABLED log
>>>>>>> statements:
>>>>>>>              if (log.isLoggable(PlatformLogger.FINEST)) {
>>>>>>>                  log.finest("test PlatformLogger.FINEST");
>>>>>>>              }
>>>>>>>
>>>>>>> As you can see in screenshots:
>>>>>>> - 5 million Integer instances are allocated
>>>>>>> - Integer.valueOf(int) is called 5 million times (autoboxing)
>>>>>>> - HashMap.get() represents 30% of the test time
>>>>>>> - patched PlatformLogger is 3x times faster
>>>>>>> [jvm options: -Xms8m -Xmx8m -verbose:gc]
>>>>>>>
>>>>>>> I suggest you to use an alternative way to map PlatformLogger's
>>>>>>> levels
>>>>>>> (int) and JUL Level instances to fix that performance / memory
>>>>>>> issue: I
>>>>>>> added the getLevel(int level) method that performs a switch case to
>>>>>>> return
>>>>>>> the corresponding Level object (quick and dirty solution).
>>>>>>>
>>>>>>> I advocate this is not a very clean solution but I prefer efficiency
>>>>>>> here:
>>>>>>> any better solution may be appropriate to avoid at least Integer
>>>>>>> allocation
>>>>>>> and maybe enhance performance.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Laurent Bourg?s
>>>>>>>
>>>>>>> PS: here is the patch as text:
>>>>>>>
>>>>>>> # This patch file was generated by NetBeans IDE
>>>>>>> # It uses platform neutral UTF-8 encoding and \n newlines.
>>>>>>> --- PlatformLogger.java (6767)
>>>>>>> +++ PlatformLogger.java (6768)
>>>>>>> @@ -468,31 +468,13 @@
>>>>>>>        * java.util.logging.Logger object.
>>>>>>>        */
>>>>>>>       static class JavaLogger extends LoggerProxy {
>>>>>>> -        /** Note: using Integer keys leads to a lot of new Integer
>>>>>>> instances !! */
>>>>>>> -        private static final Map levelObjects = new
>>>>>>> HashMap<>();
>>>>>>> -        /** fastest mapping to Level instances from PlatformLogger
>>>>>>> level
>>>>>>> as integer */
>>>>>>> -        private static final Object[] fastLevelObjects;
>>>>>>> -
>>>>>>> -
>>>>>>> +        private static final Map levelObjects =
>>>>>>> +            new HashMap<>();
>>>>>>> +
>>>>>>>           static {
>>>>>>>               if (LoggingSupport.isAvailable()) {
>>>>>>>                   // initialize the map to Level objects
>>>>>>>                   getLevelObjects();
>>>>>>> -
>>>>>>> -                // initialize the fastLevelObjects:
>>>>>>> -                fastLevelObjects = new Object[] {
>>>>>>> -                    LoggingSupport.parseLevel(getLevelName(OFF)),
>>>>>>>     //
>>>>>>> 0
>>>>>>> -
>>>>>>>  LoggingSupport.parseLevel(getLevelName(SEVERE)),    //
>>>>>>> 1
>>>>>>> -
>>>>>>>  LoggingSupport.parseLevel(getLevelName(WARNING)),   //
>>>>>>> 2
>>>>>>> -                    LoggingSupport.parseLevel(getLevelName(INFO)),
>>>>>>>      //
>>>>>>> 3
>>>>>>> -
>>>>>>>  LoggingSupport.parseLevel(getLevelName(CONFIG)),    //
>>>>>>> 4
>>>>>>> -                    LoggingSupport.parseLevel(getLevelName(FINE)),
>>>>>>>      //
>>>>>>> 5
>>>>>>> -                    LoggingSupport.parseLevel(getLevelName(FINER)),
>>>>>>>     //
>>>>>>> 6
>>>>>>> -
>>>>>>>  LoggingSupport.parseLevel(getLevelName(FINEST)),    //
>>>>>>> 7
>>>>>>> -                    LoggingSupport.parseLevel(getLevelName(ALL))
>>>>>>>      //
>>>>>>> 8
>>>>>>> -                };
>>>>>>> -            } else {
>>>>>>> -                fastLevelObjects = null; // check null
>>>>>>>               }
>>>>>>>           }
>>>>>>>
>>>>>>> @@ -515,7 +497,7 @@
>>>>>>>               this.javaLogger = LoggingSupport.getLogger(name);
>>>>>>>               if (level != 0) {
>>>>>>>                   // level has been updated and so set the Logger's
>>>>>>> level
>>>>>>> -                LoggingSupport.setLevel(javaLogger,
>>>>>>> getLevel(level));
>>>>>>> +                LoggingSupport.setLevel(javaLogger,
>>>>>>> levelObjects.get(level));
>>>>>>>               }
>>>>>>>           }
>>>>>>>
>>>>>>> @@ -526,11 +508,11 @@
>>>>>>>           * not be updated.
>>>>>>>           */
>>>>>>>           void doLog(int level, String msg) {
>>>>>>> -            LoggingSupport.log(javaLogger, getLevel(level), msg);
>>>>>>> +            LoggingSupport.log(javaLogger, levelObjects.get(level),
>>>>>>> msg);
>>>>>>>           }
>>>>>>>
>>>>>>>           void doLog(int level, String msg, Throwable t) {
>>>>>>> -            LoggingSupport.log(javaLogger, getLevel(level), msg, t);
>>>>>>> +            LoggingSupport.log(javaLogger, levelObjects.get(level),
>>>>>>> msg,
>>>>>>> t);
>>>>>>>           }
>>>>>>>
>>>>>>>           void doLog(int level, String msg, Object... params) {
>>>>>>> @@ -544,12 +526,12 @@
>>>>>>>               for (int i = 0; i < len; i++) {
>>>>>>>                   sparams [i] = String.valueOf(params[i]);
>>>>>>>               }
>>>>>>> -            LoggingSupport.log(javaLogger, getLevel(level), msg,
>>>>>>> sparams);
>>>>>>> +            LoggingSupport.log(javaLogger, levelObjects.get(level),
>>>>>>> msg,
>>>>>>> sparams);
>>>>>>>           }
>>>>>>>
>>>>>>>           boolean isEnabled() {
>>>>>>>               Object level = LoggingSupport.getLevel(javaLogger);
>>>>>>> -            return level == null || level.equals(getLevel(OFF)) ==
>>>>>>> false;
>>>>>>> +            return level == null ||
>>>>>>> level.equals(levelObjects.get(OFF)) ==
>>>>>>> false;
>>>>>>>           }
>>>>>>>
>>>>>>>           int getLevel() {
>>>>>>> @@ -566,34 +548,12 @@
>>>>>>>
>>>>>>>           void setLevel(int newLevel) {
>>>>>>>               levelValue = newLevel;
>>>>>>> -            LoggingSupport.setLevel(javaLogger, getLevel(newLevel));
>>>>>>> +            LoggingSupport.setLevel(javaLogger,
>>>>>>> levelObjects.get(newLevel));
>>>>>>>           }
>>>>>>>
>>>>>>>           public boolean isLoggable(int level) {
>>>>>>> -            return LoggingSupport.isLoggable(javaLogger,
>>>>>>> getLevel(level));
>>>>>>> +            return LoggingSupport.isLoggable(javaLogger,
>>>>>>> levelObjects.get(level));
>>>>>>>           }
>>>>>>> -
>>>>>>> -        /**
>>>>>>> -         * Return the corresponding level object (fastest
>>>>>>> implementation)
>>>>>>> -         * @param level PlatformLogger level as primitive integer
>>>>>>> -         * @return Object (JUL Level instance)
>>>>>>> -         */
>>>>>>> -        private static Object getLevel(final int level) {
>>>>>>> -            // higher occurences first (finest, fine, finer, info):
>>>>>>> -            switch (level) {
>>>>>>> -                case FINEST  : return fastLevelObjects[7];
>>>>>>> -                case FINE    : return fastLevelObjects[5];
>>>>>>> -                case FINER   : return fastLevelObjects[6];
>>>>>>> -                case INFO    : return fastLevelObjects[3];
>>>>>>> -                case CONFIG  : return fastLevelObjects[4];
>>>>>>> -                case WARNING : return fastLevelObjects[2];
>>>>>>> -                case SEVERE  : return fastLevelObjects[1];
>>>>>>> -                case ALL     : return fastLevelObjects[8];
>>>>>>> -                case OFF     : return fastLevelObjects[0];
>>>>>>> -                default      : return null;
>>>>>>> -            }
>>>>>>> -        }
>>>>>>> -
>>>>>>>       }
>>>>>>>
>>>>>>>       private static String getLevelName(int level) {
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>


From john.zavgren at oracle.com  Thu Mar 21 18:36:35 2013
From: john.zavgren at oracle.com (John Zavgren)
Date: Thu, 21 Mar 2013 11:36:35 -0700 (PDT)
Subject: RFR-8008118
Message-ID: <68f061c7-bdf1-45d3-b543-6bee2b18f2e4@default>

All:

How does this look?
1.) I reverted the for statement formatting change.
2.) I removed the goto statement and "inlined" some code instead.
3.) I checked to make sure that we're not freeing memory that we didn't actually allocate. (Path vector elements that are empty.)



http://cr.openjdk.java.net/~jzavgren/8008118/webrev.04/

John
----- Original Message -----
From: christos at zoulas.com
To: martinrb at google.com, john.zavgren at oracle.com
Cc: core-libs-dev at openjdk.java.net
Sent: Thursday, March 21, 2013 2:00:10 PM GMT -05:00 US/Canada Eastern
Subject: Re: RFR-8008118

On Mar 21, 10:10am, martinrb at google.com (Martin Buchholz) wrote:
-- Subject: Re: RFR-8008118

| Please revert this formatting change:
| 
| -        for (q = p; (*q != ':') && (*q != '\0'); q++)
| -            ;
| +        for (q = p; (*q != ':') && (*q != '\0'); q++);
| +
| 

Stylistically I prefer:

	    for (q = p; (*q != ':') && (*q != '\0'); q++)
		    continue;

so that re-formatting accidents don't happen, and the intent is clearly
communicated.

christos


From peter.levart at gmail.com  Thu Mar 21 18:47:38 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 21 Mar 2013 19:47:38 +0100
Subject: RFR (M): 7198429: need checked categorization of caller-sensitive
	methods in the JDK
In-Reply-To: <514B4D3F.7040600@oracle.com>
References: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com>
	<5149825D.1040608@gmail.com> <514B4D3F.7040600@oracle.com>
Message-ID: <514B55CA.6040907@gmail.com>

On 03/21/2013 07:11 PM, Mandy Chung wrote:
> Hi Peter,
>
> On 3/20/2013 2:33 AM, Peter Levart wrote:
>> Hi,
>>
>> If I understand correctly, sun.reflect.Reflection.getCallerClass(int) 
>> will not be usable by non-system code any more. I know it's not a 
>> public API, but it's useful in some situations (not security-related) 
>> and there's no public API for that functionality.
>>
>
> Do you have any example of existing use of Reflection.getCallerClass 
> to find immediate caller class?  or does it need to walk the stack? 
> That'd be useful.

I have seen a utility that uses it to establish the context (package and 
ClassLoader) of where to start searching for resources for GUI 
components construction. And a utility that wraps Class.forName(String) 
- specifying Class.forName(name, true, 
Reflection.getCallerClass(2).getClassLoader()) instead to use the 
caller's class loader to load the class...

Usually it is only necessary to get the immediate caller.

>
>> Is there a reason to not "unofficially" support also classes with @CS 
>> annotated methods and which are not loaded by bootstrap or extension 
>> class-loader ?
>
> We expect that most of the caller-sensitive cases are in the JDK and 
> should be rare for non-system libraries to have caller-sensitive 
> code.  It'd be good to understand the use cases and the requirements 
> to determine the appropriate support for it.

Ok, but why limit? Is it an optimization?

Is it for security? For example: one might think that creating an 
anonymous class and holding a j.l.Class reference somewhere safe is 
enough for safety, so the class itself could have public API. Now if an 
untrusted callback object is passed to the code of such class and it is 
invoked from within that code, the anonymous class can get "revealed" to 
the untrusted code which can use it's public API to invoke it. Are there 
any other implications of allowing non-system code to get the caller?

Regards, Peter

>
> Mandy
>
>>
>> Regards, Peter
>>
>> On 03/15/2013 04:31 AM, Christian Thalinger wrote:
>>> [This is the HotSpot part of JEP 176]
>>>
>>> http://cr.openjdk.java.net/~twisti/7198429
>>>
>>> 7198429: need checked categorization of caller-sensitive methods in 
>>> the JDK
>>> Reviewed-by:
>>>
>>> More information in JEP 176:
>>>
>>> http://openjdk.java.net/jeps/176
>>>
>>> src/share/vm/ci/ciMethod.cpp
>>> src/share/vm/ci/ciMethod.hpp
>>> src/share/vm/classfile/classFileParser.cpp
>>> src/share/vm/classfile/classFileParser.hpp
>>> src/share/vm/classfile/javaClasses.hpp
>>> src/share/vm/classfile/systemDictionary.hpp
>>> src/share/vm/classfile/vmSymbols.hpp
>>> src/share/vm/oops/method.cpp
>>> src/share/vm/oops/method.hpp
>>> src/share/vm/opto/library_call.cpp
>>> src/share/vm/prims/jvm.cpp
>>> src/share/vm/prims/methodHandles.cpp
>>> src/share/vm/prims/unsafe.cpp
>>> src/share/vm/runtime/vframe.cpp
>>> src/share/vm/runtime/vframe.hpp
>>>
>>
>



From Alan.Bateman at oracle.com  Thu Mar 21 19:05:29 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 21 Mar 2013 19:05:29 +0000
Subject: RFR-8008118
In-Reply-To: <68f061c7-bdf1-45d3-b543-6bee2b18f2e4@default>
References: <68f061c7-bdf1-45d3-b543-6bee2b18f2e4@default>
Message-ID: <514B59F9.3090109@oracle.com>

On 21/03/2013 18:36, John Zavgren wrote:
> All:
>
> How does this look?
> 1.) I reverted the for statement formatting change.
> 2.) I removed the goto statement and "inlined" some code instead.
> 3.) I checked to make sure that we're not freeing memory that we didn't actually allocate. (Path vector elements that are empty.)
>
>
>
> http://cr.openjdk.java.net/~jzavgren/8008118/webrev.04/
>
> John
>
On line 262 then shouldn't this be pathv[i] = cwd;

The recovery when NEW fails looks right to me although while (--i >= 0) 
{ ... } might be clearer.

-Alan.



From christos at zoulas.com  Thu Mar 21 19:11:47 2013
From: christos at zoulas.com (Christos Zoulas)
Date: Thu, 21 Mar 2013 15:11:47 -0400
Subject: RFR-8008118
In-Reply-To: <68f061c7-bdf1-45d3-b543-6bee2b18f2e4@default>
	from John Zavgren (Mar 21, 11:36am)
Message-ID: <20130321191147.A017197129@rebar.astron.com>

On Mar 21, 11:36am, john.zavgren at oracle.com (John Zavgren) wrote:
-- Subject: Re: RFR-8008118

| All:
| 
| How does this look?
| 1.) I reverted the for statement formatting change.

Not exactly. Now it is indented incorrectly.

| 2.) I removed the goto statement and "inlined" some code instead.

I prefer to write simpler code that works with both signed and unsigned
indexes:

+                while (i > 0) 
+                    if (pathv[--i] != cwd) 
+                        free(pathv[i]); 
+

| 3.) I checked to make sure that we're not freeing memory that we didn't act=
| ually allocate. (Path vector elements that are empty.)

You are still using the "./" string literal constant in the code so you'll
end up freeing it (the compiler will prolly merge the two instances and
you'll get lucky but it is semantically incorrect).

christos


From peter.levart at gmail.com  Thu Mar 21 19:31:45 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 21 Mar 2013 20:31:45 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due
	to HashMap leads to Integer allocations (boxing)
In-Reply-To: 
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com>
	
	<514B30B1.2010005@gmail.com> <514B3BF8.8090207@gmail.com>
	
Message-ID: <514B6021.1070505@gmail.com>

On 03/21/2013 07:25 PM, Laurent Bourg?s wrote:
> Peter,
>
> My last idea for today:
> Consider the object field of the LevelEnum as a mutable field (non 
> final), JavaLogger initialization can then set its value during its 
> initialization (j.u.l available).
>
> Doing so, it will avoid any Map.get() in isLoggable(int) to improve 
> performance as done in my patch.

Good idea. And it's thread-safe too I think, since the static 
initializer HB any instance methods can run and the field is only 
accessed from JavaLogger's instance methods....

Here's the new rev:

http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.05/index.html

I removed the object() and forObject() methods and access the field 
directly. I also renamed it to something more significant. forObject() 
is not necessary, since it only had one call site and I just inlined it. 
I also "took the opportunity". Now we're back to original + 9 LOC ...

Regards, Peter

>
> I will test this solution soon...
>
> My previous message I forgot to send to the mailing list:
>
> my last two cents:
>  - I prefer having theobject()and forObject() methods in the 
> JavaLogger class because it reduces the risk to use it elsewhere and 
> it avoids double indirection: JavaLogger calls these methods that call 
> back JavaLogger to access its fields ... too obfuscated for me
> +
> +        // the following two methods are (and should only be) called from JavaLogger...
> +
> +        Object object() {
>
> +            return JavaLogger.levelObjects.get(this);
> +        }
> +
> +        static LevelEnum forObject(Object levelObject) {
>
> +            LevelEnum levelEnum = JavaLogger.levelEnums.get(levelObject);
> +            return levelEnum == null ? UNKNOWN : levelEnum;
> +        }
>
> +    }
> - take the opportunity to replace repeated lines in LoggerProxy.doLog() methods by isLoggable(level):
>              if (level < levelValue || levelValue == OFF) {
>
>
>                  return;
>              }
> Great job anyway,
> Cheers,
> Laurent
>
>
>
> 2013/3/21 Peter Levart  >
>
>     Hi Laurent, Mandy,
>
>     I think I've got it now. It's a middle-ground. It would be a shame
>     to loose the code-reuse (one switch instead of two). So I only
>     moved the levelObjects to JavaLogger, not the entire LevelEnum:
>
>     http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.04/index.html
>
>     So this is basically similar to original code. It just uses
>     LevelEnum instead of java.lang.Integer and EnumMap instead of
>     HashMap. Hopefully these perform better. If I moved the LevelEnum
>     into the JavaLogger, I would have to re-instate the second switch
>     for LoggerProxy and the solution would not be much simpler than
>     your patch, Laurent. This is still just 20 LOC more than original
>     code.
>
>     Regards, Peter
>
>
>     On 03/21/2013 05:09 PM, Peter Levart wrote:
>>     You're right, loggingEnabled can change afterwards. I'll correct
>>     the code as suggested...
>>
>>     Peter
>>
>>     On 03/21/2013 04:57 PM, Laurent Bourg?s wrote:
>>>     Peter,
>>>
>>>     I am convinced it is better if the LevelEnum belongs to
>>>     JavaLogger class (encapsulated so defered initialization).
>>>
>>>     Here is a typical scenario:
>>>     1 - PlatformLogger initialized (not JUL) => LoggerProxy must
>>>     work so LevelEnum can not be used and the formergetLevelName()
>>>     (switch case) is required.
>>>     2 - JUL initialized: calls redirectPlatformLogger() =>
>>>     JavaLoggers created => LevelEnum initialized (Level object can
>>>     be retrieved from LoggingSupport)
>>>
>>>     For example, JUL can be started programmatically so the
>>>     loggingEnabled flag is not enough to initialize the
>>>     LevelEnum.object at step 1 and it will be null. Then at step 2,
>>>     LevelEnum.object are null so the JavaLogger is broken.
>>>
>>>     Here is a test of this scenario:
>>>     public static void main(String[] args) {
>>>
>>>         final PlatformLogger log =
>>>     PlatformLogger.getLogger("sun.awt.X11"); // 1: LoggerProxy
>>>
>>>         if (log.isLoggable(PlatformLogger.INFO)) {
>>>     log.info ("PlatformLogger.INFO: LoggerProxy");
>>>         }
>>>
>>>         final Logger logger = Logger.getLogger("test");
>>>     //   calls PlatformLogger.redirectPlatformLoggers(); // 2 :
>>>     JavaLogger
>>>
>>>         if (log.isLoggable(PlatformLogger.INFO)) {
>>>     log.info ("PlatformLogger.INFO: JavaLogger");
>>>         }
>>>
>>>     logger.info ("done");
>>>     }
>>>
>>>     Laurent
>>>
>>>     2013/3/21 Peter Levart >>     >
>>>
>>>         Hi Laurent, Mandy,
>>>
>>>         Let me try one more time (it would be less optimal to have 2
>>>         switch statements instead of one). Here's the 3rd webrev:
>>>
>>>         http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.03/index.html
>>>
>>>         The changes:
>>>         - added the comments
>>>         - made LevelEnum private (to not be tempted to be used from
>>>         outside the PlatformLogger)
>>>         - used the loggingEnabled flag as a pre-check when trying to
>>>         parse the level objects
>>>
>>>
>>>         What do you think?
>>>
>>>         Regards, Peter
>>>
>>>         On 03/21/2013 04:06 PM, Laurent Bourg?s wrote:
>>>>         Thanks Mandy for the clarifications !
>>>>
>>>>         Peter, I propose to:
>>>>         - move the LevelEnum into the JavaLogger class in order to
>>>>         initialize it as later as possible i.e. after j.u.l calls
>>>>         redirectPlatformLoggers()
>>>>         - only use it in JavaLogger class (private enum) so revert
>>>>         changes to PlatformLogger and LoggerProxy classes
>>>>         - add few comments in the code to explain lazy
>>>>         initialization (see mandy's answer)
>>>>
>>>>         Finally, could you keep my comment before the switch case
>>>>         (high occurences first) ?
>>>>         +        static LevelEnum forValue(int levelValue) {
>>>>
>>>>         +            // higher occurences first (finest, fine, finer, info)
>>>>         +            // based on isLoggable(level) calls (03/20/2013)
>>>>         +            // in jdk project only (including generated sources)
>>>>
>>>>         +            switch (levelValue) {
>>>>         +                case PlatformLogger.FINEST:  return FINEST;  // 116 + 2257 matches in generated files
>>>>         +                case PlatformLogger.FINE:    return FINE;    // 270
>>>>
>>>>         +                case PlatformLogger.FINER:   return FINER;   // 157
>>>>         +                case PlatformLogger.INFO:    return INFO;    // 39
>>>>         +                case PlatformLogger.WARNING: return WARNING; // 12
>>>>
>>>>         +                case PlatformLogger.CONFIG:  return CONFIG;  // 6
>>>>         +                case PlatformLogger.SEVERE:  return SEVERE;  // 1
>>>>         +                case PlatformLogger.OFF:     return OFF;     // 0
>>>>
>>>>         +                case PlatformLogger.ALL:     return ALL;     // 0
>>>>         +                default:                     return UNKNOWN;
>>>>         +            }
>>>>
>>>>         +        }
>>>>
>>>>         cheers,
>>>>         Laurent
>>>>
>>>>         2013/3/21 Mandy Chung >>>         >
>>>>
>>>>             Laurent, Peter,
>>>>
>>>>             I haven't looked at the patch yet.  One thing worths
>>>>             mentioning is that PlatformLogger was added for the
>>>>             platform code to use so as to avoid the initialization
>>>>             of java.util.logging since logging is not turned on by
>>>>             default and that to reduce the startup overhead. In
>>>>             addition, it also enables the elimination of the core
>>>>             classes dependency from java.util.logging for
>>>>             modularization effort. Therefore the PlatformLogger
>>>>             only lazily looks up the Level object when
>>>>             java.util.logging is present and also has been
>>>>             initialized by application code.
>>>>
>>>>             Mandy
>>>>
>>>>
>>>>             On 3/21/2013 7:45 AM, Peter Levart wrote:
>>>>>             On 03/21/2013 03:30 PM, Laurent Bourg?s wrote:
>>>>>>             Peter,
>>>>>>
>>>>>>             your solution looks better; I wanted my patch to be
>>>>>>             simple, efficient and only modify the JavaLogger
>>>>>>             class (localized changes).
>>>>>>
>>>>>>             In your patch, I have doubts related to lazy and
>>>>>>             conditional initialization in JavaLogger (static
>>>>>>             initialization):
>>>>>>             if (LoggingSupport.isAvailable()) {
>>>>>>                  // initialize ...
>>>>>>             }
>>>>>
>>>>>             In original code, if LoggingSupport.isAvailable()
>>>>>             returned false, levelObjects map remained empty and
>>>>>             consequently null was used as the level object passed
>>>>>             to LoggingSupport methods. In LevelEnum I try to keep
>>>>>             this logic. When LevelEnum is first used, it's
>>>>>             constants are initialized and level objects with them. If
>>>>>             LoggingSupport.isAvailable() returns false, level
>>>>>             objects are initialized to null.
>>>>>
>>>>>             I just noticed there's a bug in initialization of the
>>>>>             LevelEnum.UNKNOWN member constant. It should not try
>>>>>             to parse level object. Here's an update:
>>>>>
>>>>>             http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.02/index.html
>>>>>
>>>>>             But your concern might be correct. In my code
>>>>>             LevelEnum is also used from the LoggerProxy.format()
>>>>>             method (in addition to all the places in JavaLogger)
>>>>>             to obtain the level name for formatting. If this
>>>>>             method is called the first time while
>>>>>             LoggingSupport.isAvailable() returns false and that
>>>>>             happens before JavaLogger uses LevelEnum for the first
>>>>>             time (and at that time LoggingSupport.isAvailable()
>>>>>             would return true), then level objects will not be
>>>>>             initialized correctly.
>>>>>
>>>>>             Lazy initialization of level objects might help (for
>>>>>             the price of added complexity)...
>>>>>
>>>>>             Regards, Peter
>>>>>
>>>>>>             Does somebody have the knowledge about LoggingSupport.isAvailable()
>>>>>>
>>>>>>             and the lazy PlatformLogger initialization (JavaLogger are only used when j.u.l is initialized) ?
>>>>>>
>>>>>>
>>>>>>             What's happening if LoggingSupport.isAvailable() returns false in your patch ?
>>>>>>             - LevelEnum  instances are incorrectly initialized:object field is null !
>>>>>>
>>>>>>             - PlatformLogger is then broken ... as Level object are required by j.u.l calls
>>>>>>
>>>>>>
>>>>>>             To fix both problems, moving theLevelEnum  into JavaLogger should help and check nulls onLevelEnum.object field.
>>>>>>
>>>>>>
>>>>>>             Thanks for your feedback,
>>>>>>             Laurent
>>>>>>
>>>>>>
>>>>>>             2013/3/21 Peter Levart >>>>>             >
>>>>>>
>>>>>>                 On 03/21/2013 12:12 PM, Laurent Bourg?s wrote:
>>>>>>
>>>>>>                     Here is an improved patch tested on JDK7u13
>>>>>>                     and JDK8 internal build on my
>>>>>>                     machine linux x64:
>>>>>>                     http://jmmc.fr/~bourgesl/share/webrev-8010309/ 
>>>>>>
>>>>>>                     FYI, I removed completely the Map>>>>>                     Object> levelObjects and used
>>>>>>                     two arrays to perform the PlatformLogger's
>>>>>>                     level (int) to j.u.l.Level
>>>>>>                     mapping:
>>>>>>
>>>>>>                     I decided to keep it simple as possible (no
>>>>>>                     enum ...) and used a switch
>>>>>>                     case based on current level occurences:
>>>>>>
>>>>>>
>>>>>>                 Hi Laurent,
>>>>>>
>>>>>>                 In my experience enums are just the right and
>>>>>>                 most compact tool for coding such constant
>>>>>>                 associations. Here's a quick try (ripping off
>>>>>>                 your optimized switch ;-):
>>>>>>
>>>>>>                 http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.01/index.html
>>>>>>
>>>>>>                 ...it adds 12 LOC to the original PlatformLogger
>>>>>>                 and is 43 LOC less tha your patch. In addition:
>>>>>>
>>>>>>                 - only one switch instead of two (to maintain)
>>>>>>                 - no parallel IDX_ constants
>>>>>>
>>>>>>                 What do you think?
>>>>>>
>>>>>>                 Regards, Peter
>>>>>>
>>>>>>
>>>>>>
>>>>>>                       510 /**
>>>>>>                       511          * Return the corresponding
>>>>>>                     j.u.l.Level instance
>>>>>>                       512          * @param level PlatformLogger
>>>>>>                     level as integer
>>>>>>                       513          * @return Object (j.u.l.Level
>>>>>>                     instance) or null if no
>>>>>>                     matching level
>>>>>>                       514  */
>>>>>>                       515 private static Object getLevel(final
>>>>>>                     int level) {
>>>>>>                       516   if (levelObjects == null) {
>>>>>>                       517       return null;
>>>>>>                       518   }
>>>>>>                       519   // higher occurences first (finest,
>>>>>>                     fine, finer, info)
>>>>>>                       520   // based on isLoggable(level) calls
>>>>>>                     (03/20/2013)
>>>>>>                       521   // in jdk project only (including
>>>>>>                     generated sources)
>>>>>>                       522   switch (level) {
>>>>>>                       523       case FINEST  : return
>>>>>>                     levelObjects[IDX_FINEST];
>>>>>>                     // 116 + 2257 matches in generated files
>>>>>>                       524       case FINE    : return
>>>>>>                     levelObjects[IDX_FINE];    // 270
>>>>>>                       525       case FINER   : return
>>>>>>                     levelObjects[IDX_FINER];   // 157
>>>>>>                       526       case INFO    : return
>>>>>>                     levelObjects[IDX_INFO];    // 39
>>>>>>                       527       case WARNING : return
>>>>>>                     levelObjects[IDX_WARNING]; // 12
>>>>>>                       528       case CONFIG  : return
>>>>>>                     levelObjects[IDX_CONFIG];  // 6
>>>>>>                       529       case SEVERE  : return
>>>>>>                     levelObjects[IDX_SEVERE];  // 1
>>>>>>                       530       case OFF   : return
>>>>>>                     levelObjects[IDX_OFF];     // 0
>>>>>>                       531       case ALL   : return
>>>>>>                     levelObjects[IDX_ALL];     // 0
>>>>>>                       532       default    : return null;
>>>>>>                       533   }
>>>>>>                       534         }
>>>>>>
>>>>>>                     I enhanced the PlatformLoggerTest class also
>>>>>>                     and figured out that TLAB
>>>>>>                     optimized Integer allocations but I think the
>>>>>>                     patch is still useful.
>>>>>>
>>>>>>                     Can you have a look to the patch ?
>>>>>>                     Should I write a jtreg test  (performance /
>>>>>>                     GC issue) ?
>>>>>>
>>>>>>                     Cheers,
>>>>>>                     Laurent
>>>>>>
>>>>>>
>>>>>>                     2013/3/20 Mandy Chung >>>>>                     >
>>>>>>
>>>>>>                           Hi Laurent,
>>>>>>
>>>>>>                         Thank you for signing the OCA.  Your
>>>>>>                         contribution is very welcome.  You
>>>>>>                         can submit a patch for this bug (see [1])
>>>>>>                         to Core libraries group which
>>>>>>                         owns logging.  Jim Gish and I will
>>>>>>                         sponsor it.
>>>>>>
>>>>>>                         Thanks
>>>>>>                         Mandy
>>>>>>                         [1] http://openjdk.java.net/contribute/
>>>>>>
>>>>>>
>>>>>>                         On 3/20/2013 5:45 AM, Laurent Bourg?s wrote:
>>>>>>
>>>>>>                         Hi mandy,
>>>>>>
>>>>>>                         Do you want me to propose an improved
>>>>>>                         patch to remove the former Map and
>>>>>>                         fix the getLevel() method ? or you prefer
>>>>>>                         fix on your own ?
>>>>>>
>>>>>>                         Is it better to discuss the fix on the
>>>>>>                         bug database (still not visible) ?
>>>>>>
>>>>>>                         Laurent
>>>>>>
>>>>>>                         2013/3/19 Mandy Chung
>>>>>>                         >>>>>                         >
>>>>>>
>>>>>>                               Hi Laurent,
>>>>>>
>>>>>>                             Thanks for the contribution.  I agree
>>>>>>                             that the map can be replaced with a
>>>>>>                             direct mapping from a int value to
>>>>>>                             Level object and avoid the autoboxing
>>>>>>                             conversion.
>>>>>>
>>>>>>                             I have filed a bug to track this and
>>>>>>                             target this for JDK8:
>>>>>>                             http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=
>>>>>>                             8010309
>>>>>>
>>>>>>                             Thanks
>>>>>>                             Mandy
>>>>>>
>>>>>>
>>>>>>                             On 3/19/13 5:19 AM, Laurent Bourg?s
>>>>>>                             wrote:
>>>>>>
>>>>>>                             Dear all,
>>>>>>
>>>>>>                             I run recently netbeans profiler on
>>>>>>                             my swing application
>>>>>>                             (Aspro2:http://www.jmmc.fr/aspro
>>>>>>                             ) under linux x64 platform and
>>>>>>                             figured out a
>>>>>>                             performance and waste issue related
>>>>>>                             to PlatformLogger.
>>>>>>
>>>>>>                             Actually, the JavaLogger
>>>>>>                             implementation uses a Map>>>>>                             Object>
>>>>>>                             levelObjects to store mapping between
>>>>>>                             PlatformLogger's levels (int) and JUL
>>>>>>                             Level instances.
>>>>>>
>>>>>>                             However, the isLoggable(int level)
>>>>>>                             method is highly used by awt project and
>>>>>>                             other JDK projects and it leads to
>>>>>>                             many Integer allocations as autoboxing
>>>>>>                             converts the level as int to an
>>>>>>                             Integer instance used by the
>>>>>>                             Map.get() call.
>>>>>>
>>>>>>                                  /**
>>>>>>                                   * JavaLogger forwards all the
>>>>>>                             calls to its corresponding
>>>>>>                                   * java.util.logging.Logger object.
>>>>>>                                   */
>>>>>>                                  static class JavaLogger extends
>>>>>>                             LoggerProxy {
>>>>>>                              private static final* Map>>>>>                             Object>* levelObjects = new
>>>>>>                             HashMap<>();
>>>>>>                             ...
>>>>>>                              public boolean isLoggable(*int level*) {
>>>>>>                              return
>>>>>>                             LoggingSupport.isLoggable(javaLogger, *
>>>>>>                             levelObjects.get(level)*);
>>>>>>                                      }
>>>>>>                                  }
>>>>>>
>>>>>>                             I wrote a simple test to illustrate
>>>>>>                             that performance / waste problem:
>>>>>>                             PlatformLoggerTest that simply
>>>>>>                             performs 1 million DISABLED log
>>>>>>                             statements:
>>>>>>                              if
>>>>>>                             (log.isLoggable(PlatformLogger.FINEST)) {
>>>>>>                              log.finest("test
>>>>>>                             PlatformLogger.FINEST");
>>>>>>                                          }
>>>>>>
>>>>>>                             As you can see in screenshots:
>>>>>>                             - 5 million Integer instances are
>>>>>>                             allocated
>>>>>>                             - Integer.valueOf(int) is called 5
>>>>>>                             million times (autoboxing)
>>>>>>                             - HashMap.get() represents 30% of the
>>>>>>                             test time
>>>>>>                             - patched PlatformLogger is 3x times
>>>>>>                             faster
>>>>>>                             [jvm options: -Xms8m -Xmx8m -verbose:gc]
>>>>>>
>>>>>>                             I suggest you to use an alternative
>>>>>>                             way to map PlatformLogger's levels
>>>>>>                             (int) and JUL Level instances to fix
>>>>>>                             that performance / memory issue: I
>>>>>>                             added the getLevel(int level) method
>>>>>>                             that performs a switch case to return
>>>>>>                             the corresponding Level object (quick
>>>>>>                             and dirty solution).
>>>>>>
>>>>>>                             I advocate this is not a very clean
>>>>>>                             solution but I prefer efficiency here:
>>>>>>                             any better solution may be
>>>>>>                             appropriate to avoid at least Integer
>>>>>>                             allocation
>>>>>>                             and maybe enhance performance.
>>>>>>
>>>>>>                             Best regards,
>>>>>>                             Laurent Bourg?s
>>>>>>
>>>>>>                             PS: here is the patch as text:
>>>>>>
>>>>>>                             # This patch file was generated by
>>>>>>                             NetBeans IDE
>>>>>>                             # It uses platform neutral UTF-8
>>>>>>                             encoding and \n newlines.
>>>>>>                             --- PlatformLogger.java (6767)
>>>>>>                             +++ PlatformLogger.java (6768)
>>>>>>                             @@ -468,31 +468,13 @@
>>>>>>                                    * java.util.logging.Logger object.
>>>>>>                                    */
>>>>>>                                   static class JavaLogger extends
>>>>>>                             LoggerProxy {
>>>>>>                             -        /** Note: using Integer keys
>>>>>>                             leads to a lot of new Integer
>>>>>>                             instances !! */
>>>>>>                             -  private static final Map>>>>>                             Object> levelObjects = new
>>>>>>                             HashMap<>();
>>>>>>                             -        /** fastest mapping to Level
>>>>>>                             instances from PlatformLogger level
>>>>>>                             as integer */
>>>>>>                             -  private static final Object[]
>>>>>>                             fastLevelObjects;
>>>>>>                             -
>>>>>>                             -
>>>>>>                             +  private static final Map>>>>>                             Object> levelObjects =
>>>>>>                             +  new HashMap<>();
>>>>>>                             +
>>>>>>                             static {
>>>>>>                             if (LoggingSupport.isAvailable()) {
>>>>>>                                 // initialize the map to Level
>>>>>>                             objects
>>>>>>                             getLevelObjects();
>>>>>>                             -
>>>>>>                             -    // initialize the fastLevelObjects:
>>>>>>                             -  fastLevelObjects = new Object[] {
>>>>>>                             -
>>>>>>                              LoggingSupport.parseLevel(getLevelName(OFF)),
>>>>>>                                   //
>>>>>>                             0
>>>>>>                             -
>>>>>>                              LoggingSupport.parseLevel(getLevelName(SEVERE)),
>>>>>>                                //
>>>>>>                             1
>>>>>>                             -
>>>>>>                              LoggingSupport.parseLevel(getLevelName(WARNING)),
>>>>>>                               //
>>>>>>                             2
>>>>>>                             -
>>>>>>                              LoggingSupport.parseLevel(getLevelName(INFO)),
>>>>>>                                  //
>>>>>>                             3
>>>>>>                             -
>>>>>>                              LoggingSupport.parseLevel(getLevelName(CONFIG)),
>>>>>>                                //
>>>>>>                             4
>>>>>>                             -
>>>>>>                              LoggingSupport.parseLevel(getLevelName(FINE)),
>>>>>>                                  //
>>>>>>                             5
>>>>>>                             -
>>>>>>                              LoggingSupport.parseLevel(getLevelName(FINER)),
>>>>>>                                 //
>>>>>>                             6
>>>>>>                             -
>>>>>>                              LoggingSupport.parseLevel(getLevelName(FINEST)),
>>>>>>                                //
>>>>>>                             7
>>>>>>                             -
>>>>>>                              LoggingSupport.parseLevel(getLevelName(ALL))
>>>>>>                                    //
>>>>>>                             8
>>>>>>                             -    };
>>>>>>                             -            } else {
>>>>>>                             -  fastLevelObjects = null; // check null
>>>>>>                             }
>>>>>>                                       }
>>>>>>
>>>>>>                             @@ -515,7 +497,7 @@
>>>>>>                             this.javaLogger =
>>>>>>                             LoggingSupport.getLogger(name);
>>>>>>                             if (level != 0) {
>>>>>>                                 // level has been updated and so
>>>>>>                             set the Logger's level
>>>>>>                             -
>>>>>>                              LoggingSupport.setLevel(javaLogger,
>>>>>>                             getLevel(level));
>>>>>>                             +  LoggingSupport.setLevel(javaLogger,
>>>>>>                             levelObjects.get(level));
>>>>>>                             }
>>>>>>                                       }
>>>>>>
>>>>>>                             @@ -526,11 +508,11 @@
>>>>>>                                       * not be updated.
>>>>>>                                       */
>>>>>>                                       void doLog(int level,
>>>>>>                             String msg) {
>>>>>>                             -  LoggingSupport.log(javaLogger,
>>>>>>                             getLevel(level), msg);
>>>>>>                             +  LoggingSupport.log(javaLogger,
>>>>>>                             levelObjects.get(level), msg);
>>>>>>                                       }
>>>>>>
>>>>>>                                       void doLog(int level,
>>>>>>                             String msg, Throwable t) {
>>>>>>                             -  LoggingSupport.log(javaLogger,
>>>>>>                             getLevel(level), msg, t);
>>>>>>                             +  LoggingSupport.log(javaLogger,
>>>>>>                             levelObjects.get(level), msg,
>>>>>>                             t);
>>>>>>                                       }
>>>>>>
>>>>>>                                       void doLog(int level,
>>>>>>                             String msg, Object... params) {
>>>>>>                             @@ -544,12 +526,12 @@
>>>>>>                             for (int i = 0; i < len; i++) {
>>>>>>                                 sparams [i] =
>>>>>>                             String.valueOf(params[i]);
>>>>>>                             }
>>>>>>                             -  LoggingSupport.log(javaLogger,
>>>>>>                             getLevel(level), msg, sparams);
>>>>>>                             +  LoggingSupport.log(javaLogger,
>>>>>>                             levelObjects.get(level), msg,
>>>>>>                             sparams);
>>>>>>                                       }
>>>>>>
>>>>>>                             boolean isEnabled() {
>>>>>>                             Object level =
>>>>>>                             LoggingSupport.getLevel(javaLogger);
>>>>>>                             -  return level == null ||
>>>>>>                             level.equals(getLevel(OFF)) == false;
>>>>>>                             +  return level == null ||
>>>>>>                             level.equals(levelObjects.get(OFF)) ==
>>>>>>                             false;
>>>>>>                                       }
>>>>>>
>>>>>>                                       int getLevel() {
>>>>>>                             @@ -566,34 +548,12 @@
>>>>>>
>>>>>>                                       void setLevel(int newLevel) {
>>>>>>                             levelValue = newLevel;
>>>>>>                             -
>>>>>>                              LoggingSupport.setLevel(javaLogger,
>>>>>>                             getLevel(newLevel));
>>>>>>                             +  LoggingSupport.setLevel(javaLogger,
>>>>>>                             levelObjects.get(newLevel));
>>>>>>                                       }
>>>>>>
>>>>>>                             public boolean isLoggable(int level) {
>>>>>>                             -  return
>>>>>>                             LoggingSupport.isLoggable(javaLogger,
>>>>>>                             getLevel(level));
>>>>>>                             +  return
>>>>>>                             LoggingSupport.isLoggable(javaLogger,
>>>>>>                             levelObjects.get(level));
>>>>>>                                       }
>>>>>>                             -
>>>>>>                             -        /**
>>>>>>                             -         * Return the corresponding
>>>>>>                             level object (fastest implementation)
>>>>>>                             -         * @param level
>>>>>>                             PlatformLogger level as primitive integer
>>>>>>                             -         * @return Object (JUL Level
>>>>>>                             instance)
>>>>>>                             -         */
>>>>>>                             -  private static Object
>>>>>>                             getLevel(final int level) {
>>>>>>                             -  // higher occurences first
>>>>>>                             (finest, fine, finer, info):
>>>>>>                             -  switch (level) {
>>>>>>                             -    case FINEST  : return
>>>>>>                             fastLevelObjects[7];
>>>>>>                             -    case FINE  : return
>>>>>>                             fastLevelObjects[5];
>>>>>>                             -    case FINER   : return
>>>>>>                             fastLevelObjects[6];
>>>>>>                             -    case INFO  : return
>>>>>>                             fastLevelObjects[3];
>>>>>>                             -    case CONFIG  : return
>>>>>>                             fastLevelObjects[4];
>>>>>>                             -    case WARNING : return
>>>>>>                             fastLevelObjects[2];
>>>>>>                             -    case SEVERE  : return
>>>>>>                             fastLevelObjects[1];
>>>>>>                             -    case ALL   : return
>>>>>>                             fastLevelObjects[8];
>>>>>>                             -    case OFF   : return
>>>>>>                             fastLevelObjects[0];
>>>>>>                             -    default  : return null;
>>>>>>                             -            }
>>>>>>                             -        }
>>>>>>                             -
>>>>>>                                   }
>>>>>>
>>>>>>                                   private static String
>>>>>>                             getLevelName(int level) {
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>



From Alan.Bateman at oracle.com  Thu Mar 21 20:45:32 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 21 Mar 2013 20:45:32 +0000
Subject: Review request 8010416  Addition of Driver.deregisterDriver
In-Reply-To: <1E5BD063-F804-4DAD-858F-3DC0751982BC@oracle.com>
References: <1E5BD063-F804-4DAD-858F-3DC0751982BC@oracle.com>
Message-ID: <514B716C.7070404@oracle.com>

On 21/03/2013 13:36, Lance Andersen - Oracle wrote:
> Need a reviewer for 8010416, addition of Driver.deregisterDriver.
>
> The webrev can be found at  http://cr.openjdk.java.net/~lancea/8010416/webrev.00/.
>
>
If I read this correctly then the intention is that the Driver is 
notified and so that it gets a chance to clean-up when 
DriverManager.deregisterDriver is called to deregister it. I can see 
that being useful but I don't think I understand what "releases any 
resources" means. Does it means that the Driver can no longer be used or 
does it mean that it should only release resources associated with its 
registration with the driver manager?  I think this is distinction is 
important because the former means that that Driver might need to extend 
AutoCloseable and define the behavior for the case that its methods are 
invoked after it has been closed. In addition, I think the default 
method isn't giving you the complete solution because existing drivers 
will continue to "work" after their deregisterDriver is invoked.

The other concern is that Driver.deregisterDriver can be invoked 
directly and this makes it possible for DriverManager to hand out 
Drivers that have their resources released and I don't think this is the 
intention.

I'm also concerned about the default method specifying the 
SecurityException as that requires all drivers to implement this. 
Ideally the permission check is in one place, DriverManager.

So overall I think this one will require a bit more consideration. One 
idea to try is to create AbstractDriver with a protected deregister 
method that is a no-op. Drivers would extend this if they have clean-up 
to do. There may be other solutions, this is just one to try but would 
force Drivers to extend this instead of implementing Driver direction. 
There may be other ideas to try too (I just mention this one). The main 
thing is that all the implications are understood as I think this is a 
tricky one to get right.

-Alan.


From bradford.wetmore at oracle.com  Thu Mar 21 22:12:10 2013
From: bradford.wetmore at oracle.com (Brad Wetmore)
Date: Thu, 21 Mar 2013 15:12:10 -0700
Subject: RFR 8009517: Disable fatal compiler warning in the old build
In-Reply-To: <5147BF89.7000602@oracle.com>
References: <5139E680.6000606@oracle.com>
	
	<513A0A96.7080508@oracle.com> <513A8194.9040002@oracle.com>
	<513AEEBB.2080900@oracle.com> <5147BF89.7000602@oracle.com>
Message-ID: <514B85BA.5000302@oracle.com>

David,

Plugin's integration next week is now also impacted since they also have 
to use the old build environment, so it's time to resolve this.  So 
here's an update/proposal/webrev.

The original bug filed by David Katleman was:

     8009517: build-infra: jdk8: -Werror not being applied to nio builds

and I filed:

     8010434: Old build environment no longer builds.

I've closed mine, and will integrate against the former.

In my partial (JDK) build using the old mechanism and the current TL 
JDK/langtools gate, only two changes are now necessary.

I propose we disable -deprecation in jdk/makejavax/others, and 
-overrides in  make/com/sun/org/apache/xml.

The first *LIKELY* crept in due to a recent change in the Base64 code 
which no longer implicitly compiles sun/misc/CharacterDecoder.java 
without -Werror active.  The original deprecation issue needs to be 
addressed sometime by the responsible team, but that will avoid RE 
having to hand edit to the Makefiles just to build JCE.

The second change is due to the compiler change with hashCode/equals.

The codereview is here:

     http://cr.openjdk.java.net/~wetmore/8009517/webrev.00/

I plan to push through the deploy gate, as they have an integration next 
week.  Thomas Ng will do the push for us.

Any objections, please speak now.

Brad



On 3/18/2013 6:29 PM, Brad Wetmore wrote:
> Sorry for the delay in response, I've been pulled in yet another
> direction, and this has come back up in priority.
>
> On 3/9/2013 12:11 AM, Chris Hegarty wrote:
>>> I agree about warning creeping problems.  This is a temporary solution,
>>> we should soon be fixing the underlying hashcode/equals
>>> problems...but...
>>
>> Your temporary solution, -overrides, is just that. It will enable the
>> old build to complete today, but it could fail at any point in the
>> future, as the code changes.
>
> Correct.  As it stands today, a recent change now requires *BOTH*
> overrides/deprecation in order to get a complete MASTER build using the
> old build system.
>
> [brwetmor at flicker-vm1] 222 >hg diff common/shared/Defs-java.gmk
> diff --git a/make/common/shared/Defs-java.gmk
> b/make/common/shared/Defs-java.gmk
> --- a/make/common/shared/Defs-java.gmk
> +++ b/make/common/shared/Defs-java.gmk
> @@ -127,7 +127,7 @@
>   endif
>
>   # TODO: Workaround for CR 7063027. Remove -path eventually.
> -JAVAC_LINT_OPTIONS += -Xlint:-path
> +JAVAC_LINT_OPTIONS += -Xlint:-path,-overrides,-deprecation
>
>   JAVACFLAGS += $(JAVAC_LINT_OPTIONS)
>
>> For example, java.net is currently warning free, in the old it compiles
>> with fatal warnings enabled. Lets say, in a moment of madness, I add a
>> dependency from java.net.Socket to say java.awt.RenderingHints.Key ( or
>> any class that produces warnings when compiled. I run the new build, all
>> is fine. Push the changes. Now someone else sync's up, but need to build
>> using the old build. If the new dependent class is not already compiled
>> before java.net.Socket gets compiled, it will be compiled implicitly.
>> It's warnings will cause the compile to fail, and the old build will
>> fail. Or much simpler, anyone could write sloppy code with warnings, the
>> new build will suppress them, and they won't notice. Push this code, and
>> the old build will fail if is explicitly, or implicitly, compiles this
>> code with -Werror enabled.
>
> Exactly.  Our formerly clean code now requires disabling of two Lint
> options, but the new build is happy just to report the warning.  The old
> build crashes on the warning.
>
> Our options for the old build system are:
>
> 1.  disable the warning for overrides/deprecation, keep -Werror (my
> preferred since these are minor warnings.)
> 2.  Somehow disable -Werror on these new directories that are now
> failing.  (more work to figure out, but also acceptable)
> 3.  Fix the warnings.  (I don't have cycles to drive a rewrite of use of
> deprecated code and/or add missing equals/hashcode that the recent javac
> changes exposed.)
>
>>>  We
>>> spent a lot of time cleaning up many directories, seems a shame to start
>>> allowing non-fatal warnings to come back into previously clean code
>>> because people aren't taking the time to fix new warnings as they are
>>> introduced.
>>
>> I personally spent several weeks over the past number of years fixing
>> warnings and reviewing warning cleanup webrevs from others. I took much
>> pride in keeping certain areas warnings free.
>>
>> It is with great regret that I propose to disable fatal warnings in the
>> old build, but I felt this the best/safest option. I heard much
>> annoyance and frustration from others about hitting seemingly random
>> errors with the old build recently. This is the only sure way to avoid
>> that.
>>
>>> The new builds will still warn, but the
>>> old builds will still fail for all but these override problems.  Yes,
>>> you lose the warnings in the old, but seems better than completely
>>> shutting off erroring.
>>
>> I'm ok with that, if others are. To clarify, I think you are suggesting
>> that we keep the old build as it, with -overrides,
>
> and now ",-deprecation"  :(
>
>>  and use it
>> periodically as a way of tracking new warnings being introduced into
>> areas that were warning free.
>
> That would be a side-effect, as someone would occasionally need to
> figure out what's changed.
>
> The main issue we're hitting right now is that RE has to make several
> source code changes in order to build JCE jar files without errors.  I
> was able to change the individual LINT options globally and reduce it
> down to one change, but that's still one change that RE has to make.  I
> feel that RE should not be making any changes, but that ship has already
> sailed and we're stuck with the results now.
>
>   That is, if the old build fails because of
>> a fatal warning, so be it. File a bug and fix the source code. Then the
>> old build will work again. This means that at any point in time the old
>> build cannot be guaranteed to be buildable.
>>
>> Everyone seems to agree, a solution needs to be found to allow us to
>> keep certain areas warning free. This issue is too important, and too
>> much time was spent, to allow it to regress to the state it was in a few
>> years ago.
>
> It's already started.
>
> Brad
>
>
>> -Chris.
>>
>>>
>>> (Ideally it would be nice to warn but not fail on just this one lint
>>> option, but don't see how that's possible.)
>>>
>>> Brad
>>>
>>>
>>>
>>>
>>>
>>>> -Chris.
>>>>
>>>>>
>>>>> Mike
>>>>>
>>>>> On Mar 8 2013, at 05:24 , Chris Hegarty wrote:
>>>>>
>>>>>> Since the new build does not enable -Werror when compiling any java
>>>>>> code, and disables quite a few lint options, new changes my
>>>>>> inadvertently introduce warnings without even realizing. This can
>>>>>> cause problems when building with the old build as many areas do
>>>>>> compile with -Werror set. Since the old build is on life support,
>>>>>> probably best to just completely disable -Werror, so anyone still
>>>>>> needing to use it can.
>>>>>>
>>>>>> diff -r 48b7295f02f8 make/common/shared/Defs-java.gmk
>>>>>> --- a/make/common/shared/Defs-java.gmk  Thu Mar 07 10:07:13 2013
>>>>>> +0000
>>>>>> +++ b/make/common/shared/Defs-java.gmk  Thu Mar 07 11:10:37 2013
>>>>>> +0000
>>>>>> @@ -122,9 +122,10 @@ ifeq ($(JAVAC_MAX_WARNINGS), true)
>>>>>> ifeq ($(JAVAC_MAX_WARNINGS), true)
>>>>>>    JAVAC_LINT_OPTIONS += -Xlint:all
>>>>>> endif
>>>>>> -ifeq ($(JAVAC_WARNINGS_FATAL), true)
>>>>>> -  JAVACFLAGS  += -Werror
>>>>>> -endif
>>>>>> +# Disable fatal warnings, 8009517
>>>>>> +#ifeq ($(JAVAC_WARNINGS_FATAL), true)
>>>>>> +#  JAVACFLAGS  += -Werror
>>>>>> +#endif
>>>>>>
>>>>>> # TODO: Workaround for CR 7063027. Remove -path eventually.
>>>>>> JAVAC_LINT_OPTIONS += -Xlint:-path
>>>>>>
>>>>>> -Chris.
>>>>>


From mike.duigou at oracle.com  Thu Mar 21 22:28:56 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 21 Mar 2013 15:28:56 -0700
Subject: RFR 8009517: Disable fatal compiler warning in the old build
In-Reply-To: <514B85BA.5000302@oracle.com>
References: <5139E680.6000606@oracle.com>
	
	<513A0A96.7080508@oracle.com> <513A8194.9040002@oracle.com>
	<513AEEBB.2080900@oracle.com> <5147BF89.7000602@oracle.com>
	<514B85BA.5000302@oracle.com>
Message-ID: <52EFE005-18D9-4FD6-9218-21AFFEBFD5B0@oracle.com>

This looks fine. Get it in before something else changes!

Mike

On Mar 21 2013, at 15:12 , Brad Wetmore wrote:

> David,
> 
> Plugin's integration next week is now also impacted since they also have to use the old build environment, so it's time to resolve this.  So here's an update/proposal/webrev.
> 
> The original bug filed by David Katleman was:
> 
>    8009517: build-infra: jdk8: -Werror not being applied to nio builds
> 
> and I filed:
> 
>    8010434: Old build environment no longer builds.
> 
> I've closed mine, and will integrate against the former.
> 
> In my partial (JDK) build using the old mechanism and the current TL JDK/langtools gate, only two changes are now necessary.
> 
> I propose we disable -deprecation in jdk/makejavax/others, and -overrides in  make/com/sun/org/apache/xml.
> 
> The first *LIKELY* crept in due to a recent change in the Base64 code which no longer implicitly compiles sun/misc/CharacterDecoder.java without -Werror active.  The original deprecation issue needs to be addressed sometime by the responsible team, but that will avoid RE having to hand edit to the Makefiles just to build JCE.
> 
> The second change is due to the compiler change with hashCode/equals.
> 
> The codereview is here:
> 
>    http://cr.openjdk.java.net/~wetmore/8009517/webrev.00/
> 
> I plan to push through the deploy gate, as they have an integration next week.  Thomas Ng will do the push for us.
> 
> Any objections, please speak now.
> 
> Brad
> 
> 
> 
> On 3/18/2013 6:29 PM, Brad Wetmore wrote:
>> Sorry for the delay in response, I've been pulled in yet another
>> direction, and this has come back up in priority.
>> 
>> On 3/9/2013 12:11 AM, Chris Hegarty wrote:
>>>> I agree about warning creeping problems.  This is a temporary solution,
>>>> we should soon be fixing the underlying hashcode/equals
>>>> problems...but...
>>> 
>>> Your temporary solution, -overrides, is just that. It will enable the
>>> old build to complete today, but it could fail at any point in the
>>> future, as the code changes.
>> 
>> Correct.  As it stands today, a recent change now requires *BOTH*
>> overrides/deprecation in order to get a complete MASTER build using the
>> old build system.
>> 
>> [brwetmor at flicker-vm1] 222 >hg diff common/shared/Defs-java.gmk
>> diff --git a/make/common/shared/Defs-java.gmk
>> b/make/common/shared/Defs-java.gmk
>> --- a/make/common/shared/Defs-java.gmk
>> +++ b/make/common/shared/Defs-java.gmk
>> @@ -127,7 +127,7 @@
>>  endif
>> 
>>  # TODO: Workaround for CR 7063027. Remove -path eventually.
>> -JAVAC_LINT_OPTIONS += -Xlint:-path
>> +JAVAC_LINT_OPTIONS += -Xlint:-path,-overrides,-deprecation
>> 
>>  JAVACFLAGS += $(JAVAC_LINT_OPTIONS)
>> 
>>> For example, java.net is currently warning free, in the old it compiles
>>> with fatal warnings enabled. Lets say, in a moment of madness, I add a
>>> dependency from java.net.Socket to say java.awt.RenderingHints.Key ( or
>>> any class that produces warnings when compiled. I run the new build, all
>>> is fine. Push the changes. Now someone else sync's up, but need to build
>>> using the old build. If the new dependent class is not already compiled
>>> before java.net.Socket gets compiled, it will be compiled implicitly.
>>> It's warnings will cause the compile to fail, and the old build will
>>> fail. Or much simpler, anyone could write sloppy code with warnings, the
>>> new build will suppress them, and they won't notice. Push this code, and
>>> the old build will fail if is explicitly, or implicitly, compiles this
>>> code with -Werror enabled.
>> 
>> Exactly.  Our formerly clean code now requires disabling of two Lint
>> options, but the new build is happy just to report the warning.  The old
>> build crashes on the warning.
>> 
>> Our options for the old build system are:
>> 
>> 1.  disable the warning for overrides/deprecation, keep -Werror (my
>> preferred since these are minor warnings.)
>> 2.  Somehow disable -Werror on these new directories that are now
>> failing.  (more work to figure out, but also acceptable)
>> 3.  Fix the warnings.  (I don't have cycles to drive a rewrite of use of
>> deprecated code and/or add missing equals/hashcode that the recent javac
>> changes exposed.)
>> 
>>>> We
>>>> spent a lot of time cleaning up many directories, seems a shame to start
>>>> allowing non-fatal warnings to come back into previously clean code
>>>> because people aren't taking the time to fix new warnings as they are
>>>> introduced.
>>> 
>>> I personally spent several weeks over the past number of years fixing
>>> warnings and reviewing warning cleanup webrevs from others. I took much
>>> pride in keeping certain areas warnings free.
>>> 
>>> It is with great regret that I propose to disable fatal warnings in the
>>> old build, but I felt this the best/safest option. I heard much
>>> annoyance and frustration from others about hitting seemingly random
>>> errors with the old build recently. This is the only sure way to avoid
>>> that.
>>> 
>>>> The new builds will still warn, but the
>>>> old builds will still fail for all but these override problems.  Yes,
>>>> you lose the warnings in the old, but seems better than completely
>>>> shutting off erroring.
>>> 
>>> I'm ok with that, if others are. To clarify, I think you are suggesting
>>> that we keep the old build as it, with -overrides,
>> 
>> and now ",-deprecation"  :(
>> 
>>> and use it
>>> periodically as a way of tracking new warnings being introduced into
>>> areas that were warning free.
>> 
>> That would be a side-effect, as someone would occasionally need to
>> figure out what's changed.
>> 
>> The main issue we're hitting right now is that RE has to make several
>> source code changes in order to build JCE jar files without errors.  I
>> was able to change the individual LINT options globally and reduce it
>> down to one change, but that's still one change that RE has to make.  I
>> feel that RE should not be making any changes, but that ship has already
>> sailed and we're stuck with the results now.
>> 
>>  That is, if the old build fails because of
>>> a fatal warning, so be it. File a bug and fix the source code. Then the
>>> old build will work again. This means that at any point in time the old
>>> build cannot be guaranteed to be buildable.
>>> 
>>> Everyone seems to agree, a solution needs to be found to allow us to
>>> keep certain areas warning free. This issue is too important, and too
>>> much time was spent, to allow it to regress to the state it was in a few
>>> years ago.
>> 
>> It's already started.
>> 
>> Brad
>> 
>> 
>>> -Chris.
>>> 
>>>> 
>>>> (Ideally it would be nice to warn but not fail on just this one lint
>>>> option, but don't see how that's possible.)
>>>> 
>>>> Brad
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> -Chris.
>>>>> 
>>>>>> 
>>>>>> Mike
>>>>>> 
>>>>>> On Mar 8 2013, at 05:24 , Chris Hegarty wrote:
>>>>>> 
>>>>>>> Since the new build does not enable -Werror when compiling any java
>>>>>>> code, and disables quite a few lint options, new changes my
>>>>>>> inadvertently introduce warnings without even realizing. This can
>>>>>>> cause problems when building with the old build as many areas do
>>>>>>> compile with -Werror set. Since the old build is on life support,
>>>>>>> probably best to just completely disable -Werror, so anyone still
>>>>>>> needing to use it can.
>>>>>>> 
>>>>>>> diff -r 48b7295f02f8 make/common/shared/Defs-java.gmk
>>>>>>> --- a/make/common/shared/Defs-java.gmk  Thu Mar 07 10:07:13 2013
>>>>>>> +0000
>>>>>>> +++ b/make/common/shared/Defs-java.gmk  Thu Mar 07 11:10:37 2013
>>>>>>> +0000
>>>>>>> @@ -122,9 +122,10 @@ ifeq ($(JAVAC_MAX_WARNINGS), true)
>>>>>>> ifeq ($(JAVAC_MAX_WARNINGS), true)
>>>>>>>   JAVAC_LINT_OPTIONS += -Xlint:all
>>>>>>> endif
>>>>>>> -ifeq ($(JAVAC_WARNINGS_FATAL), true)
>>>>>>> -  JAVACFLAGS  += -Werror
>>>>>>> -endif
>>>>>>> +# Disable fatal warnings, 8009517
>>>>>>> +#ifeq ($(JAVAC_WARNINGS_FATAL), true)
>>>>>>> +#  JAVACFLAGS  += -Werror
>>>>>>> +#endif
>>>>>>> 
>>>>>>> # TODO: Workaround for CR 7063027. Remove -path eventually.
>>>>>>> JAVAC_LINT_OPTIONS += -Xlint:-path
>>>>>>> 
>>>>>>> -Chris.
>>>>>> 



From mandy.chung at oracle.com  Thu Mar 21 23:07:19 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 21 Mar 2013 16:07:19 -0700
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due
	to HashMap leads to Integer allocations (boxing)
In-Reply-To: <514B2E8D.8060701@gmail.com>
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com> <514B2E8D.8060701@gmail.com>
Message-ID: <514B92A7.1000305@oracle.com>

Hi Peter, Laurent,

Good work and I like the solution.

On 3/21/13 9:00 AM, Peter Levart wrote:
>
> Hi Mandy,
>
> JavaLogger and LoggerProxy are only used from within PlatformLogger. 
> Wouldn't it be better to declare them private? Their usage (one or the 
> other) depends on the 'loggingSupport' flag that is initialized with 
> PlatformLogger class. Usage of JavaLogger or LoggerProxy outside 
> PlatformLogger would be wrong, I think.

Yes JavaLogger and LoggerProxy classes can be made private.

> Here's the new rev:
>
> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.05/index.html
>
> I removed the object() and forObject() methods and access the field 
> directly. I also renamed it to something more significant. forObject() 
> is not necessary, since it only had one call site and I just inlined 
> it. I also "took the opportunity". Now we're back to original + 9 LOC ...

I looked at it but not in great detail.  In general it's very good clean 
up.   The comment in line 124-132 is good information and since the code 
is evolving, I would suggest to take those count out.

valueOf is one common method name to find an instance of a given value.  
Perhaps LevelEnum.forValue can be renamed to LevelEnum.valueOf(int)?  It 
seems to be useful to add a static method LevelEnum.getLevel(int) to 
replace the calls to "LevelEnum.forValue(newLevel).julLevel".

The tests are in jdk/test/java/util/logging and 
jdk/test/sun/util/logging.  It'd be good to check if you want to extend 
jdk/test/sun/util/logging/PlatformLoggerTest.java to cover all levels 
(it's currently already checking several).

Thanks
Mandy


From alexey.utkin at oracle.com  Fri Mar 22 07:06:43 2013
From: alexey.utkin at oracle.com (Alexey Utkin)
Date: Fri, 22 Mar 2013 11:06:43 +0400
Subject: FYI: Fastest UFT-8 -> UNICODE converter as state machine.
Message-ID: <514C0303.9040205@oracle.com>

http://bjoern.hoehrmann.de/utf-8/decoder/dfa/
Verified on full UNICODE set.

Regards,
-uta


From Alan.Bateman at oracle.com  Fri Mar 22 08:34:23 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 22 Mar 2013 08:34:23 +0000
Subject: RFR 8009517: Disable fatal compiler warning in the old build
In-Reply-To: <514B85BA.5000302@oracle.com>
References: <5139E680.6000606@oracle.com>
	
	<513A0A96.7080508@oracle.com> <513A8194.9040002@oracle.com>
	<513AEEBB.2080900@oracle.com> <5147BF89.7000602@oracle.com>
	<514B85BA.5000302@oracle.com>
Message-ID: <514C178F.4000401@oracle.com>

On 21/03/2013 22:12, Brad Wetmore wrote:
> :
>
> The codereview is here:
>
>     http://cr.openjdk.java.net/~wetmore/8009517/webrev.00/
>
> I plan to push through the deploy gate, as they have an integration 
> next week.  Thomas Ng will do the push for us.
>
> Any objections, please speak now.
No objection here but just to mention that since you need to set 
NEWBUILD=false then it might not be too much extra to also set 
JAVAC_WARNINGS_FATAL=false.

In any case, I think it would be desirable if there was a retirement 
date set for the old build so that the remaining users (I assume very 
few at this point) have something to aim for.

-Alan.


From bourges.laurent at gmail.com  Fri Mar 22 09:05:51 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Fri, 22 Mar 2013 10:05:51 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due to
	HashMap leads to Integer allocations (boxing)
In-Reply-To: <514B92A7.1000305@oracle.com>
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com> <514B2E8D.8060701@gmail.com>
	<514B92A7.1000305@oracle.com>
Message-ID: 

Hi Mandy & Peter,

Here is an update patch applying mandy's suggestions:
http://jmmc.fr/~bourgesl/share/webrev-2-8010309/

Good work and I like the solution.
>
Thanks.


>  JavaLogger and LoggerProxy are only used from within PlatformLogger.
> Wouldn't it be better to declare them private? Their usage (one or the
> other) depends on the 'loggingSupport' flag that is initialized with
> PlatformLogger class. Usage of JavaLogger or LoggerProxy outside
> PlatformLogger would be wrong, I think.
>
>
> Yes JavaLogger and LoggerProxy classes can be made private.
>

Done.

 I looked at it but not in great detail.  In general it's very good clean
> up.   The comment in line 124-132 is good information and since the code is
> evolving, I would suggest to take those count out.
>

Fixed.


> valueOf is one common method name to find an instance of a given value.
> Perhaps LevelEnum.forValue can be renamed to LevelEnum.valueOf(int)?
>

Done.


> It seems to be useful to add a static method LevelEnum.getLevel(int) to
> replace the calls to "LevelEnum.forValue(newLevel).julLevel".
>

I agree I prefer using methods (field encapsulation) so I added:

+        /**
+         * java.util.logging.Level optionally initialized in
JavaLogger's static initializer
+         * and USED ONLY IN JavaLogger (only once java.util.logging
is available and enabled)
+         */
+        private Object julLevel;
+
+        void setJulLevel(Object julLevel) {
+            this.julLevel = julLevel;
+        }
+
+        Object getJulLevel() {
+            return this.julLevel;
+        }
+
+        /**
+         * Return the java.util.logging.Level used only in JavaLogger
+         * @param levelValue PlatformLogger level as int
+         * @return java.util.logging.Level or null if
java.util.logging is not available and disabled
+         */
+        static Object getJulLevel(int levelValue) {
+            return valueOf(levelValue).getJulLevel();
+        }

The tests are in jdk/test/java/util/logging and jdk/test/sun/util/logging.
> It'd be good to check if you want to extend
> jdk/test/sun/util/logging/PlatformLoggerTest.java to cover all levels (it's
> currently already checking several).
>

I will now have a look ...

Regards,
Laurent


From peter.levart at gmail.com  Fri Mar 22 10:04:04 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 22 Mar 2013 11:04:04 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due
	to HashMap leads to Integer allocations (boxing)
In-Reply-To: 
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com> <514B2E8D.8060701@gmail.com>
	<514B92A7.1000305@oracle.com>
	
Message-ID: <514C2C94.60700@gmail.com>

On 03/22/2013 10:05 AM, Laurent Bourg?s wrote:
> Hi Mandy & Peter,
>
> Here is an update patch applying mandy's suggestions:
> http://jmmc.fr/~bourgesl/share/webrev-2-8010309/ 
> 
>

You've beaten me! I have been preparing them too ;-) ...

https://dl.dropboxusercontent.com/u/101777488/jdk8-tl/PlatformLogger/webrev.06/index.html

I also did some some renames, that I think make the code more consistent:
- LevelEnum -> Level (the code is not dependent on 
java.util.logging.Level, so the name can be reused, its private anyway)
- julLevel -> javaLevel (javaLevel / JavaLogger)
- LevelEnum.forValue -> Level.valueOf (Mandy)
- JavaLogger.julLevelToEnum -> JavaLogger.javaLevelToLevel

Other changes (to webrev.05):
- removed the occurrence counts in switch comments (as per Mandy's 
suggestion)
- made LoggerProxy and JavaLogger private
- fixed double-read of volatile LoggerProxy.levelValue in 
LoggerProxy.isLoggable()
- added static Level.javaLevel(int value) shortcut (Mandy)

I also updated the test to exercise the correctness of mappings.

Have I forgotten something?


Regards, Peter

>     Good work and I like the solution.
>
> Thanks.
>
>>     JavaLogger and LoggerProxy are only used from within
>>     PlatformLogger. Wouldn't it be better to declare them private?
>>     Their usage (one or the other) depends on the 'loggingSupport'
>>     flag that is initialized with PlatformLogger class. Usage of
>>     JavaLogger or LoggerProxy outside PlatformLogger would be wrong,
>>     I think.
>
>     Yes JavaLogger and LoggerProxy classes can be made private.
>
>
> Done.
>
>     I looked at it but not in great detail.  In general it's very good
>     clean up.   The comment in line 124-132 is good information and
>     since the code is evolving, I would suggest to take those count out.
>
>
> Fixed.
>
>     valueOf is one common method name to find an instance of a given
>     value.  Perhaps LevelEnum.forValue can be renamed to
>     LevelEnum.valueOf(int)?
>
>
> Done.
>
>     It seems to be useful to add a static method
>     LevelEnum.getLevel(int) to replace the calls to
>     "LevelEnum.forValue(newLevel).julLevel".
>
>
> I agree I prefer using methods (field encapsulation) so I added:
> +        /**
> +         * java.util.logging.Level optionally initialized in JavaLogger's static initializer
>
> +         * and USED ONLY IN JavaLogger (only once java.util.logging is available and enabled)
> +         */
> +        private Object julLevel;
>
> +
> +        void setJulLevel(Object julLevel) {
> +            this.julLevel = julLevel;
> +        }
> +
>
> +        Object getJulLevel() {
> +            return this.julLevel;
> +        }
> +
> +        /**
>
> +         * Return the java.util.logging.Level used only in JavaLogger
> +         * @param levelValue PlatformLogger level as int
> +         * @return java.util.logging.Level or null if java.util.logging is not available and disabled
>
> +         */
> +        static Object getJulLevel(int levelValue) {
> +            return valueOf(levelValue).getJulLevel();
> +        }
>
>
>     The tests are in jdk/test/java/util/logging and
>     jdk/test/sun/util/logging. It'd be good to check if you want to
>     extend jdk/test/sun/util/logging/PlatformLoggerTest.java to cover
>     all levels (it's currently already checking several).
>
>
> I will now have a look ...
>
> Regards,
> Laurent
>



From bourges.laurent at gmail.com  Fri Mar 22 10:34:57 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Fri, 22 Mar 2013 11:34:57 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due to
	HashMap leads to Integer allocations (boxing)
In-Reply-To: <514C2C94.60700@gmail.com>
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com> <514B2E8D.8060701@gmail.com>
	<514B92A7.1000305@oracle.com>
	
	<514C2C94.60700@gmail.com>
Message-ID: 

Peter,

You've beaten me! I have been preparing them too ;-) ...
>

Ok I definitely stop working on the code and let you do it.


> I also did some some renames, that I think make the code more consistent:
> - LevelEnum -> Level (the code is not dependent on
> java.util.logging.Level, so the name can be reused, its private anyway)
> - julLevel -> javaLevel (javaLevel / JavaLogger)
> - LevelEnum.forValue -> Level.valueOf (Mandy)
> - JavaLogger.julLevelToEnum -> JavaLogger.javaLevelToLevel
>

For consistency and clarity, I would prefer having following conventions:
- int levelValue (= PlatformLevel as int) and not int level (conflict with
Level enum ...)
- julLevel / julLogger: more explicit than javaLevel / javaLogger (java
means everything  ... but jul means java.util.logging and javaLogger is in
conflict with JavaLogger class)

Other changes (to webrev.05):
> - removed the occurrence counts in switch comments (as per Mandy's
> suggestion)
> - made LoggerProxy and JavaLogger private
> - fixed double-read of volatile LoggerProxy.levelValue in
> LoggerProxy.isLoggable()
> - added static Level.javaLevel(int value) shortcut (Mandy)
>
> I also updated the test to exercise the correctness of mappings.
>

Well done.

cheers,
Laurent


From weijun.wang at oracle.com  Fri Mar 22 12:05:58 2013
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Fri, 22 Mar 2013 12:05:58 +0000
Subject: hg: jdk8/tl/jdk: 8010531: Add BadKdc* tests to problem list for
	solaris-sparcv9
Message-ID: <20130322120610.2CBEA48337@hg.openjdk.java.net>

Changeset: 93cd7052d306
Author:    weijun
Date:      2013-03-22 19:59 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/93cd7052d306

8010531: Add BadKdc* tests to problem list for solaris-sparcv9
Reviewed-by: alanb

! test/ProblemList.txt



From peter.levart at gmail.com  Fri Mar 22 12:26:49 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 22 Mar 2013 13:26:49 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due
	to HashMap leads to Integer allocations (boxing)
In-Reply-To: 
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com> <514B2E8D.8060701@gmail.com>
	<514B92A7.1000305@oracle.com>
	
	<514C2C94.60700@gmail.com>
	
Message-ID: <514C4E09.3020008@gmail.com>

On 03/22/2013 11:34 AM, Laurent Bourg?s wrote:
> Peter,
>
>     You've beaten me! I have been preparing them too ;-) ...
>
>
> Ok I definitely stop working on the code and let you do it.

Ok. I'll make the final touches, incorporating also comments and changes 
from your code...

>
>     I also did some some renames, that I think make the code more
>     consistent:
>     - LevelEnum -> Level (the code is not dependent on
>     java.util.logging.Level, so the name can be reused, its private
>     anyway)
>     - julLevel -> javaLevel (javaLevel / JavaLogger)
>     - LevelEnum.forValue -> Level.valueOf (Mandy)
>     - JavaLogger.julLevelToEnum -> JavaLogger.javaLevelToLevel
>
>
> For consistency and clarity, I would prefer having following conventions:
> - int levelValue (= PlatformLevel as int) and not int level (conflict 
> with Level enum ...)

I think that PlatformLogger public API should stay as is. Public 
method's parameter names are just called 'level' and values of public 
constants are expected to be passed to them. There are only two places 
where 'level' is the name of a local variable of type Level (and not 
int) and at both places there is not conflict, since there's no 'int 
level' variable in scope.

I renamed LevelEnum to Level because the following most frequently used 
pattern looks strange:

     LevelEnum.javaLevel(int)

Neither parameter nor the result has anything to do with LevelEnum directly.

But if we move the javaLevel(int) method out of the Level enum into the 
JavaLogger, then Level can be renamed back to LevelEnum (or anything else?).


> - julLevel / julLogger: more explicit than javaLevel / javaLogger 
> (java means everything  ... but jul means java.util.logging and 
> javaLogger is in conflict with JavaLogger class)


But javaLogger is not in conflict with javaLevel. I suggest renaming 
JavaLoger class to JavaLoggerProxy, so we would have:

Object javaLogger // holding java.util.logging.Logger instance
Object javaLevel    // holding java.util.logging.Level instance

class JavaLoggerProxy  // a specialization of LoggerProxy, delegating to 
javaLogger

If 'jul' is a prefered prefix to 'java', I suggest renaming all 3: 
julLogger, julLevel, JulLoggerProxy. I don't have a preference for 
either, so perhaps Mandy, Laurent or anybody else can express them...


Regards, Peter

>
>     Other changes (to webrev.05):
>     - removed the occurrence counts in switch comments (as per Mandy's
>     suggestion)
>     - made LoggerProxy and JavaLogger private
>     - fixed double-read of volatile LoggerProxy.levelValue in
>     LoggerProxy.isLoggable()
>     - added static Level.javaLevel(int value) shortcut (Mandy)
>
>     I also updated the test to exercise the correctness of mappings.
>
>
> Well done.
>
> cheers,
> Laurent
>



From maurizio.cimadamore at oracle.com  Fri Mar 22 12:45:45 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Fri, 22 Mar 2013 12:45:45 +0000
Subject: hg: jdk8/tl/langtools: 5 new changesets
Message-ID: <20130322124559.BDE3D48338@hg.openjdk.java.net>

Changeset: cc38a6723663
Author:    mcimadamore
Date:      2013-03-22 12:38 +0000
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cc38a6723663

8009649: Lambda back-end should generate invokespecial for method handles referring to private instance methods
Summary: Private lambda methods should be accessed through invokespecial
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
+ test/tools/javac/lambda/bytecode/TestLambdaBytecode.java

Changeset: f3814edefb33
Author:    mcimadamore
Date:      2013-03-22 12:39 +0000
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f3814edefb33

8010101: Intersection type cast issues redundant unchecked warning
Summary: Code for checking intersection type cast is incorrectly swapping operands, leading to spurious warnings
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/lambda/Intersection02.java
+ test/tools/javac/lambda/Intersection02.out

Changeset: b6cf07c54c29
Author:    mcimadamore
Date:      2013-03-22 12:41 +0000
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b6cf07c54c29

8009820: AssertionError when compiling java code with two identical static imports
Summary: Speculative attribution is carried out twice with same method symbol in case of static imports
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
+ test/tools/javac/lambda/DoubleStaticImport.java

Changeset: c6728c9addff
Author:    mcimadamore
Date:      2013-03-22 12:43 +0000
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c6728c9addff

8010303: Graph inference: missing incorporation step causes spurious inference error
Summary: Multiple equality constraints on inference vars are not used to generate new inference constraints
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! test/tools/javac/lambda/TargetType28.out
+ test/tools/javac/lambda/TargetType67.java
+ test/tools/javac/lambda/TargetType68.java
+ test/tools/javac/lambda/TargetType69.java

Changeset: 5da12e8a59ba
Author:    mcimadamore
Date:      2013-03-22 12:44 +0000
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5da12e8a59ba

8010387: Javac crashes when diagnostic mentions anonymous inner class' type variables
Summary: Rich formatter doesn't preprocess supertypes of an anonymous inner class
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
+ test/tools/javac/Diagnostics/8010387/T8010387.java
+ test/tools/javac/Diagnostics/8010387/T8010387.out



From mark.sheppard at oracle.com  Fri Mar 22 12:52:33 2013
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Fri, 22 Mar 2013 12:52:33 +0000
Subject: RFR-8008118
In-Reply-To: <68f061c7-bdf1-45d3-b543-6bee2b18f2e4@default>
References: <68f061c7-bdf1-45d3-b543-6bee2b18f2e4@default>
Message-ID: <514C5411.60308@oracle.com>

Hi John,
    in the cleanup, would it be necessary to free the allocated pathv 
array also, prior to return?
if I'm not misreading.

Also, rather than storing the pointer to the string literal, malloc 
(NEW) and memcpy as per the other entries.
This will avoid potential conflict should other code attempt to release 
the pathv, which would be unaware
of it containing the string literal. (Who cleans up pathv after it has 
been used?)

regards
Mark
On 21/03/2013 18:36, John Zavgren wrote:
> All:
>
> How does this look?
> 1.) I reverted the for statement formatting change.
> 2.) I removed the goto statement and "inlined" some code instead.
> 3.) I checked to make sure that we're not freeing memory that we didn't actually allocate. (Path vector elements that are empty.)
>
>
>
> http://cr.openjdk.java.net/~jzavgren/8008118/webrev.04/
>
> John
> ----- Original Message -----
> From: christos at zoulas.com
> To: martinrb at google.com, john.zavgren at oracle.com
> Cc: core-libs-dev at openjdk.java.net
> Sent: Thursday, March 21, 2013 2:00:10 PM GMT -05:00 US/Canada Eastern
> Subject: Re: RFR-8008118
>
> On Mar 21, 10:10am, martinrb at google.com (Martin Buchholz) wrote:
> -- Subject: Re: RFR-8008118
>
> | Please revert this formatting change:
> |
> | -        for (q = p; (*q != ':') && (*q != '\0'); q++)
> | -            ;
> | +        for (q = p; (*q != ':') && (*q != '\0'); q++);
> | +
> |
>
> Stylistically I prefer:
>
> 	    for (q = p; (*q != ':') && (*q != '\0'); q++)
> 		    continue;
>
> so that re-formatting accidents don't happen, and the intent is clearly
> communicated.
>
> christos



From peter.levart at gmail.com  Fri Mar 22 13:28:45 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 22 Mar 2013 14:28:45 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due
	to HashMap leads to Integer allocations (boxing)
In-Reply-To: <514C4E09.3020008@gmail.com>
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com> <514B2E8D.8060701@gmail.com>
	<514B92A7.1000305@oracle.com>
	
	<514C2C94.60700@gmail.com>
	
	<514C4E09.3020008@gmail.com>
Message-ID: <514C5C8D.1090406@gmail.com>

Ok, Lauret, Mandy,

Here are the final touches:

https://dl.dropboxusercontent.com/u/101777488/jdk8-tl/PlatformLogger/webrev.07/index.html

Changes from webrev.06:

- renamed back Level -> LevelEnum
- renamed JavaLogger -> JavaLoggerProxy
- moved javaLevel(int) static method from LevelEnum to JavaLoggerProxy 
and made it private (only used there)
- consistent use of variable name 'level' to refer to PlatformLogger's 
int level value
- consistent use of variable name 'levelEnum' to refer to LevelEnum member
- consistent use of variable name 'javaLevel' to refer to 
java.util.logging.Level instance
- consistent use of variable name 'javaLogger' to refer to 
java.util.logging.Logger instance
- renamed PlatformLogger.newJavaLogger() private method -> 
PlatformLogger.redirectToJavaLoggerProxy()
- renamed PlatformLogger.logger private field -> PlatformLogger.loggerProxy
- some additional comments

I think that these changes make code more consistent and self-explanatory.

What remains is a possible rename from: javaLogger, javaLevel, 
JavaLoggerProxy -> julLogger, julLevel, JulLoggerProxy if that's the 
final decision.

Regards, Peter


On 03/22/2013 01:26 PM, Peter Levart wrote:
> On 03/22/2013 11:34 AM, Laurent Bourg?s wrote:
>> Peter,
>>
>>     You've beaten me! I have been preparing them too ;-) ...
>>
>>
>> Ok I definitely stop working on the code and let you do it.
>
> Ok. I'll make the final touches, incorporating also comments and 
> changes from your code...
>
>>
>>     I also did some some renames, that I think make the code more
>>     consistent:
>>     - LevelEnum -> Level (the code is not dependent on
>>     java.util.logging.Level, so the name can be reused, its private
>>     anyway)
>>     - julLevel -> javaLevel (javaLevel / JavaLogger)
>>     - LevelEnum.forValue -> Level.valueOf (Mandy)
>>     - JavaLogger.julLevelToEnum -> JavaLogger.javaLevelToLevel
>>
>>
>> For consistency and clarity, I would prefer having following conventions:
>> - int levelValue (= PlatformLevel as int) and not int level (conflict 
>> with Level enum ...)
>
> I think that PlatformLogger public API should stay as is. Public 
> method's parameter names are just called 'level' and values of public 
> constants are expected to be passed to them. There are only two places 
> where 'level' is the name of a local variable of type Level (and not 
> int) and at both places there is not conflict, since there's no 'int 
> level' variable in scope.
>
> I renamed LevelEnum to Level because the following most frequently 
> used pattern looks strange:
>
>     LevelEnum.javaLevel(int)
>
> Neither parameter nor the result has anything to do with LevelEnum 
> directly.
>
> But if we move the javaLevel(int) method out of the Level enum into 
> the JavaLogger, then Level can be renamed back to LevelEnum (or 
> anything else?).
>
>
>> - julLevel / julLogger: more explicit than javaLevel / javaLogger 
>> (java means everything  ... but jul means java.util.logging and 
>> javaLogger is in conflict with JavaLogger class)
>
>
> But javaLogger is not in conflict with javaLevel. I suggest renaming 
> JavaLoger class to JavaLoggerProxy, so we would have:
>
> Object javaLogger // holding java.util.logging.Logger instance
> Object javaLevel    // holding java.util.logging.Level instance
>
> class JavaLoggerProxy  // a specialization of LoggerProxy, delegating 
> to javaLogger
>
> If 'jul' is a prefered prefix to 'java', I suggest renaming all 3: 
> julLogger, julLevel, JulLoggerProxy. I don't have a preference for 
> either, so perhaps Mandy, Laurent or anybody else can express them...
>
>
> Regards, Peter
>
>>
>>     Other changes (to webrev.05):
>>     - removed the occurrence counts in switch comments (as per
>>     Mandy's suggestion)
>>     - made LoggerProxy and JavaLogger private
>>     - fixed double-read of volatile LoggerProxy.levelValue in
>>     LoggerProxy.isLoggable()
>>     - added static Level.javaLevel(int value) shortcut (Mandy)
>>
>>     I also updated the test to exercise the correctness of mappings.
>>
>>
>> Well done.
>>
>> cheers,
>> Laurent
>>
>



From bourges.laurent at gmail.com  Fri Mar 22 13:41:34 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Fri, 22 Mar 2013 14:41:34 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due to
	HashMap leads to Integer allocations (boxing)
In-Reply-To: <514C5C8D.1090406@gmail.com>
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com> <514B2E8D.8060701@gmail.com>
	<514B92A7.1000305@oracle.com>
	
	<514C2C94.60700@gmail.com>
	
	<514C4E09.3020008@gmail.com> <514C5C8D.1090406@gmail.com>
Message-ID: 

Peter,

that's OK for me and the code is clearer.


> What remains is a possible rename from: javaLogger, javaLevel,
> JavaLoggerProxy -> julLogger, julLevel, JulLoggerProxy if that's the final
> decision.
>

I vote for jul prefix that is more explicit; as I said, java means anything
but not specifically java.util.logging.

Laurent


From stefan.karlsson at oracle.com  Fri Mar 22 13:54:32 2013
From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com)
Date: Fri, 22 Mar 2013 13:54:32 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130322135510.0F76C4833B@hg.openjdk.java.net>

Changeset: 470232a8e89d
Author:    stefank
Date:      2013-03-22 15:01 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/470232a8e89d

8005116: NPG: Rename -permstat option for jmap in jdk8 to -clstats
Reviewed-by: jmasa, sla
Contributed-by: Erik Helin 

! src/share/classes/sun/tools/jmap/JMap.java

Changeset: 518d6087e01f
Author:    stefank
Date:      2013-03-22 15:01 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/518d6087e01f

8004172: Update jstat counter names to reflect metaspace changes
Reviewed-by: mchung
Contributed-by: Erik Helin 

! src/share/classes/sun/tools/jstat/resources/jstat_options
! test/sun/tools/jstat/gcCapacityOutput1.awk
! test/sun/tools/jstat/gcCauseOutput1.awk
+ test/sun/tools/jstat/gcMetaCapacityOutput1.awk
! test/sun/tools/jstat/gcOldOutput1.awk
! test/sun/tools/jstat/gcOutput1.awk
- test/sun/tools/jstat/gcPermCapacityOutput1.awk
+ test/sun/tools/jstat/jstatGcMetaCapacityOutput1.sh
- test/sun/tools/jstat/jstatGcPermCapacityOutput1.sh
! test/sun/tools/jstat/lineCounts1.awk
! test/sun/tools/jstat/lineCounts2.awk
! test/sun/tools/jstat/lineCounts3.awk
! test/sun/tools/jstat/lineCounts4.awk
! test/sun/tools/jstat/options1.out
! test/sun/tools/jstat/options2.out
! test/sun/tools/jstat/timeStamp1.awk
! test/sun/tools/jstatd/jstatGcutilOutput1.awk



From martinrb at google.com  Fri Mar 22 14:19:20 2013
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 22 Mar 2013 07:19:20 -0700
Subject: RFR-8008118
In-Reply-To: <20130321191147.A017197129@rebar.astron.com>
References: <68f061c7-bdf1-45d3-b543-6bee2b18f2e4@default>
	<20130321191147.A017197129@rebar.astron.com>
Message-ID: 

On Thu, Mar 21, 2013 at 12:11 PM, Christos Zoulas wrote:

> On Mar 21, 11:36am, john.zavgren at oracle.com (John Zavgren) wrote:
> -- Subject: Re: RFR-8008118
>
> | All:
> |
> | How does this look?
> | 1.) I reverted the for statement formatting change.
>
> Not exactly. Now it is indented incorrectly.
>
>
Agreed.  Really revert.


> | 2.) I removed the goto statement and "inlined" some code instead.
>
> I prefer to write simpler code that works with both signed and unsigned
> indexes:
>
> +                while (i > 0)
> +                    if (pathv[--i] != cwd)
> +                        free(pathv[i]);
> +
>
>
Christos' suggestion looks pretty good.

As Mark noted, need to add missing free of pathv itself.


> | 3.) I checked to make sure that we're not freeing memory that we didn't
> act=
> | ually allocate. (Path vector elements that are empty.)
>
> You are still using the "./" string literal constant in the code so you'll
> end up freeing it (the compiler will prolly merge the two instances and
> you'll get lucky but it is semantically incorrect).
>

Agreed,

pathv[i] = cwd;


From john.zavgren at oracle.com  Fri Mar 22 14:38:29 2013
From: john.zavgren at oracle.com (John Zavgren)
Date: Fri, 22 Mar 2013 07:38:29 -0700 (PDT)
Subject: RFR-8008118
Message-ID: <70b1d9e4-bee6-4355-8694-a7c7771861bf@default>


Greetings: 


I made modifications as per Martin's suggestions: 
1.) free pathv on "abort". 
2.) allocate memory for storing the "cwd" string, and then copy it into the memory location (to make sure that the contents of the pathv[] array don't refer to memory that's from the stack of the procedure that created it.) 


Thanks! 
John 



http://cr.openjdk.java.net/~jzavgren/8008118/webrev.06/ 
----- Original Message ----- 
From: martinrb at google.com 
To: christos at zoulas.com 
Cc: john.zavgren at oracle.com, core-libs-dev at openjdk.java.net 
Sent: Friday, March 22, 2013 10:19:24 AM GMT -05:00 US/Canada Eastern 
Subject: Re: RFR-8008118 







On Thu, Mar 21, 2013 at 12:11 PM, Christos Zoulas < christos at zoulas.com > wrote: 



On Mar 21, 11:36am, john.zavgren at oracle.com (John Zavgren) wrote: 
-- Subject: Re: RFR-8008118 


| All: 
| 
| How does this look? 
| 1.) I reverted the for statement formatting change. 

Not exactly. Now it is indented incorrectly. 





Agreed. Really revert. 



| 2.) I removed the goto statement and "inlined" some code instead. 

I prefer to write simpler code that works with both signed and unsigned 
indexes: 

+ while (i > 0) 
+ if (pathv[--i] != cwd) 
+ free(pathv[i]); 
+ 




Christos' suggestion looks pretty good. 


As Mark noted, need to add missing free of pathv itself. 


| 3.) I checked to make sure that we're not freeing memory that we didn't act= 

| ually allocate. (Path vector elements that are empty.) 

You are still using the "./" string literal constant in the code so you'll 
end up freeing it (the compiler will prolly merge the two instances and 
you'll get lucky but it is semantically incorrect). 



Agreed, 


pathv[i] = cwd;

From peter.levart at gmail.com  Fri Mar 22 16:23:57 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 22 Mar 2013 17:23:57 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due
	to HashMap leads to Integer allocations (boxing)
In-Reply-To: <514C5C8D.1090406@gmail.com>
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com> <514B2E8D.8060701@gmail.com>
	<514B92A7.1000305@oracle.com>
	
	<514C2C94.60700@gmail.com>
	
	<514C4E09.3020008@gmail.com> <514C5C8D.1090406@gmail.com>
Message-ID: <514C859D.1050705@gmail.com>

Hi Laurent,

I have run your performance test on my machine (i7 CPU, Linux) and with 
original code on JDK8 64bit (CompressedOOPS enabled by default, no TLAB 
options), i get:

...
INFO: testPerf[100000000 iterations]: duration = 1767.6329779999999 ms.
INFO: testPerf[100000000 iterations]: duration = 1758.7931449999999 ms.
INFO: testPerf[100000000 iterations]: duration = 1763.386362 ms.
...

While with latest patch (webrev.07), the results are:

...
INFO: testPerf[100000000 iterations]: duration = 660.940466 ms.
INFO: testPerf[100000000 iterations]: duration = 662.4854379999999 ms.
INFO: testPerf[100000000 iterations]: duration = 656.497199 ms.
...


So it's apparently a 2.5x improvement in speed.

This test is designed to test the PlatformLogger.isLoggable() for levels 
that don't result in log messages being actually written out, but there 
are some caveats:

- the test is using a loop with local variables and counters, which is 
very prone to JIT optimizations such as loop-unrolling. This might or 
might not be happening and even if it is, the impact might be the same 
on unpatched vs. patched PlatformLogger code.
- the test is testing the performance when the PlatformLogger is 
directed to java.util.logging from the beginning. That means JIT is 
compiling calls to virtual methods of JavaLoggerProxy into monomorphic 
inlined calls. The results are different if the test is 1st warmed-up 
while no java.util.logging is initialized yet (calls directed to 
LoggerProxy) and later java.util.logging is enabled (PlatformLoggers are 
redirected to JavaLoggerProxys) and the same test repeated.

I have created a special test that demonstrates this (all tests run on 
recent JDK8 build, i7 (4 cores) Linux, 64bit, no TLAB option, 
CompressedOOPS enabled by default):

** Original code

 >> JVM START
#
# isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
#
# Warm up:
            1 threads, Tavg =      1.78 ns/op (? =   0.00 ns/op) [     1.78]
            1 threads, Tavg =      1.67 ns/op (? =   0.00 ns/op) [     1.67]
# Measure:
            1 threads, Tavg =      1.44 ns/op (? =   0.00 ns/op) [     1.44]
            2 threads, Tavg =      1.37 ns/op (? =   0.01 ns/op) [     
1.37,      1.38]
            3 threads, Tavg =      1.53 ns/op (? =   0.13 ns/op) [     
1.41,      1.49,      1.71]
            4 threads, Tavg =      1.43 ns/op (? =   0.10 ns/op) [     
1.36,      1.62,      1.39,      1.38]

<< JVM END

 >> JVM START

 >> java.util.logging enabled

#
# isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
#
# Warm up:
            1 threads, Tavg =      4.81 ns/op (? =   0.00 ns/op) [     4.81]
            1 threads, Tavg =      4.79 ns/op (? =   0.00 ns/op) [     4.79]
# Measure:
            1 threads, Tavg =      4.67 ns/op (? =   0.00 ns/op) [     4.67]
            2 threads, Tavg =      4.67 ns/op (? =   0.00 ns/op) [     
4.67,      4.67]
            3 threads, Tavg =      4.87 ns/op (? =   0.31 ns/op) [     
4.67,      4.68,      5.32]
            4 threads, Tavg =      4.68 ns/op (? =   0.01 ns/op) [     
4.68,      4.67,      4.68,      4.69]

<< JVM END

 >> JVM START
#
# isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
#
# Warm up:
            1 threads, Tavg =      1.39 ns/op (? =   0.00 ns/op) [     1.39]
            1 threads, Tavg =      1.80 ns/op (? =   0.00 ns/op) [     1.80]
# Measure:
            1 threads, Tavg =      1.38 ns/op (? =   0.00 ns/op) [     1.38]
            2 threads, Tavg =      1.38 ns/op (? =   0.00 ns/op) [     
1.38,      1.38]
            3 threads, Tavg =      1.38 ns/op (? =   0.01 ns/op) [     
1.39,      1.38,      1.37]
            4 threads, Tavg =      1.38 ns/op (? =   0.02 ns/op) [     
1.42,      1.37,      1.37,      1.37]


 >> java.util.logging enabled

#
# isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
#
# Warm up:
            1 threads, Tavg =     11.87 ns/op (? =   0.00 ns/op) [    11.87]
            1 threads, Tavg =      9.08 ns/op (? =   0.00 ns/op) [     9.08]
# Measure:
            1 threads, Tavg =      9.12 ns/op (? =   0.00 ns/op) [     9.12]
            2 threads, Tavg =      9.02 ns/op (? =   0.02 ns/op) [     
9.05,      9.00]
            3 threads, Tavg =      9.20 ns/op (? =   0.04 ns/op) [     
9.26,      9.19,      9.17]
            4 threads, Tavg =      9.33 ns/op (? =   0.07 ns/op) [     
9.44,      9.34,      9.26,      9.28]

<< JVM END


** Patched code (webrev.07)

 >> JVM START
#
# isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
#
# Warm up:
            1 threads, Tavg =      1.38 ns/op (? =   0.00 ns/op) [     1.38]
            1 threads, Tavg =      1.68 ns/op (? =   0.00 ns/op) [     1.68]
# Measure:
            1 threads, Tavg =      1.38 ns/op (? =   0.00 ns/op) [     1.38]
            2 threads, Tavg =      1.40 ns/op (? =   0.02 ns/op) [     
1.37,      1.42]
            3 threads, Tavg =      1.49 ns/op (? =   0.21 ns/op) [     
1.80,      1.38,      1.36]
            4 threads, Tavg =      1.50 ns/op (? =   0.13 ns/op) [     
1.47,      1.73,      1.41,      1.42]

<< JVM END

 >> JVM START

 >> java.util.logging enabled

#
# isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
#
# Warm up:
            1 threads, Tavg =      1.80 ns/op (? =   0.00 ns/op) [     1.80]
            1 threads, Tavg =      1.74 ns/op (? =   0.00 ns/op) [     1.74]
# Measure:
            1 threads, Tavg =      1.78 ns/op (? =   0.00 ns/op) [     1.78]
            2 threads, Tavg =      1.80 ns/op (? =   0.00 ns/op) [     
1.80,      1.80]
            3 threads, Tavg =      1.84 ns/op (? =   0.03 ns/op) [     
1.80,      1.88,      1.86]
            4 threads, Tavg =      1.78 ns/op (? =   0.00 ns/op) [     
1.78,      1.77,      1.77,      1.78]

<< JVM END

 >> JVM START
#
# isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
#
# Warm up:
            1 threads, Tavg =      1.73 ns/op (? =   0.00 ns/op) [     1.73]
            1 threads, Tavg =      1.72 ns/op (? =   0.00 ns/op) [     1.72]
# Measure:
            1 threads, Tavg =      1.38 ns/op (? =   0.00 ns/op) [     1.38]
            2 threads, Tavg =      1.37 ns/op (? =   0.00 ns/op) [     
1.37,      1.37]
            3 threads, Tavg =      1.52 ns/op (? =   0.19 ns/op) [     
1.37,      1.45,      1.79]
            4 threads, Tavg =      1.58 ns/op (? =   0.19 ns/op) [     
1.42,      1.79,      1.81,      1.41]


 >> java.util.logging enabled

#
# isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
#
# Warm up:
            1 threads, Tavg =      5.43 ns/op (? =   0.00 ns/op) [     5.43]
            1 threads, Tavg =      5.65 ns/op (? =   0.00 ns/op) [     5.65]
# Measure:
            1 threads, Tavg =      5.66 ns/op (? =   0.00 ns/op) [     5.66]
            2 threads, Tavg =      5.67 ns/op (? =   0.01 ns/op) [     
5.68,      5.66]
            3 threads, Tavg =      5.65 ns/op (? =   0.00 ns/op) [     
5.65,      5.65,      5.65]
            4 threads, Tavg =      5.66 ns/op (? =   0.01 ns/op) [     
5.65,      5.65,      5.67,      5.67]

<< JVM END


It appears the speed-up is visible and varies from 1.6x to 2.6x, 
depending on other factors that also play role in the overall speed 
(like JIT optimizations).

I only presented the results for PlatformLogger.isLoggable(FINEST), 
because this is the most sensitive call in tight loops. Other methods 
perform similarly.

This is the test code I used:


package test;

import si.pele.microbench.TestRunner;
import sun.util.logging.PlatformLogger;

import java.util.logging.LogManager;

public class PlatformLoggerBenchmark extends TestRunner {

     static final PlatformLogger log = 
PlatformLogger.getLogger(PlatformLoggerBenchmark.class.getName());

     static {
         log.setLevel(PlatformLogger.SEVERE); // almost OFF
     }

     public static class isLoggableFinest extends Test {
         @Override
         protected void doLoop(Loop loop, DevNull devNull1, DevNull 
devNull2, DevNull devNull3, DevNull devNull4, DevNull devNull5) {
             while (loop.nextIteration()) {
devNull1.yield(log.isLoggable(PlatformLogger.FINEST));
             }
         }
     }

     public static void main(String[] args) throws Exception {

         System.out.println(">> JVM START");

         doTest(isLoggableFinest.class, 5000L, 1, 4, 1);

         // enable java.util.logging
LogManager.getLogManager().getLogger(log.getName());
         System.out.println("\n>> java.util.logging enabled\n");

         doTest(isLoggableFinest.class, 5000L, 1, 4, 1);

         System.out.println("<< JVM END");
     }
}


The test uses a simple microbenchmark runner that I coded together using 
some ideas from the sessions with Alexey Shipilev and his benchmark suite.

Here's the source to my dirty implementation:

     https://github.com/plevart/micro-bench/tree/v2


Regards, Peter

On 03/22/2013 02:28 PM, Peter Levart wrote:
> Ok, Lauret, Mandy,
>
> Here are the final touches:
>
> https://dl.dropboxusercontent.com/u/101777488/jdk8-tl/PlatformLogger/webrev.07/index.html
>
> Changes from webrev.06:
>
> - renamed back Level -> LevelEnum
> - renamed JavaLogger -> JavaLoggerProxy
> - moved javaLevel(int) static method from LevelEnum to JavaLoggerProxy 
> and made it private (only used there)
> - consistent use of variable name 'level' to refer to PlatformLogger's 
> int level value
> - consistent use of variable name 'levelEnum' to refer to LevelEnum member
> - consistent use of variable name 'javaLevel' to refer to 
> java.util.logging.Level instance
> - consistent use of variable name 'javaLogger' to refer to 
> java.util.logging.Logger instance
> - renamed PlatformLogger.newJavaLogger() private method -> 
> PlatformLogger.redirectToJavaLoggerProxy()
> - renamed PlatformLogger.logger private field -> 
> PlatformLogger.loggerProxy
> - some additional comments
>
> I think that these changes make code more consistent and self-explanatory.
>
> What remains is a possible rename from: javaLogger, javaLevel, 
> JavaLoggerProxy -> julLogger, julLevel, JulLoggerProxy if that's the 
> final decision.
>
> Regards, Peter
>
>
> On 03/22/2013 01:26 PM, Peter Levart wrote:
>> On 03/22/2013 11:34 AM, Laurent Bourg?s wrote:
>>> Peter,
>>>
>>>     You've beaten me! I have been preparing them too ;-) ...
>>>
>>>
>>> Ok I definitely stop working on the code and let you do it.
>>
>> Ok. I'll make the final touches, incorporating also comments and 
>> changes from your code...
>>
>>>
>>>     I also did some some renames, that I think make the code more
>>>     consistent:
>>>     - LevelEnum -> Level (the code is not dependent on
>>>     java.util.logging.Level, so the name can be reused, its private
>>>     anyway)
>>>     - julLevel -> javaLevel (javaLevel / JavaLogger)
>>>     - LevelEnum.forValue -> Level.valueOf (Mandy)
>>>     - JavaLogger.julLevelToEnum -> JavaLogger.javaLevelToLevel
>>>
>>>
>>> For consistency and clarity, I would prefer having following 
>>> conventions:
>>> - int levelValue (= PlatformLevel as int) and not int level 
>>> (conflict with Level enum ...)
>>
>> I think that PlatformLogger public API should stay as is. Public 
>> method's parameter names are just called 'level' and values of public 
>> constants are expected to be passed to them. There are only two 
>> places where 'level' is the name of a local variable of type Level 
>> (and not int) and at both places there is not conflict, since there's 
>> no 'int level' variable in scope.
>>
>> I renamed LevelEnum to Level because the following most frequently 
>> used pattern looks strange:
>>
>>     LevelEnum.javaLevel(int)
>>
>> Neither parameter nor the result has anything to do with LevelEnum 
>> directly.
>>
>> But if we move the javaLevel(int) method out of the Level enum into 
>> the JavaLogger, then Level can be renamed back to LevelEnum (or 
>> anything else?).
>>
>>
>>> - julLevel / julLogger: more explicit than javaLevel / javaLogger 
>>> (java means everything  ... but jul means java.util.logging and 
>>> javaLogger is in conflict with JavaLogger class)
>>
>>
>> But javaLogger is not in conflict with javaLevel. I suggest renaming 
>> JavaLoger class to JavaLoggerProxy, so we would have:
>>
>> Object javaLogger // holding java.util.logging.Logger instance
>> Object javaLevel    // holding java.util.logging.Level instance
>>
>> class JavaLoggerProxy  // a specialization of LoggerProxy, delegating 
>> to javaLogger
>>
>> If 'jul' is a prefered prefix to 'java', I suggest renaming all 3: 
>> julLogger, julLevel, JulLoggerProxy. I don't have a preference for 
>> either, so perhaps Mandy, Laurent or anybody else can express them...
>>
>>
>> Regards, Peter
>>
>>>
>>>     Other changes (to webrev.05):
>>>     - removed the occurrence counts in switch comments (as per
>>>     Mandy's suggestion)
>>>     - made LoggerProxy and JavaLogger private
>>>     - fixed double-read of volatile LoggerProxy.levelValue in
>>>     LoggerProxy.isLoggable()
>>>     - added static Level.javaLevel(int value) shortcut (Mandy)
>>>
>>>     I also updated the test to exercise the correctness of mappings.
>>>
>>>
>>> Well done.
>>>
>>> cheers,
>>> Laurent
>>>
>>
>



From mandy.chung at oracle.com  Fri Mar 22 16:32:27 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 22 Mar 2013 09:32:27 -0700
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due
	to HashMap leads to Integer allocations (boxing)
In-Reply-To: <514C859D.1050705@gmail.com>
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com> <514B2E8D.8060701@gmail.com>
	<514B92A7.1000305@oracle.com>
	
	<514C2C94.60700@gmail.com>
	
	<514C4E09.3020008@gmail.com> <514C5C8D.1090406@gmail.com>
	<514C859D.1050705@gmail.com>
Message-ID: <514C879B.3060400@oracle.com>

Peter, Laurent,

This is good work.  I don't have the cycle to look through this data 
this week.  I'll get to it next week.

Mandy

On 3/22/2013 9:23 AM, Peter Levart wrote:
> Hi Laurent,
>
> I have run your performance test on my machine (i7 CPU, Linux) and 
> with original code on JDK8 64bit (CompressedOOPS enabled by default, 
> no TLAB options), i get:
>
> ...
> INFO: testPerf[100000000 iterations]: duration = 1767.6329779999999 ms.
> INFO: testPerf[100000000 iterations]: duration = 1758.7931449999999 ms.
> INFO: testPerf[100000000 iterations]: duration = 1763.386362 ms.
> ...
>
> While with latest patch (webrev.07), the results are:
>
> ...
> INFO: testPerf[100000000 iterations]: duration = 660.940466 ms.
> INFO: testPerf[100000000 iterations]: duration = 662.4854379999999 ms.
> INFO: testPerf[100000000 iterations]: duration = 656.497199 ms.
> ...
>
>
> So it's apparently a 2.5x improvement in speed.
>
> This test is designed to test the PlatformLogger.isLoggable() for 
> levels that don't result in log messages being actually written out, 
> but there are some caveats:
>
> - the test is using a loop with local variables and counters, which is 
> very prone to JIT optimizations such as loop-unrolling. This might or 
> might not be happening and even if it is, the impact might be the same 
> on unpatched vs. patched PlatformLogger code.
> - the test is testing the performance when the PlatformLogger is 
> directed to java.util.logging from the beginning. That means JIT is 
> compiling calls to virtual methods of JavaLoggerProxy into monomorphic 
> inlined calls. The results are different if the test is 1st warmed-up 
> while no java.util.logging is initialized yet (calls directed to 
> LoggerProxy) and later java.util.logging is enabled (PlatformLoggers 
> are redirected to JavaLoggerProxys) and the same test repeated.
>
> I have created a special test that demonstrates this (all tests run on 
> recent JDK8 build, i7 (4 cores) Linux, 64bit, no TLAB option, 
> CompressedOOPS enabled by default):
>
> ** Original code
>
> >> JVM START
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      1.78 ns/op (? = 0.00 ns/op) [     1.78]
>            1 threads, Tavg =      1.67 ns/op (? = 0.00 ns/op) [     1.67]
> # Measure:
>            1 threads, Tavg =      1.44 ns/op (? = 0.00 ns/op) [     1.44]
>            2 threads, Tavg =      1.37 ns/op (? = 0.01 ns/op) [     
> 1.37,      1.38]
>            3 threads, Tavg =      1.53 ns/op (? = 0.13 ns/op) [     
> 1.41,      1.49,      1.71]
>            4 threads, Tavg =      1.43 ns/op (? = 0.10 ns/op) [     
> 1.36,      1.62,      1.39,      1.38]
>
> << JVM END
>
> >> JVM START
>
> >> java.util.logging enabled
>
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      4.81 ns/op (? = 0.00 ns/op) [     4.81]
>            1 threads, Tavg =      4.79 ns/op (? = 0.00 ns/op) [     4.79]
> # Measure:
>            1 threads, Tavg =      4.67 ns/op (? = 0.00 ns/op) [     4.67]
>            2 threads, Tavg =      4.67 ns/op (? = 0.00 ns/op) [     
> 4.67,      4.67]
>            3 threads, Tavg =      4.87 ns/op (? = 0.31 ns/op) [     
> 4.67,      4.68,      5.32]
>            4 threads, Tavg =      4.68 ns/op (? = 0.01 ns/op) [     
> 4.68,      4.67,      4.68,      4.69]
>
> << JVM END
>
> >> JVM START
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      1.39 ns/op (? = 0.00 ns/op) [     1.39]
>            1 threads, Tavg =      1.80 ns/op (? = 0.00 ns/op) [     1.80]
> # Measure:
>            1 threads, Tavg =      1.38 ns/op (? = 0.00 ns/op) [     1.38]
>            2 threads, Tavg =      1.38 ns/op (? = 0.00 ns/op) [     
> 1.38,      1.38]
>            3 threads, Tavg =      1.38 ns/op (? = 0.01 ns/op) [     
> 1.39,      1.38,      1.37]
>            4 threads, Tavg =      1.38 ns/op (? = 0.02 ns/op) [     
> 1.42,      1.37,      1.37,      1.37]
>
>
> >> java.util.logging enabled
>
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =     11.87 ns/op (? = 0.00 ns/op) [    11.87]
>            1 threads, Tavg =      9.08 ns/op (? = 0.00 ns/op) [     9.08]
> # Measure:
>            1 threads, Tavg =      9.12 ns/op (? = 0.00 ns/op) [     9.12]
>            2 threads, Tavg =      9.02 ns/op (? = 0.02 ns/op) [     
> 9.05,      9.00]
>            3 threads, Tavg =      9.20 ns/op (? = 0.04 ns/op) [     
> 9.26,      9.19,      9.17]
>            4 threads, Tavg =      9.33 ns/op (? = 0.07 ns/op) [     
> 9.44,      9.34,      9.26,      9.28]
>
> << JVM END
>
>
> ** Patched code (webrev.07)
>
> >> JVM START
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      1.38 ns/op (? = 0.00 ns/op) [     1.38]
>            1 threads, Tavg =      1.68 ns/op (? = 0.00 ns/op) [     1.68]
> # Measure:
>            1 threads, Tavg =      1.38 ns/op (? = 0.00 ns/op) [     1.38]
>            2 threads, Tavg =      1.40 ns/op (? = 0.02 ns/op) [     
> 1.37,      1.42]
>            3 threads, Tavg =      1.49 ns/op (? = 0.21 ns/op) [     
> 1.80,      1.38,      1.36]
>            4 threads, Tavg =      1.50 ns/op (? = 0.13 ns/op) [     
> 1.47,      1.73,      1.41,      1.42]
>
> << JVM END
>
> >> JVM START
>
> >> java.util.logging enabled
>
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      1.80 ns/op (? = 0.00 ns/op) [     1.80]
>            1 threads, Tavg =      1.74 ns/op (? = 0.00 ns/op) [     1.74]
> # Measure:
>            1 threads, Tavg =      1.78 ns/op (? = 0.00 ns/op) [     1.78]
>            2 threads, Tavg =      1.80 ns/op (? = 0.00 ns/op) [     
> 1.80,      1.80]
>            3 threads, Tavg =      1.84 ns/op (? = 0.03 ns/op) [     
> 1.80,      1.88,      1.86]
>            4 threads, Tavg =      1.78 ns/op (? = 0.00 ns/op) [     
> 1.78,      1.77,      1.77,      1.78]
>
> << JVM END
>
> >> JVM START
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      1.73 ns/op (? = 0.00 ns/op) [     1.73]
>            1 threads, Tavg =      1.72 ns/op (? = 0.00 ns/op) [     1.72]
> # Measure:
>            1 threads, Tavg =      1.38 ns/op (? = 0.00 ns/op) [     1.38]
>            2 threads, Tavg =      1.37 ns/op (? = 0.00 ns/op) [     
> 1.37,      1.37]
>            3 threads, Tavg =      1.52 ns/op (? = 0.19 ns/op) [     
> 1.37,      1.45,      1.79]
>            4 threads, Tavg =      1.58 ns/op (? = 0.19 ns/op) [     
> 1.42,      1.79,      1.81,      1.41]
>
>
> >> java.util.logging enabled
>
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      5.43 ns/op (? = 0.00 ns/op) [     5.43]
>            1 threads, Tavg =      5.65 ns/op (? = 0.00 ns/op) [     5.65]
> # Measure:
>            1 threads, Tavg =      5.66 ns/op (? = 0.00 ns/op) [     5.66]
>            2 threads, Tavg =      5.67 ns/op (? = 0.01 ns/op) [     
> 5.68,      5.66]
>            3 threads, Tavg =      5.65 ns/op (? = 0.00 ns/op) [     
> 5.65,      5.65,      5.65]
>            4 threads, Tavg =      5.66 ns/op (? = 0.01 ns/op) [     
> 5.65,      5.65,      5.67,      5.67]
>
> << JVM END
>
>
> It appears the speed-up is visible and varies from 1.6x to 2.6x, 
> depending on other factors that also play role in the overall speed 
> (like JIT optimizations).
>
> I only presented the results for PlatformLogger.isLoggable(FINEST), 
> because this is the most sensitive call in tight loops. Other methods 
> perform similarly.
>
> This is the test code I used:
>
>
> package test;
>
> import si.pele.microbench.TestRunner;
> import sun.util.logging.PlatformLogger;
>
> import java.util.logging.LogManager;
>
> public class PlatformLoggerBenchmark extends TestRunner {
>
>     static final PlatformLogger log = 
> PlatformLogger.getLogger(PlatformLoggerBenchmark.class.getName());
>
>     static {
>         log.setLevel(PlatformLogger.SEVERE); // almost OFF
>     }
>
>     public static class isLoggableFinest extends Test {
>         @Override
>         protected void doLoop(Loop loop, DevNull devNull1, DevNull 
> devNull2, DevNull devNull3, DevNull devNull4, DevNull devNull5) {
>             while (loop.nextIteration()) {
> devNull1.yield(log.isLoggable(PlatformLogger.FINEST));
>             }
>         }
>     }
>
>     public static void main(String[] args) throws Exception {
>
>         System.out.println(">> JVM START");
>
>         doTest(isLoggableFinest.class, 5000L, 1, 4, 1);
>
>         // enable java.util.logging
> LogManager.getLogManager().getLogger(log.getName());
>         System.out.println("\n>> java.util.logging enabled\n");
>
>         doTest(isLoggableFinest.class, 5000L, 1, 4, 1);
>
>         System.out.println("<< JVM END");
>     }
> }
>
>
> The test uses a simple microbenchmark runner that I coded together 
> using some ideas from the sessions with Alexey Shipilev and his 
> benchmark suite.
>
> Here's the source to my dirty implementation:
>
> https://github.com/plevart/micro-bench/tree/v2
>
>
> Regards, Peter
>
> On 03/22/2013 02:28 PM, Peter Levart wrote:
>> Ok, Lauret, Mandy,
>>
>> Here are the final touches:
>>
>> https://dl.dropboxusercontent.com/u/101777488/jdk8-tl/PlatformLogger/webrev.07/index.html
>>
>> Changes from webrev.06:
>>
>> - renamed back Level -> LevelEnum
>> - renamed JavaLogger -> JavaLoggerProxy
>> - moved javaLevel(int) static method from LevelEnum to 
>> JavaLoggerProxy and made it private (only used there)
>> - consistent use of variable name 'level' to refer to 
>> PlatformLogger's int level value
>> - consistent use of variable name 'levelEnum' to refer to LevelEnum 
>> member
>> - consistent use of variable name 'javaLevel' to refer to 
>> java.util.logging.Level instance
>> - consistent use of variable name 'javaLogger' to refer to 
>> java.util.logging.Logger instance
>> - renamed PlatformLogger.newJavaLogger() private method -> 
>> PlatformLogger.redirectToJavaLoggerProxy()
>> - renamed PlatformLogger.logger private field -> 
>> PlatformLogger.loggerProxy
>> - some additional comments
>>
>> I think that these changes make code more consistent and 
>> self-explanatory.
>>
>> What remains is a possible rename from: javaLogger, javaLevel, 
>> JavaLoggerProxy -> julLogger, julLevel, JulLoggerProxy if that's the 
>> final decision.
>>
>> Regards, Peter
>>
>>
>> On 03/22/2013 01:26 PM, Peter Levart wrote:
>>> On 03/22/2013 11:34 AM, Laurent Bourg?s wrote:
>>>> Peter,
>>>>
>>>>     You've beaten me! I have been preparing them too ;-) ...
>>>>
>>>>
>>>> Ok I definitely stop working on the code and let you do it.
>>>
>>> Ok. I'll make the final touches, incorporating also comments and 
>>> changes from your code...
>>>
>>>>
>>>>     I also did some some renames, that I think make the code more
>>>>     consistent:
>>>>     - LevelEnum -> Level (the code is not dependent on
>>>>     java.util.logging.Level, so the name can be reused, its private
>>>>     anyway)
>>>>     - julLevel -> javaLevel (javaLevel / JavaLogger)
>>>>     - LevelEnum.forValue -> Level.valueOf (Mandy)
>>>>     - JavaLogger.julLevelToEnum -> JavaLogger.javaLevelToLevel
>>>>
>>>>
>>>> For consistency and clarity, I would prefer having following 
>>>> conventions:
>>>> - int levelValue (= PlatformLevel as int) and not int level 
>>>> (conflict with Level enum ...)
>>>
>>> I think that PlatformLogger public API should stay as is. Public 
>>> method's parameter names are just called 'level' and values of 
>>> public constants are expected to be passed to them. There are only 
>>> two places where 'level' is the name of a local variable of type 
>>> Level (and not int) and at both places there is not conflict, since 
>>> there's no 'int level' variable in scope.
>>>
>>> I renamed LevelEnum to Level because the following most frequently 
>>> used pattern looks strange:
>>>
>>>     LevelEnum.javaLevel(int)
>>>
>>> Neither parameter nor the result has anything to do with LevelEnum 
>>> directly.
>>>
>>> But if we move the javaLevel(int) method out of the Level enum into 
>>> the JavaLogger, then Level can be renamed back to LevelEnum (or 
>>> anything else?).
>>>
>>>
>>>> - julLevel / julLogger: more explicit than javaLevel / javaLogger 
>>>> (java means everything  ... but jul means java.util.logging and 
>>>> javaLogger is in conflict with JavaLogger class)
>>>
>>>
>>> But javaLogger is not in conflict with javaLevel. I suggest renaming 
>>> JavaLoger class to JavaLoggerProxy, so we would have:
>>>
>>> Object javaLogger // holding java.util.logging.Logger instance
>>> Object javaLevel    // holding java.util.logging.Level instance
>>>
>>> class JavaLoggerProxy  // a specialization of LoggerProxy, 
>>> delegating to javaLogger
>>>
>>> If 'jul' is a prefered prefix to 'java', I suggest renaming all 3: 
>>> julLogger, julLevel, JulLoggerProxy. I don't have a preference for 
>>> either, so perhaps Mandy, Laurent or anybody else can express them...
>>>
>>>
>>> Regards, Peter
>>>
>>>>
>>>>     Other changes (to webrev.05):
>>>>     - removed the occurrence counts in switch comments (as per
>>>>     Mandy's suggestion)
>>>>     - made LoggerProxy and JavaLogger private
>>>>     - fixed double-read of volatile LoggerProxy.levelValue in
>>>>     LoggerProxy.isLoggable()
>>>>     - added static Level.javaLevel(int value) shortcut (Mandy)
>>>>
>>>>     I also updated the test to exercise the correctness of mappings.
>>>>
>>>>
>>>> Well done.
>>>>
>>>> cheers,
>>>> Laurent
>>>>
>>>
>>
>



From joe.darcy at oracle.com  Fri Mar 22 17:09:00 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Fri, 22 Mar 2013 17:09:00 +0000
Subject: hg: jdk8/tl/langtools: 7080464: langtools regression test failures
	when assertions are enabled
Message-ID: <20130322170906.1F92948345@hg.openjdk.java.net>

Changeset: f4500abff1fd
Author:    darcy
Date:      2013-03-22 10:08 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f4500abff1fd

7080464: langtools regression test failures when assertions are enabled
Reviewed-by: jjg

! test/tools/javac/api/TestJavacTaskScanner.java
! test/tools/javac/diags/MessageFile.java
! test/tools/javac/diags/MessageInfo.java



From Alan.Bateman at oracle.com  Fri Mar 22 18:18:30 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 22 Mar 2013 18:18:30 +0000
Subject: RFR(S): 8009397 test/com/sun/jdi/PrivateTransportTest.sh: ERROR:
	transport library missing onLoad entry: private_dt_socket
In-Reply-To: <6E926A33-CBCE-46C9-86A4-2C3F57E058CB@oracle.com>
References: <2A1F6D24-22FC-4CB4-84FD-05E8ECDDC9BF@oracle.com>
	<513646F9.3060601@oracle.com>
	
	<51379D88.6080807@oracle.com>
	<6E926A33-CBCE-46C9-86A4-2C3F57E058CB@oracle.com>
Message-ID: <514CA076.6060600@oracle.com>

On 07/03/2013 11:54, Staffan Larsen wrote:
> Here is a webrev for fixing this problem. I actually removed all of our own tokenization code in dll_build_name() and replaced it with calls to strtok_r (strtok_s on windows) instead. I think this should be more robust, at the cost of an extra memory allocation. I've also added the const qualifier to some of the parameters.
>
> http://cr.openjdk.java.net/~sla/8009558/webrev.02/
>
> All of the jdi and hprof tests passes with this change.
>
> Thanks,
> /Staffan
>
This looks good to me too.

A minor nit is that probably should put a space in "while(path = ..." in 
all of the dll_build_name implementation. Ignore this comment if you've 
already created the change-set are ready to push of course.

-Alan


From bradford.wetmore at oracle.com  Fri Mar 22 19:10:46 2013
From: bradford.wetmore at oracle.com (Brad Wetmore)
Date: Fri, 22 Mar 2013 12:10:46 -0700
Subject: RFR 8009517: Disable fatal compiler warning in the old build
In-Reply-To: <514C178F.4000401@oracle.com>
References: <5139E680.6000606@oracle.com>
	
	<513A0A96.7080508@oracle.com> <513A8194.9040002@oracle.com>
	<513AEEBB.2080900@oracle.com> <5147BF89.7000602@oracle.com>
	<514B85BA.5000302@oracle.com> <514C178F.4000401@oracle.com>
Message-ID: <514CACB6.6060106@oracle.com>



On 3/22/2013 1:34 AM, Alan Bateman wrote:
> On 21/03/2013 22:12, Brad Wetmore wrote:
>> :
>>
>> The codereview is here:
>>
>> http://cr.openjdk.java.net/~wetmore/8009517/webrev.00/
>>
>> I plan to push through the deploy gate, as they have an integration
>> next week.  Thomas Ng will do the push for us.
>>
>> Any objections, please speak now.
> No objection here but just to mention that since you need to set
> NEWBUILD=false then it might not be too much extra to also set
> JAVAC_WARNINGS_FATAL=false.

At least for me, I'm not using the new build environment at all.  (I 
think RE is doing the same when building the JCE jar files):

     % cd jdk/make
     % make381 all

That is, NEWBUILD doesn't exist in this build hierarchy.

As for adding JAVAC_WARNINGS_FATAL=false, I thought we were keeping 
warnings fatal here to so that folks running builds in this environment 
can the developers know they are introducing warnings/crud into their code?

> In any case, I think it would be desirable if there was a retirement
> date set for the old build so that the remaining users (I assume very
> few at this point) have something to aim for.

Erik is now more aware of our JCE build problems, so hopefully we won't 
be far behind.  I was surprised to hear deploy still has the dependency.

Brad


From bill.pittore at oracle.com  Fri Mar 22 21:02:41 2013
From: bill.pittore at oracle.com (BILL PITTORE)
Date: Fri, 22 Mar 2013 17:02:41 -0400
Subject: Request for review fix for 8010668
Message-ID: <514CC6F1.7050109@oracle.com>

This fixes a problem with the recently committed changes for JNI static 
libraries. On an error condition or explicit unload request, statically 
linked libs should not be unloaded.

http://cr.openjdk.java.net/~bpittore/8010668/webrev.00/

thanks,
bill




From christian.thalinger at oracle.com  Fri Mar 22 23:10:03 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 22 Mar 2013 16:10:03 -0700
Subject: RFR (M): 7198429: need checked categorization of caller-sensitive
	methods in the JDK
In-Reply-To: <7D0554D4-7E1E-4DD0-907A-8F7AF17B9928@oracle.com>
References: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com>
	
	<7D0554D4-7E1E-4DD0-907A-8F7AF17B9928@oracle.com>
Message-ID: <8C82BDFA-7981-4D0C-955A-D9C474831DF2@oracle.com>


On Mar 19, 2013, at 6:02 PM, Christian Thalinger  wrote:

> 
> On Mar 19, 2013, at 5:21 PM, John Rose  wrote:
> 
>> On Mar 14, 2013, at 8:31 PM, Christian Thalinger  wrote:
>> 
>>> [This is the HotSpot part of JEP 176]
>>> 
>>> http://cr.openjdk.java.net/~twisti/7198429
>>> 
>>> 7198429: need checked categorization of caller-sensitive methods in the JDK
>>> Reviewed-by:
>> 
>> 
>> Over all, great work on a tricky problem.  I'd add a few asserts and tweak a couple of lines; see below.  Reviewed as is or with suggested changes. ? John
>> 
>> --- Method::is_ignored_by_security_stack_walk
>> I would like to see reflect_invoke_cache go away some day.  Would it be possible to strengthen the asserts to prove that it is an expensive alias for an intrinsic_id check?  (I realize this is a question mainly for folks working on JVMTI.)
> 
> That's what I tried to do:  if the intrinsic_id == _invoke it also must be the same method in reflect_invoke_cache.  More than that would mean to enhance ActiveMethodOopsCache because you can't ask for methods in the cache.
> 
>> 
>> --- JVM_GetCallerClass
>> Suggest an assert for vfst.method() == NULL.  Should not happen, and previous code would apparently have crashed already, but...
>> 
>> (The corner case I'm thinking of is a compiled frame with nmethod::method returning null after nmethod::make_unloaded.  Should not happen.)
> 
> Sure, I can add that assert but there is other code in jvm.cpp that relies on the fact that vfst.method() is non-null.  We should add asserts in all that places but that's for another RFE.
> 
>> 
>> --- JVM_GetClassContext
>> What do these lines do:
>> +   // Collect method holders
>> +   GrowableArray* klass_array = new GrowableArray();
>> 
>> It looks like a paste-o from another source base.
> 
> Left over.  I filed an RFE for that improvement:
> 
> JDK-8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink
> 
>> 
>> --- LibraryCallKit::inline_native_Reflection_getCallerClass
>> 
>> I believe this assertion, but I would prefer to see it checked more forcibly:
>> +   // NOTE: Start the loop at depth 1 because the current JVM state does
>> +   // not include the Reflection.getCallerClass() frame.
>> 
>> Not sure there is a good way to do this.  But, perhaps put the comment here:
>>  case 0:
>>    // ...comment...
>>    ShouldNotReachHere();
> 
> How about:
> 
>    case 0:
>      fatal("current JVM state does not include the Reflection.getCallerClass() frame");
>      break;
> 
>> 
>> Also, if something goes wrong with caller sensitivity, we just get a "return false".  Perhaps do a "caller_jvm=NULL;break" to branch to the pretty failure message?  That makes it slightly easier to see what happened.
> 
> It seems easier to add printing code to the case statement:
> 
>    case 1:
>      // Frame 0 and 1 must be caller sensitive (see JVM_GetCallerClass).
>      if (!m->caller_sensitive()) {
> #ifndef PRODUCT
>        if ((PrintIntrinsics || PrintInlining || PrintOptoInlining) && Verbose) {
>          tty->print_cr("  Bailing out: CallerSensitive annotation expected at frame %d", n);
>        }
> #endif
>        return false;  // bail-out; let JVM_GetCallerClass do the work
>      }
>      break;
> 
>> 
>> The LogCompilation switch should leave a "paper trail".  Actually, I see that LogCompilation doesn't mention failed intrinsic inlines.  Rats.  At least PrintInlining or PrintIntrinsics (diagnostic flags) will give us some leverage if we need to debug.
>> 
>> --- JVM_RegisterUnsafeMethods
>> That's an improvement.  Thanks.
>> 
>> (A nagging worry:  How big are those static tables getting?)
> 
> We could remove some very old ones like 1.4.0 and 1.4.1.  This time, next time?
> 
>> 
>> --- vframeStreamCommon::security_get_caller_frame
>> This now does something odd if depth < 0.  Suggest an assert.
> 
> The behavior with depth < 0 in the current code is even worse.  An assert is a good idea.  As discussed I want to remove that method in the future because its uses are dubious.

I forgot to update the webrev.  Here you go:

http://cr.openjdk.java.net/~twisti/7198429/

-- Chris



From weijun.wang at oracle.com  Sat Mar 23 03:50:00 2013
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Sat, 23 Mar 2013 03:50:00 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130323035033.632B54836B@hg.openjdk.java.net>

Changeset: 3470101fae58
Author:    weijun
Date:      2013-03-23 11:49 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3470101fae58

8009970: Several LoginModule classes need extra permission to load AuthResources
Reviewed-by: mullan

! src/share/classes/com/sun/security/auth/module/JndiLoginModule.java
! src/share/classes/com/sun/security/auth/module/KeyStoreLoginModule.java
! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java

Changeset: ed63cace1d30
Author:    weijun
Date:      2013-03-23 11:49 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ed63cace1d30

8009875: Provide a default udp_preference_limit for krb5.conf
Reviewed-by: valeriep

! src/share/classes/sun/security/krb5/KdcComm.java
! src/share/classes/sun/security/krb5/internal/Krb5.java
! test/sun/security/krb5/auto/KDC.java
+ test/sun/security/krb5/config/DefUdpLimit.java



From chris.hegarty at oracle.com  Sat Mar 23 08:47:27 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Sat, 23 Mar 2013 08:47:27 +0000
Subject: Request for review fix for 8010668
In-Reply-To: <514CC6F1.7050109@oracle.com>
References: <514CC6F1.7050109@oracle.com>
Message-ID: <514D6C1F.8020601@oracle.com>

Looks fine to me Bill.

-Chris.

On 03/22/2013 09:02 PM, BILL PITTORE wrote:
> This fixes a problem with the recently committed changes for JNI static
> libraries. On an error condition or explicit unload request, statically
> linked libs should not be unloaded.
>
> http://cr.openjdk.java.net/~bpittore/8010668/webrev.00/
>
> thanks,
> bill
>
>


From dl at cs.oswego.edu  Sat Mar 23 11:08:34 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Sat, 23 Mar 2013 07:08:34 -0400
Subject: RFR 8005696: Add CompletableFuture - JEP 155
In-Reply-To: <51489817.7070809@oracle.com>
References: <5142070C.6000709@oracle.com>
	
	<51430D6B.4060601@cs.oswego.edu> <5143258A.9020906@oracle.com>
	<5147206B.4060001@cs.oswego.edu> <51489817.7070809@oracle.com>
Message-ID: <514D8D32.1020104@cs.oswego.edu>


There was a signature mismatch between the public
   public static CompletableFuture anyOf(CompletableFuture... cfs)
and the internal method performing most of the work:
   private static CompletableFuture anyTree(...)
("" and "" are subtly different.) Similarly for allOf.
Now fixed in our CVS. It required a bunch of other adjustments
to get this to compile without warnings. None of it affects public API.

-Doug


On 03/19/13 12:53, Chris Hegarty wrote:
> Updated specdiff and webrev. Unless I hear otherwise, I think the API is as good
> as final.
>
>
> http://cr.openjdk.java.net/~chegar/8005696/ver.01/specdiff/java/util/concurrent/package-summary.html
>
>    http://cr.openjdk.java.net/~chegar/8005696/ver.01/webrev/
>



From Alan.Bateman at oracle.com  Sat Mar 23 11:15:42 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 23 Mar 2013 11:15:42 +0000
Subject: Request for review fix for 8010668
In-Reply-To: <514CC6F1.7050109@oracle.com>
References: <514CC6F1.7050109@oracle.com>
Message-ID: <514D8EDE.3070202@oracle.com>

On 22/03/2013 21:02, BILL PITTORE wrote:
> This fixes a problem with the recently committed changes for JNI 
> static libraries. On an error condition or explicit unload request, 
> statically linked libs should not be unloaded.
>
> http://cr.openjdk.java.net/~bpittore/8010668/webrev.00/
>
> thanks,
> bill
This looks good to me too, sorry we missed this when reviewing the 
original changes.

-Alan.


From david.holmes at oracle.com  Mon Mar 25 01:34:48 2013
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 25 Mar 2013 11:34:48 +1000
Subject: Request for review fix for 8010668
In-Reply-To: <514D8EDE.3070202@oracle.com>
References: <514CC6F1.7050109@oracle.com> <514D8EDE.3070202@oracle.com>
Message-ID: <514FA9B8.204@oracle.com>

On 23/03/2013 9:15 PM, Alan Bateman wrote:
> On 22/03/2013 21:02, BILL PITTORE wrote:
>> This fixes a problem with the recently committed changes for JNI
>> static libraries. On an error condition or explicit unload request,
>> statically linked libs should not be unloaded.
>>
>> http://cr.openjdk.java.net/~bpittore/8010668/webrev.00/
>>
>> thanks,
>> bill
> This looks good to me too, sorry we missed this when reviewing the
> original changes.

I am curious as to the lifecycle of a statically linked library. When 
would we "load" and "unload" it? Can we actually attempt to run the 
load/unload hooks multiple times ?

David

> -Alan.


From sundararajan.athijegannathan at oracle.com  Mon Mar 25 06:42:40 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Mon, 25 Mar 2013 06:42:40 +0000
Subject: hg: jdk8/tl/nashorn: 3 new changesets
Message-ID: <20130325064243.334A64839B@hg.openjdk.java.net>

Changeset: 3b0a0d9d51f0
Author:    sundar
Date:      2013-03-18 21:03 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/3b0a0d9d51f0

8010199: javax.script.Invocable implementation for nashorn does not return null when matching functions are missing
Reviewed-by: lagergren, jlaskey

! bin/jjs
! bin/jjssecure
! bin/nashorn
! bin/nashornsecure
! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
+ test/script/basic/JDK-8010199.js
! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java

Changeset: 606a1946e3e2
Author:    jlaskey
Date:      2013-03-19 11:03 -0300
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/606a1946e3e2

8009969: CodeCoverage should use template
Reviewed-by: jlaskey, sundar
Contributed-by: pavel.stepanov at oracle.com

! make/build.xml
! make/code_coverage.xml
! make/project.properties

Changeset: 4be452026847
Author:    attila
Date:      2013-03-23 00:58 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/4be452026847

8010652: Eliminate non-child references in Block/FunctionNode, and make few node types immutable
Reviewed-by: jlaskey, lagergren

! make/project.properties
! src/jdk/nashorn/internal/codegen/Attr.java
! src/jdk/nashorn/internal/codegen/ClassEmitter.java
! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/codegen/CompilationPhase.java
! src/jdk/nashorn/internal/codegen/Compiler.java
! src/jdk/nashorn/internal/codegen/FinalizeTypes.java
! src/jdk/nashorn/internal/codegen/FoldConstants.java
! src/jdk/nashorn/internal/codegen/FunctionSignature.java
! src/jdk/nashorn/internal/codegen/Lower.java
! src/jdk/nashorn/internal/codegen/MethodEmitter.java
! src/jdk/nashorn/internal/codegen/Splitter.java
! src/jdk/nashorn/internal/codegen/WeighNodes.java
! src/jdk/nashorn/internal/ir/AccessNode.java
! src/jdk/nashorn/internal/ir/Assignment.java
! src/jdk/nashorn/internal/ir/BaseNode.java
! src/jdk/nashorn/internal/ir/BinaryNode.java
! src/jdk/nashorn/internal/ir/Block.java
! src/jdk/nashorn/internal/ir/BreakNode.java
! src/jdk/nashorn/internal/ir/CallNode.java
! src/jdk/nashorn/internal/ir/CaseNode.java
! src/jdk/nashorn/internal/ir/CatchNode.java
! src/jdk/nashorn/internal/ir/ContinueNode.java
! src/jdk/nashorn/internal/ir/DoWhileNode.java
! src/jdk/nashorn/internal/ir/EmptyNode.java
! src/jdk/nashorn/internal/ir/ExecuteNode.java
! src/jdk/nashorn/internal/ir/ForNode.java
! src/jdk/nashorn/internal/ir/FunctionNode.java
! src/jdk/nashorn/internal/ir/IdentNode.java
! src/jdk/nashorn/internal/ir/IfNode.java
! src/jdk/nashorn/internal/ir/IndexNode.java
! src/jdk/nashorn/internal/ir/LabelNode.java
+ src/jdk/nashorn/internal/ir/LexicalContext.java
! src/jdk/nashorn/internal/ir/LineNumberNode.java
! src/jdk/nashorn/internal/ir/LiteralNode.java
! src/jdk/nashorn/internal/ir/Location.java
! src/jdk/nashorn/internal/ir/Node.java
! src/jdk/nashorn/internal/ir/ObjectNode.java
! src/jdk/nashorn/internal/ir/PropertyNode.java
- src/jdk/nashorn/internal/ir/ReferenceNode.java
! src/jdk/nashorn/internal/ir/ReturnNode.java
! src/jdk/nashorn/internal/ir/RuntimeNode.java
! src/jdk/nashorn/internal/ir/SplitNode.java
! src/jdk/nashorn/internal/ir/SwitchNode.java
! src/jdk/nashorn/internal/ir/Symbol.java
! src/jdk/nashorn/internal/ir/TernaryNode.java
! src/jdk/nashorn/internal/ir/ThrowNode.java
! src/jdk/nashorn/internal/ir/TryNode.java
! src/jdk/nashorn/internal/ir/TypeOverride.java
! src/jdk/nashorn/internal/ir/UnaryNode.java
! src/jdk/nashorn/internal/ir/VarNode.java
! src/jdk/nashorn/internal/ir/WhileNode.java
! src/jdk/nashorn/internal/ir/WithNode.java
! src/jdk/nashorn/internal/ir/debug/JSONWriter.java
! src/jdk/nashorn/internal/ir/debug/PrintVisitor.java
! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java
! src/jdk/nashorn/internal/ir/visitor/NodeVisitor.java
! src/jdk/nashorn/internal/parser/Parser.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/resources/Messages.properties
! test/script/basic/JDK-8006755.js
! test/script/basic/NASHORN-837.js
! test/src/jdk/nashorn/internal/codegen/CompilerTest.java



From daniel.fuchs at oracle.com  Mon Mar 25 11:45:30 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 25 Mar 2013 12:45:30 +0100
Subject: JDK-8010495: Update JAXP NetBeans project - add support for generating
	javadoc
Message-ID: <515038DA.3010802@oracle.com>

Hi guys,

I'd like to propose a small change to jaxp/build.xml and
jaxp/nbproject/project.xml - in order to allow editing
JAXP sources in NetBeans, as well as generating the JAXP
javadoc for previewing purposes.

I actually stole the javadoc target from
jdk/make/netbeans/common/shared.xml

The changes are small & targeted at developers.
There should be no impact on the build process.

Here is the webrev:

http://cr.openjdk.java.net/~dfuchs/JDK-8010495/jdk8/webrev.00/

best regards,

-- daniel


From peter.levart at gmail.com  Mon Mar 25 11:46:45 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 25 Mar 2013 12:46:45 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due
	to HashMap leads to Integer allocations (boxing)
In-Reply-To: <514C859D.1050705@gmail.com>
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com> <514B2E8D.8060701@gmail.com>
	<514B92A7.1000305@oracle.com>
	
	<514C2C94.60700@gmail.com>
	
	<514C4E09.3020008@gmail.com> <514C5C8D.1090406@gmail.com>
	<514C859D.1050705@gmail.com>
Message-ID: <51503925.1020403@gmail.com>

Hi Laurent, Mandy,

MethodHandles.guardWithCheck() rocks!

Out of curiosity, I put the MethodHandles in latest JDK8 build to the 
test. It turns out that they are surprisingly good. I optimized the 
dispatch logic of the most critical method: 
PlatformLogger.isLoggable(int) which I have shown in previous mail, is 
performance-dependent on whether java.util.logging is enabled from the 
beginning so that the dispatch is compiled by JIT into an in-lined 
monomorphic call or it is enabled later-on when the code has already 
been warmed-up using LoggerProxy. The method's performance drops by 
factor of 3 in the later situation.

Here's what I did:

http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.mh.01/index.html

The benchmark results are as follows (only showing the patched 
PlatformLogger - for original code results, refer to previous mail or 
see below quoted message):

** Patched code (webrev.mh.01)

 >> JVM START
#
# isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
#
# Warm up:
            1 threads, Tavg =      1.40 ns/op (? =   0.00 ns/op) [     1.40]
            1 threads, Tavg =      1.39 ns/op (? =   0.00 ns/op) [     1.39]
# Measure:
            1 threads, Tavg =      1.42 ns/op (? =   0.00 ns/op) [     1.42]
            2 threads, Tavg =      1.31 ns/op (? =   0.00 ns/op) [     
1.31,      1.31]
            3 threads, Tavg =      1.43 ns/op (? =   0.20 ns/op) [     
1.74,      1.32,      1.32]
            4 threads, Tavg =      1.34 ns/op (? =   0.01 ns/op) [     
1.35,      1.35,      1.33,      1.35]

<< JVM END

 >> JVM START

 >> java.util.logging enabled

#
# isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
#
# Warm up:
            1 threads, Tavg =      1.69 ns/op (? =   0.00 ns/op) [     1.69]
            1 threads, Tavg =      1.77 ns/op (? =   0.00 ns/op) [     1.77]
# Measure:
            1 threads, Tavg =      1.73 ns/op (? =   0.00 ns/op) [     1.73]
            2 threads, Tavg =      1.73 ns/op (? =   0.00 ns/op) [     
1.72,      1.73]
            3 threads, Tavg =      1.97 ns/op (? =   0.49 ns/op) [     
2.74,      1.72,      1.73]
            4 threads, Tavg =      1.80 ns/op (? =   0.05 ns/op) [     
1.83,      1.73,      1.79,      1.87]

<< JVM END

 >> JVM START
#
# isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
#
# Warm up:
            1 threads, Tavg =      1.35 ns/op (? =   0.00 ns/op) [     1.35]
            1 threads, Tavg =      1.74 ns/op (? =   0.00 ns/op) [     1.74]
# Measure:
            1 threads, Tavg =      1.33 ns/op (? =   0.00 ns/op) [     1.33]
            2 threads, Tavg =      1.44 ns/op (? =   0.00 ns/op) [     
1.44,      1.44]
            3 threads, Tavg =      1.28 ns/op (? =   0.01 ns/op) [     
1.30,      1.27,      1.29]
            4 threads, Tavg =      1.31 ns/op (? =   0.03 ns/op) [     
1.34,      1.27,      1.29,      1.33]


 >> java.util.logging enabled

#
# isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
#
# Warm up:
            1 threads, Tavg =      2.04 ns/op (? =   0.00 ns/op) [     2.04]
            1 threads, Tavg =      2.04 ns/op (? =   0.00 ns/op) [     2.04]
# Measure:
            1 threads, Tavg =      2.04 ns/op (? =   0.00 ns/op) [     2.04]
            2 threads, Tavg =      2.04 ns/op (? =   0.00 ns/op) [     
2.04,      2.04]
            3 threads, Tavg =      2.04 ns/op (? =   0.00 ns/op) [     
2.04,      2.03,      2.04]
            4 threads, Tavg =      2.04 ns/op (? =   0.00 ns/op) [     
2.04,      2.04,      2.04,      2.05]

<< JVM END


There's still a small drop in speed when "the switch to 
java.util.logging" happens, but it's negligible. So compared to original 
code, with both optimizations combined, the speed-up is 2.6x - 4.5x 
(depending on test).

I don't know how this performs on JDK7 though, so perhaps a backport 
should not use MethodHandles.

Regards, Peter

On 03/22/2013 05:23 PM, Peter Levart wrote:
> Hi Laurent,
>
> I have run your performance test on my machine (i7 CPU, Linux) and 
> with original code on JDK8 64bit (CompressedOOPS enabled by default, 
> no TLAB options), i get:
>
> ...
> INFO: testPerf[100000000 iterations]: duration = 1767.6329779999999 ms.
> INFO: testPerf[100000000 iterations]: duration = 1758.7931449999999 ms.
> INFO: testPerf[100000000 iterations]: duration = 1763.386362 ms.
> ...
>
> While with latest patch (webrev.07), the results are:
>
> ...
> INFO: testPerf[100000000 iterations]: duration = 660.940466 ms.
> INFO: testPerf[100000000 iterations]: duration = 662.4854379999999 ms.
> INFO: testPerf[100000000 iterations]: duration = 656.497199 ms.
> ...
>
>
> So it's apparently a 2.5x improvement in speed.
>
> This test is designed to test the PlatformLogger.isLoggable() for 
> levels that don't result in log messages being actually written out, 
> but there are some caveats:
>
> - the test is using a loop with local variables and counters, which is 
> very prone to JIT optimizations such as loop-unrolling. This might or 
> might not be happening and even if it is, the impact might be the same 
> on unpatched vs. patched PlatformLogger code.
> - the test is testing the performance when the PlatformLogger is 
> directed to java.util.logging from the beginning. That means JIT is 
> compiling calls to virtual methods of JavaLoggerProxy into monomorphic 
> inlined calls. The results are different if the test is 1st warmed-up 
> while no java.util.logging is initialized yet (calls directed to 
> LoggerProxy) and later java.util.logging is enabled (PlatformLoggers 
> are redirected to JavaLoggerProxys) and the same test repeated.
>
> I have created a special test that demonstrates this (all tests run on 
> recent JDK8 build, i7 (4 cores) Linux, 64bit, no TLAB option, 
> CompressedOOPS enabled by default):
>
> ** Original code
>
> >> JVM START
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      1.78 ns/op (? = 0.00 ns/op) [     1.78]
>            1 threads, Tavg =      1.67 ns/op (? = 0.00 ns/op) [     1.67]
> # Measure:
>            1 threads, Tavg =      1.44 ns/op (? = 0.00 ns/op) [     1.44]
>            2 threads, Tavg =      1.37 ns/op (? = 0.01 ns/op) [     
> 1.37,      1.38]
>            3 threads, Tavg =      1.53 ns/op (? = 0.13 ns/op) [     
> 1.41,      1.49,      1.71]
>            4 threads, Tavg =      1.43 ns/op (? = 0.10 ns/op) [     
> 1.36,      1.62,      1.39,      1.38]
>
> << JVM END
>
> >> JVM START
>
> >> java.util.logging enabled
>
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      4.81 ns/op (? = 0.00 ns/op) [     4.81]
>            1 threads, Tavg =      4.79 ns/op (? = 0.00 ns/op) [     4.79]
> # Measure:
>            1 threads, Tavg =      4.67 ns/op (? = 0.00 ns/op) [     4.67]
>            2 threads, Tavg =      4.67 ns/op (? = 0.00 ns/op) [     
> 4.67,      4.67]
>            3 threads, Tavg =      4.87 ns/op (? = 0.31 ns/op) [     
> 4.67,      4.68,      5.32]
>            4 threads, Tavg =      4.68 ns/op (? = 0.01 ns/op) [     
> 4.68,      4.67,      4.68,      4.69]
>
> << JVM END
>
> >> JVM START
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      1.39 ns/op (? = 0.00 ns/op) [     1.39]
>            1 threads, Tavg =      1.80 ns/op (? = 0.00 ns/op) [     1.80]
> # Measure:
>            1 threads, Tavg =      1.38 ns/op (? = 0.00 ns/op) [     1.38]
>            2 threads, Tavg =      1.38 ns/op (? = 0.00 ns/op) [     
> 1.38,      1.38]
>            3 threads, Tavg =      1.38 ns/op (? = 0.01 ns/op) [     
> 1.39,      1.38,      1.37]
>            4 threads, Tavg =      1.38 ns/op (? = 0.02 ns/op) [     
> 1.42,      1.37,      1.37,      1.37]
>
>
> >> java.util.logging enabled
>
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =     11.87 ns/op (? = 0.00 ns/op) [    11.87]
>            1 threads, Tavg =      9.08 ns/op (? = 0.00 ns/op) [     9.08]
> # Measure:
>            1 threads, Tavg =      9.12 ns/op (? = 0.00 ns/op) [     9.12]
>            2 threads, Tavg =      9.02 ns/op (? = 0.02 ns/op) [     
> 9.05,      9.00]
>            3 threads, Tavg =      9.20 ns/op (? = 0.04 ns/op) [     
> 9.26,      9.19,      9.17]
>            4 threads, Tavg =      9.33 ns/op (? = 0.07 ns/op) [     
> 9.44,      9.34,      9.26,      9.28]
>
> << JVM END
>
>
> ** Patched code (webrev.07)
>
> >> JVM START
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      1.38 ns/op (? = 0.00 ns/op) [     1.38]
>            1 threads, Tavg =      1.68 ns/op (? = 0.00 ns/op) [     1.68]
> # Measure:
>            1 threads, Tavg =      1.38 ns/op (? = 0.00 ns/op) [     1.38]
>            2 threads, Tavg =      1.40 ns/op (? = 0.02 ns/op) [     
> 1.37,      1.42]
>            3 threads, Tavg =      1.49 ns/op (? = 0.21 ns/op) [     
> 1.80,      1.38,      1.36]
>            4 threads, Tavg =      1.50 ns/op (? = 0.13 ns/op) [     
> 1.47,      1.73,      1.41,      1.42]
>
> << JVM END
>
> >> JVM START
>
> >> java.util.logging enabled
>
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      1.80 ns/op (? = 0.00 ns/op) [     1.80]
>            1 threads, Tavg =      1.74 ns/op (? = 0.00 ns/op) [     1.74]
> # Measure:
>            1 threads, Tavg =      1.78 ns/op (? = 0.00 ns/op) [     1.78]
>            2 threads, Tavg =      1.80 ns/op (? = 0.00 ns/op) [     
> 1.80,      1.80]
>            3 threads, Tavg =      1.84 ns/op (? = 0.03 ns/op) [     
> 1.80,      1.88,      1.86]
>            4 threads, Tavg =      1.78 ns/op (? = 0.00 ns/op) [     
> 1.78,      1.77,      1.77,      1.78]
>
> << JVM END
>
> >> JVM START
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      1.73 ns/op (? = 0.00 ns/op) [     1.73]
>            1 threads, Tavg =      1.72 ns/op (? = 0.00 ns/op) [     1.72]
> # Measure:
>            1 threads, Tavg =      1.38 ns/op (? = 0.00 ns/op) [     1.38]
>            2 threads, Tavg =      1.37 ns/op (? = 0.00 ns/op) [     
> 1.37,      1.37]
>            3 threads, Tavg =      1.52 ns/op (? = 0.19 ns/op) [     
> 1.37,      1.45,      1.79]
>            4 threads, Tavg =      1.58 ns/op (? = 0.19 ns/op) [     
> 1.42,      1.79,      1.81,      1.41]
>
>
> >> java.util.logging enabled
>
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      5.43 ns/op (? = 0.00 ns/op) [     5.43]
>            1 threads, Tavg =      5.65 ns/op (? = 0.00 ns/op) [     5.65]
> # Measure:
>            1 threads, Tavg =      5.66 ns/op (? = 0.00 ns/op) [     5.66]
>            2 threads, Tavg =      5.67 ns/op (? = 0.01 ns/op) [     
> 5.68,      5.66]
>            3 threads, Tavg =      5.65 ns/op (? = 0.00 ns/op) [     
> 5.65,      5.65,      5.65]
>            4 threads, Tavg =      5.66 ns/op (? = 0.01 ns/op) [     
> 5.65,      5.65,      5.67,      5.67]
>
> << JVM END
>
>
> It appears the speed-up is visible and varies from 1.6x to 2.6x, 
> depending on other factors that also play role in the overall speed 
> (like JIT optimizations).
>
> I only presented the results for PlatformLogger.isLoggable(FINEST), 
> because this is the most sensitive call in tight loops. Other methods 
> perform similarly.
>
> This is the test code I used:
>
>
> package test;
>
> import si.pele.microbench.TestRunner;
> import sun.util.logging.PlatformLogger;
>
> import java.util.logging.LogManager;
>
> public class PlatformLoggerBenchmark extends TestRunner {
>
>     static final PlatformLogger log = 
> PlatformLogger.getLogger(PlatformLoggerBenchmark.class.getName());
>
>     static {
>         log.setLevel(PlatformLogger.SEVERE); // almost OFF
>     }
>
>     public static class isLoggableFinest extends Test {
>         @Override
>         protected void doLoop(Loop loop, DevNull devNull1, DevNull 
> devNull2, DevNull devNull3, DevNull devNull4, DevNull devNull5) {
>             while (loop.nextIteration()) {
> devNull1.yield(log.isLoggable(PlatformLogger.FINEST));
>             }
>         }
>     }
>
>     public static void main(String[] args) throws Exception {
>
>         System.out.println(">> JVM START");
>
>         doTest(isLoggableFinest.class, 5000L, 1, 4, 1);
>
>         // enable java.util.logging
> LogManager.getLogManager().getLogger(log.getName());
>         System.out.println("\n>> java.util.logging enabled\n");
>
>         doTest(isLoggableFinest.class, 5000L, 1, 4, 1);
>
>         System.out.println("<< JVM END");
>     }
> }
>
>
> The test uses a simple microbenchmark runner that I coded together 
> using some ideas from the sessions with Alexey Shipilev and his 
> benchmark suite.
>
> Here's the source to my dirty implementation:
>
> https://github.com/plevart/micro-bench/tree/v2
>
>
> Regards, Peter
>
> On 03/22/2013 02:28 PM, Peter Levart wrote:
>> Ok, Lauret, Mandy,
>>
>> Here are the final touches:
>>
>> https://dl.dropboxusercontent.com/u/101777488/jdk8-tl/PlatformLogger/webrev.07/index.html
>>
>> Changes from webrev.06:
>>
>> - renamed back Level -> LevelEnum
>> - renamed JavaLogger -> JavaLoggerProxy
>> - moved javaLevel(int) static method from LevelEnum to 
>> JavaLoggerProxy and made it private (only used there)
>> - consistent use of variable name 'level' to refer to 
>> PlatformLogger's int level value
>> - consistent use of variable name 'levelEnum' to refer to LevelEnum 
>> member
>> - consistent use of variable name 'javaLevel' to refer to 
>> java.util.logging.Level instance
>> - consistent use of variable name 'javaLogger' to refer to 
>> java.util.logging.Logger instance
>> - renamed PlatformLogger.newJavaLogger() private method -> 
>> PlatformLogger.redirectToJavaLoggerProxy()
>> - renamed PlatformLogger.logger private field -> 
>> PlatformLogger.loggerProxy
>> - some additional comments
>>
>> I think that these changes make code more consistent and 
>> self-explanatory.
>>
>> What remains is a possible rename from: javaLogger, javaLevel, 
>> JavaLoggerProxy -> julLogger, julLevel, JulLoggerProxy if that's the 
>> final decision.
>>
>> Regards, Peter
>>
>>
>> On 03/22/2013 01:26 PM, Peter Levart wrote:
>>> On 03/22/2013 11:34 AM, Laurent Bourg?s wrote:
>>>> Peter,
>>>>
>>>>     You've beaten me! I have been preparing them too ;-) ...
>>>>
>>>>
>>>> Ok I definitely stop working on the code and let you do it.
>>>
>>> Ok. I'll make the final touches, incorporating also comments and 
>>> changes from your code...
>>>
>>>>
>>>>     I also did some some renames, that I think make the code more
>>>>     consistent:
>>>>     - LevelEnum -> Level (the code is not dependent on
>>>>     java.util.logging.Level, so the name can be reused, its private
>>>>     anyway)
>>>>     - julLevel -> javaLevel (javaLevel / JavaLogger)
>>>>     - LevelEnum.forValue -> Level.valueOf (Mandy)
>>>>     - JavaLogger.julLevelToEnum -> JavaLogger.javaLevelToLevel
>>>>
>>>>
>>>> For consistency and clarity, I would prefer having following 
>>>> conventions:
>>>> - int levelValue (= PlatformLevel as int) and not int level 
>>>> (conflict with Level enum ...)
>>>
>>> I think that PlatformLogger public API should stay as is. Public 
>>> method's parameter names are just called 'level' and values of 
>>> public constants are expected to be passed to them. There are only 
>>> two places where 'level' is the name of a local variable of type 
>>> Level (and not int) and at both places there is not conflict, since 
>>> there's no 'int level' variable in scope.
>>>
>>> I renamed LevelEnum to Level because the following most frequently 
>>> used pattern looks strange:
>>>
>>>     LevelEnum.javaLevel(int)
>>>
>>> Neither parameter nor the result has anything to do with LevelEnum 
>>> directly.
>>>
>>> But if we move the javaLevel(int) method out of the Level enum into 
>>> the JavaLogger, then Level can be renamed back to LevelEnum (or 
>>> anything else?).
>>>
>>>
>>>> - julLevel / julLogger: more explicit than javaLevel / javaLogger 
>>>> (java means everything  ... but jul means java.util.logging and 
>>>> javaLogger is in conflict with JavaLogger class)
>>>
>>>
>>> But javaLogger is not in conflict with javaLevel. I suggest renaming 
>>> JavaLoger class to JavaLoggerProxy, so we would have:
>>>
>>> Object javaLogger // holding java.util.logging.Logger instance
>>> Object javaLevel    // holding java.util.logging.Level instance
>>>
>>> class JavaLoggerProxy  // a specialization of LoggerProxy, 
>>> delegating to javaLogger
>>>
>>> If 'jul' is a prefered prefix to 'java', I suggest renaming all 3: 
>>> julLogger, julLevel, JulLoggerProxy. I don't have a preference for 
>>> either, so perhaps Mandy, Laurent or anybody else can express them...
>>>
>>>
>>> Regards, Peter
>>>
>>>>
>>>>     Other changes (to webrev.05):
>>>>     - removed the occurrence counts in switch comments (as per
>>>>     Mandy's suggestion)
>>>>     - made LoggerProxy and JavaLogger private
>>>>     - fixed double-read of volatile LoggerProxy.levelValue in
>>>>     LoggerProxy.isLoggable()
>>>>     - added static Level.javaLevel(int value) shortcut (Mandy)
>>>>
>>>>     I also updated the test to exercise the correctness of mappings.
>>>>
>>>>
>>>> Well done.
>>>>
>>>> cheers,
>>>> Laurent
>>>>
>>>
>>
>



From sundararajan.athijegannathan at oracle.com  Mon Mar 25 13:55:29 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Mon, 25 Mar 2013 13:55:29 +0000
Subject: hg: jdk8/tl/jdk: 8010704: The test
	closed/java/lang/SecurityManager/CheckPackageDefinition.java
	failed after fix for 8009869
Message-ID: <20130325135608.10B40483A9@hg.openjdk.java.net>

Changeset: d92a96dcbfe1
Author:    sundar
Date:      2013-03-25 19:25 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d92a96dcbfe1

8010704: The test closed/java/lang/SecurityManager/CheckPackageDefinition.java failed after fix for 8009869
Reviewed-by: lagergren, hannesw

! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-solaris



From bourges.laurent at gmail.com  Mon Mar 25 14:24:47 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Mon, 25 Mar 2013 15:24:47 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due to
	HashMap leads to Integer allocations (boxing)
In-Reply-To: <51503925.1020403@gmail.com>
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com> <514B2E8D.8060701@gmail.com>
	<514B92A7.1000305@oracle.com>
	
	<514C2C94.60700@gmail.com>
	
	<514C4E09.3020008@gmail.com> <514C5C8D.1090406@gmail.com>
	<514C859D.1050705@gmail.com> <51503925.1020403@gmail.com>
Message-ID: 

Hi Peter,

thanks for your microbench tool !
It works well and avoid me to do my own (caliper is a well known one)

I do not know what MethodHandle is but its performance is impressive !

Here are my results (Oracle jdk 1.7_13 vs OpenJDK 8 patched):

java -Xms8m -Xmx8m

JDK 1.7_13

run:
>> JVM START
#
# isLoggableFinest: run duration:  5 000 ms, #of logical CPUS: 4
#
# Warm up:
           1 threads, Tavg =      1,75 ns/op (? =   0,00 ns/op) [     1,75]
           1 threads, Tavg =      1,75 ns/op (? =   0,00 ns/op) [     1,75]
# Measure:
           1 threads, Tavg =      1,80 ns/op (? =   0,00 ns/op) [     1,80]
           2 threads, Tavg =      1,99 ns/op (? =   0,01 ns/op) [
2,00,      1,98]


>> java.util.logging enabled

#
# isLoggableFinest: run duration:  5 000 ms, #of logical CPUS: 4
#
# Warm up:
           1 threads, Tavg =     26,41 ns/op (? =   0,00 ns/op) [    26,41]
           1 threads, Tavg =     25,86 ns/op (? =   0,00 ns/op) [    25,86]
# Measure:
           1 threads, Tavg =     26,90 ns/op (? =   0,00 ns/op) [    26,90]
           2 threads, Tavg =     30,07 ns/op (? =   0,20 ns/op) [
30,27,     29,87]

<< JVM END
BUILD SUCCESSFUL (total time: 40 seconds)

jdk 1.8 patched

run:
>> JVM START
#
# isLoggableFinest: run duration:  5 000 ms, #of logical CPUS: 4
#
# Warm up:
           1 threads, Tavg =      1,77 ns/op (? =   0,00 ns/op) [     1,77]
           1 threads, Tavg =      1,77 ns/op (? =   0,00 ns/op) [     1,77]
# Measure:
           1 threads, Tavg =      1,75 ns/op (? =   0,00 ns/op) [     1,75]
           2 threads, Tavg =      2,01 ns/op (? =   0,01 ns/op) [
2,00,      2,01]


>> java.util.logging enabled

#
# isLoggableFinest: run duration:  5 000 ms, #of logical CPUS: 4
#
# Warm up:
           1 threads, Tavg =      7,64 ns/op (? =   0,00 ns/op) [     7,64]
           1 threads, Tavg =      7,57 ns/op (? =   0,00 ns/op) [     7,57]
# Measure:
           1 threads, Tavg =      7,62 ns/op (? =   0,00 ns/op) [     7,62]
           2 threads, Tavg =      9,92 ns/op (? =   0,58 ns/op) [
10,53,      9,37]

<< JVM END
BUILD SUCCESSFUL (total time: 40 seconds)


JUL started before PlatformLogger:

run:
mars 23, 2013 9:09:00 PM PlatformLoggerBenchmark 
Infos: JUL started
mars 23, 2013 9:09:00 PM PlatformLoggerBenchmark 
>> JVM START
Grave: PlatformLogger started
#
# isLoggableFinest: run duration:  5 000 ms, #of logical CPUS: 4
#
# Warm up:
           1 threads, Tavg =      3,51 ns/op (? =   0,00 ns/op) [     3,51]
           1 threads, Tavg =      3,49 ns/op (? =   0,00 ns/op) [     3,49]
# Measure:
           1 threads, Tavg =      3,50 ns/op (? =   0,00 ns/op) [     3,50]
           2 threads, Tavg =      3,83 ns/op (? =   0,02 ns/op) [
3,82,      3,85]


>> java.util.logging enabled

#
# isLoggableFinest: run duration:  5 000 ms, #of logical CPUS: 4
#
# Warm up:
           1 threads, Tavg =      3,50 ns/op (? =   0,00 ns/op) [     3,50]
           1 threads, Tavg =      3,50 ns/op (? =   0,00 ns/op) [     3,50]
# Measure:
           1 threads, Tavg =      3,50 ns/op (? =   0,00 ns/op) [     3,50]
           2 threads, Tavg =      3,90 ns/op (? =   0,03 ns/op) [
3,87,      3,93]

<< JVM END
BUILD SUCCESSFUL (total time: 40 seconds)

I will test on OpenJDK8 (no patch) to see the impact on my machine (slower
than yours).

Laurent


From chris.hegarty at oracle.com  Mon Mar 25 14:30:18 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Mon, 25 Mar 2013 14:30:18 +0000
Subject: hg: jdk8/tl/jdk: 8010668: builtin JNI libraries should not be unloaded
Message-ID: <20130325143042.9F4E2483AB@hg.openjdk.java.net>

Changeset: 5d0c891264bf
Author:    chegar
Date:      2013-03-25 14:29 +0000
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5d0c891264bf

8010668: builtin JNI libraries should not be unloaded
Reviewed-by: chegar, alanb
Contributed-by: Bill Pittore 

! src/share/native/java/lang/ClassLoader.c



From bill.pittore at oracle.com  Mon Mar 25 15:19:58 2013
From: bill.pittore at oracle.com (BILL PITTORE)
Date: Mon, 25 Mar 2013 11:19:58 -0400
Subject: Request for review fix for 8010668
In-Reply-To: <514D8EDE.3070202@oracle.com>
References: <514CC6F1.7050109@oracle.com> <514D8EDE.3070202@oracle.com>
Message-ID: <51506B1E.6050509@oracle.com>

Thanks for the review and thanks to Chris for pushing it.

bill

On 3/23/2013 7:15 AM, Alan Bateman wrote:
> On 22/03/2013 21:02, BILL PITTORE wrote:
>> This fixes a problem with the recently committed changes for JNI 
>> static libraries. On an error condition or explicit unload request, 
>> statically linked libs should not be unloaded.
>>
>> http://cr.openjdk.java.net/~bpittore/8010668/webrev.00/
>>
>> thanks,
>> bill
> This looks good to me too, sorry we missed this when reviewing the 
> original changes.
>
> -Alan.




From huizhe.wang at oracle.com  Mon Mar 25 16:20:22 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 25 Mar 2013 09:20:22 -0700
Subject: JDK-8010495: Update JAXP NetBeans project - add support for
	generating javadoc
In-Reply-To: <515038DA.3010802@oracle.com>
References: <515038DA.3010802@oracle.com>
Message-ID: <51507946.6050400@oracle.com>

Hi Daniel,

Thanks for doing this.

JAXP doesn't have these packages: "java/", "org/ietf/jgss/", and 
"org/omg/".  Since this is the jaxp repo, it would be fine if only 
'javax/' and 'org/' are included, or 'com/' be excluded.

Regards,
Joe

On 3/25/2013 4:45 AM, Daniel Fuchs wrote:
> Hi guys,
>
> I'd like to propose a small change to jaxp/build.xml and
> jaxp/nbproject/project.xml - in order to allow editing
> JAXP sources in NetBeans, as well as generating the JAXP
> javadoc for previewing purposes.
>
> I actually stole the javadoc target from
> jdk/make/netbeans/common/shared.xml
>
> The changes are small & targeted at developers.
> There should be no impact on the build process.
>
> Here is the webrev:
>
> http://cr.openjdk.java.net/~dfuchs/JDK-8010495/jdk8/webrev.00/
>
> best regards,
>
> -- daniel



From peter.levart at gmail.com  Mon Mar 25 16:31:28 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 25 Mar 2013 17:31:28 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due
	to HashMap leads to Integer allocations (boxing)
In-Reply-To: <51503925.1020403@gmail.com>
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com> <514B2E8D.8060701@gmail.com>
	<514B92A7.1000305@oracle.com>
	
	<514C2C94.60700@gmail.com>
	
	<514C4E09.3020008@gmail.com> <514C5C8D.1090406@gmail.com>
	<514C859D.1050705@gmail.com> <51503925.1020403@gmail.com>
Message-ID: <51507BE0.6000502@gmail.com>

Well, Laurent, Mandy,

It turns out that the dispatch speed-up (or lack of slow-down to be 
precise) is possible without MethodHandles too. Maybe some VM guru could 
shed some light on this, but the following is currently the fastest variant:

http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.08/index.html

What I did is a simple "if" deciding between two call-sites, making sure 
that each is only dispatching to single class. This only works, if both 
classes (LoggerProxy and JavaLoggerProxy) are loaded in advance, before 
1st invocation on any of them is made (might be that using MethodHandles 
forced initialization of both classes beforehand and hence the 
speed-up). If I don't load JavaLoggerProxy before warming-up with 
LoggerProxy, then when j.u.logging is enabled, speed drops for a factor 
of almost 4 and never catches up even after very long time.
This pre-loading also helps for a normal single call site dispatch that 
dispatches to two distinct classes, but the speed 1st drops when the 
class changes, and only catches-up after several billions of iterations 
(30s tight loop on i7).
Now, because JavaLoggerProxy is initialized early, I had to move the 
initialization of j.u.logging.Level objects and mappings to a separate 
class "JavaLevel".

Here are the benchmark results for this last iteration...

When j.u.logging is enabled from the beginning:

** Patched code (webrev.08)

 >> JVM START

 >> java.util.logging enabled

#
# isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
#
# Warm up:
            1 threads, Tavg =      1.62 ns/op (? =   0.00 ns/op) [     1.62]
            1 threads, Tavg =      1.64 ns/op (? =   0.00 ns/op) [     1.64]
# Measure:
            1 threads, Tavg =      1.62 ns/op (? =   0.00 ns/op) [     1.62]
            2 threads, Tavg =      1.60 ns/op (? =   0.00 ns/op) [     
1.60,      1.60]
            3 threads, Tavg =      1.60 ns/op (? =   0.00 ns/op) [     
1.60,      1.60,      1.60]
            4 threads, Tavg =      1.61 ns/op (? =   0.01 ns/op) [     
1.60,      1.62,      1.60,      1.61]

<< JVM END


And when it first runs with j.u.logging disabled and is enabled in the 
middle:


 >> JVM START
#
# isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
#
# Warm up:
            1 threads, Tavg =      1.33 ns/op (? =   0.00 ns/op) [     1.33]
            1 threads, Tavg =      1.36 ns/op (? =   0.00 ns/op) [     1.36]
# Measure:
            1 threads, Tavg =      1.36 ns/op (? =   0.00 ns/op) [     1.36]
            2 threads, Tavg =      1.30 ns/op (? =   0.04 ns/op) [     
1.34,      1.25]
            3 threads, Tavg =      1.29 ns/op (? =   0.06 ns/op) [     
1.37,      1.25,      1.27]
            4 threads, Tavg =      1.32 ns/op (? =   0.10 ns/op) [     
1.24,      1.25,      1.31,      1.49]


 >> java.util.logging enabled

#
# isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
#
# Warm up:
            1 threads, Tavg =      1.74 ns/op (? =   0.00 ns/op) [     1.74]
            1 threads, Tavg =      1.73 ns/op (? =   0.00 ns/op) [     1.73]
# Measure:
            1 threads, Tavg =      1.57 ns/op (? =   0.00 ns/op) [     1.57]
            2 threads, Tavg =      1.57 ns/op (? =   0.00 ns/op) [     
1.58,      1.57]
            3 threads, Tavg =      1.58 ns/op (? =   0.00 ns/op) [     
1.57,      1.58,      1.57]
            4 threads, Tavg =      1.59 ns/op (? =   0.01 ns/op) [     
1.61,      1.58,      1.58,      1.59]

<< JVM END


It can be seen that performance is stable as it does not change a bit if 
the "switch" occurs at start or in the middle.

With this patch, we have a 2.9x - 5.7x speed-up compared to original 
code (depending on test).

Laurent, can you try this one on your machine? Would be fine to see also 
the webrev.07 tested on your machine (I'm curious if this 
slow-down-due-to-deoptimization also happens on your environment and 
what the impact is).

Regards, Peter


On 03/25/2013 12:46 PM, Peter Levart wrote:
> Hi Laurent, Mandy,
>
> MethodHandles.guardWithCheck() rocks!
>
> Out of curiosity, I put the MethodHandles in latest JDK8 build to the 
> test. It turns out that they are surprisingly good. I optimized the 
> dispatch logic of the most critical method: 
> PlatformLogger.isLoggable(int) which I have shown in previous mail, is 
> performance-dependent on whether java.util.logging is enabled from the 
> beginning so that the dispatch is compiled by JIT into an in-lined 
> monomorphic call or it is enabled later-on when the code has already 
> been warmed-up using LoggerProxy. The method's performance drops by 
> factor of 3 in the later situation.
>
> Here's what I did:
>
> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.mh.01/index.html
>
> The benchmark results are as follows (only showing the patched 
> PlatformLogger - for original code results, refer to previous mail or 
> see below quoted message):
>
> ** Patched code (webrev.mh.01)
>
> >> JVM START
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      1.40 ns/op (? = 0.00 ns/op) [     1.40]
>            1 threads, Tavg =      1.39 ns/op (? = 0.00 ns/op) [     1.39]
> # Measure:
>            1 threads, Tavg =      1.42 ns/op (? = 0.00 ns/op) [     1.42]
>            2 threads, Tavg =      1.31 ns/op (? = 0.00 ns/op) [     
> 1.31,      1.31]
>            3 threads, Tavg =      1.43 ns/op (? = 0.20 ns/op) [     
> 1.74,      1.32,      1.32]
>            4 threads, Tavg =      1.34 ns/op (? = 0.01 ns/op) [     
> 1.35,      1.35,      1.33,      1.35]
>
> << JVM END
>
> >> JVM START
>
> >> java.util.logging enabled
>
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      1.69 ns/op (? = 0.00 ns/op) [     1.69]
>            1 threads, Tavg =      1.77 ns/op (? = 0.00 ns/op) [     1.77]
> # Measure:
>            1 threads, Tavg =      1.73 ns/op (? = 0.00 ns/op) [     1.73]
>            2 threads, Tavg =      1.73 ns/op (? = 0.00 ns/op) [     
> 1.72,      1.73]
>            3 threads, Tavg =      1.97 ns/op (? = 0.49 ns/op) [     
> 2.74,      1.72,      1.73]
>            4 threads, Tavg =      1.80 ns/op (? = 0.05 ns/op) [     
> 1.83,      1.73,      1.79,      1.87]
>
> << JVM END
>
> >> JVM START
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      1.35 ns/op (? = 0.00 ns/op) [     1.35]
>            1 threads, Tavg =      1.74 ns/op (? = 0.00 ns/op) [     1.74]
> # Measure:
>            1 threads, Tavg =      1.33 ns/op (? = 0.00 ns/op) [     1.33]
>            2 threads, Tavg =      1.44 ns/op (? = 0.00 ns/op) [     
> 1.44,      1.44]
>            3 threads, Tavg =      1.28 ns/op (? = 0.01 ns/op) [     
> 1.30,      1.27,      1.29]
>            4 threads, Tavg =      1.31 ns/op (? = 0.03 ns/op) [     
> 1.34,      1.27,      1.29,      1.33]
>
>
> >> java.util.logging enabled
>
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      2.04 ns/op (? = 0.00 ns/op) [     2.04]
>            1 threads, Tavg =      2.04 ns/op (? = 0.00 ns/op) [     2.04]
> # Measure:
>            1 threads, Tavg =      2.04 ns/op (? = 0.00 ns/op) [     2.04]
>            2 threads, Tavg =      2.04 ns/op (? = 0.00 ns/op) [     
> 2.04,      2.04]
>            3 threads, Tavg =      2.04 ns/op (? = 0.00 ns/op) [     
> 2.04,      2.03,      2.04]
>            4 threads, Tavg =      2.04 ns/op (? = 0.00 ns/op) [     
> 2.04,      2.04,      2.04,      2.05]
>
> << JVM END
>
>
> There's still a small drop in speed when "the switch to 
> java.util.logging" happens, but it's negligible. So compared to 
> original code, with both optimizations combined, the speed-up is 2.6x 
> - 4.5x (depending on test).
>
> I don't know how this performs on JDK7 though, so perhaps a backport 
> should not use MethodHandles.
>
> Regards, Peter
>
> On 03/22/2013 05:23 PM, Peter Levart wrote:
>> Hi Laurent,
>>
>> I have run your performance test on my machine (i7 CPU, Linux) and 
>> with original code on JDK8 64bit (CompressedOOPS enabled by default, 
>> no TLAB options), i get:
>>
>> ...
>> INFO: testPerf[100000000 iterations]: duration = 1767.6329779999999 ms.
>> INFO: testPerf[100000000 iterations]: duration = 1758.7931449999999 ms.
>> INFO: testPerf[100000000 iterations]: duration = 1763.386362 ms.
>> ...
>>
>> While with latest patch (webrev.07), the results are:
>>
>> ...
>> INFO: testPerf[100000000 iterations]: duration = 660.940466 ms.
>> INFO: testPerf[100000000 iterations]: duration = 662.4854379999999 ms.
>> INFO: testPerf[100000000 iterations]: duration = 656.497199 ms.
>> ...
>>
>>
>> So it's apparently a 2.5x improvement in speed.
>>
>> This test is designed to test the PlatformLogger.isLoggable() for 
>> levels that don't result in log messages being actually written out, 
>> but there are some caveats:
>>
>> - the test is using a loop with local variables and counters, which 
>> is very prone to JIT optimizations such as loop-unrolling. This might 
>> or might not be happening and even if it is, the impact might be the 
>> same on unpatched vs. patched PlatformLogger code.
>> - the test is testing the performance when the PlatformLogger is 
>> directed to java.util.logging from the beginning. That means JIT is 
>> compiling calls to virtual methods of JavaLoggerProxy into 
>> monomorphic inlined calls. The results are different if the test is 
>> 1st warmed-up while no java.util.logging is initialized yet (calls 
>> directed to LoggerProxy) and later java.util.logging is enabled 
>> (PlatformLoggers are redirected to JavaLoggerProxys) and the same 
>> test repeated.
>>
>> I have created a special test that demonstrates this (all tests run 
>> on recent JDK8 build, i7 (4 cores) Linux, 64bit, no TLAB option, 
>> CompressedOOPS enabled by default):
>>
>> ** Original code
>>
>> >> JVM START
>> #
>> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
>> #
>> # Warm up:
>>            1 threads, Tavg =      1.78 ns/op (? = 0.00 ns/op) [     1.78]
>>            1 threads, Tavg =      1.67 ns/op (? = 0.00 ns/op) [     1.67]
>> # Measure:
>>            1 threads, Tavg =      1.44 ns/op (? = 0.00 ns/op) [     1.44]
>>            2 threads, Tavg =      1.37 ns/op (? = 0.01 ns/op) [     
>> 1.37,      1.38]
>>            3 threads, Tavg =      1.53 ns/op (? = 0.13 ns/op) [     
>> 1.41,      1.49,      1.71]
>>            4 threads, Tavg =      1.43 ns/op (? = 0.10 ns/op) [     
>> 1.36,      1.62,      1.39,      1.38]
>>
>> << JVM END
>>
>> >> JVM START
>>
>> >> java.util.logging enabled
>>
>> #
>> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
>> #
>> # Warm up:
>>            1 threads, Tavg =      4.81 ns/op (? = 0.00 ns/op) [     4.81]
>>            1 threads, Tavg =      4.79 ns/op (? = 0.00 ns/op) [     4.79]
>> # Measure:
>>            1 threads, Tavg =      4.67 ns/op (? = 0.00 ns/op) [     4.67]
>>            2 threads, Tavg =      4.67 ns/op (? = 0.00 ns/op) [     
>> 4.67,      4.67]
>>            3 threads, Tavg =      4.87 ns/op (? = 0.31 ns/op) [     
>> 4.67,      4.68,      5.32]
>>            4 threads, Tavg =      4.68 ns/op (? = 0.01 ns/op) [     
>> 4.68,      4.67,      4.68,      4.69]
>>
>> << JVM END
>>
>> >> JVM START
>> #
>> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
>> #
>> # Warm up:
>>            1 threads, Tavg =      1.39 ns/op (? = 0.00 ns/op) [     1.39]
>>            1 threads, Tavg =      1.80 ns/op (? = 0.00 ns/op) [     1.80]
>> # Measure:
>>            1 threads, Tavg =      1.38 ns/op (? = 0.00 ns/op) [     1.38]
>>            2 threads, Tavg =      1.38 ns/op (? = 0.00 ns/op) [     
>> 1.38,      1.38]
>>            3 threads, Tavg =      1.38 ns/op (? = 0.01 ns/op) [     
>> 1.39,      1.38,      1.37]
>>            4 threads, Tavg =      1.38 ns/op (? = 0.02 ns/op) [     
>> 1.42,      1.37,      1.37,      1.37]
>>
>>
>> >> java.util.logging enabled
>>
>> #
>> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
>> #
>> # Warm up:
>>            1 threads, Tavg =     11.87 ns/op (? = 0.00 ns/op) [    11.87]
>>            1 threads, Tavg =      9.08 ns/op (? = 0.00 ns/op) [     9.08]
>> # Measure:
>>            1 threads, Tavg =      9.12 ns/op (? = 0.00 ns/op) [     9.12]
>>            2 threads, Tavg =      9.02 ns/op (? = 0.02 ns/op) [     
>> 9.05,      9.00]
>>            3 threads, Tavg =      9.20 ns/op (? = 0.04 ns/op) [     
>> 9.26,      9.19,      9.17]
>>            4 threads, Tavg =      9.33 ns/op (? = 0.07 ns/op) [     
>> 9.44,      9.34,      9.26,      9.28]
>>
>> << JVM END
>>
>>
>> ** Patched code (webrev.07)
>>
>> >> JVM START
>> #
>> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
>> #
>> # Warm up:
>>            1 threads, Tavg =      1.38 ns/op (? = 0.00 ns/op) [     1.38]
>>            1 threads, Tavg =      1.68 ns/op (? = 0.00 ns/op) [     1.68]
>> # Measure:
>>            1 threads, Tavg =      1.38 ns/op (? = 0.00 ns/op) [     1.38]
>>            2 threads, Tavg =      1.40 ns/op (? = 0.02 ns/op) [     
>> 1.37,      1.42]
>>            3 threads, Tavg =      1.49 ns/op (? = 0.21 ns/op) [     
>> 1.80,      1.38,      1.36]
>>            4 threads, Tavg =      1.50 ns/op (? = 0.13 ns/op) [     
>> 1.47,      1.73,      1.41,      1.42]
>>
>> << JVM END
>>
>> >> JVM START
>>
>> >> java.util.logging enabled
>>
>> #
>> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
>> #
>> # Warm up:
>>            1 threads, Tavg =      1.80 ns/op (? = 0.00 ns/op) [     1.80]
>>            1 threads, Tavg =      1.74 ns/op (? = 0.00 ns/op) [     1.74]
>> # Measure:
>>            1 threads, Tavg =      1.78 ns/op (? = 0.00 ns/op) [     1.78]
>>            2 threads, Tavg =      1.80 ns/op (? = 0.00 ns/op) [     
>> 1.80,      1.80]
>>            3 threads, Tavg =      1.84 ns/op (? = 0.03 ns/op) [     
>> 1.80,      1.88,      1.86]
>>            4 threads, Tavg =      1.78 ns/op (? = 0.00 ns/op) [     
>> 1.78,      1.77,      1.77,      1.78]
>>
>> << JVM END
>>
>> >> JVM START
>> #
>> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
>> #
>> # Warm up:
>>            1 threads, Tavg =      1.73 ns/op (? = 0.00 ns/op) [     1.73]
>>            1 threads, Tavg =      1.72 ns/op (? = 0.00 ns/op) [     1.72]
>> # Measure:
>>            1 threads, Tavg =      1.38 ns/op (? = 0.00 ns/op) [     1.38]
>>            2 threads, Tavg =      1.37 ns/op (? = 0.00 ns/op) [     
>> 1.37,      1.37]
>>            3 threads, Tavg =      1.52 ns/op (? = 0.19 ns/op) [     
>> 1.37,      1.45,      1.79]
>>            4 threads, Tavg =      1.58 ns/op (? = 0.19 ns/op) [     
>> 1.42,      1.79,      1.81,      1.41]
>>
>>
>> >> java.util.logging enabled
>>
>> #
>> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
>> #
>> # Warm up:
>>            1 threads, Tavg =      5.43 ns/op (? = 0.00 ns/op) [     5.43]
>>            1 threads, Tavg =      5.65 ns/op (? = 0.00 ns/op) [     5.65]
>> # Measure:
>>            1 threads, Tavg =      5.66 ns/op (? = 0.00 ns/op) [     5.66]
>>            2 threads, Tavg =      5.67 ns/op (? = 0.01 ns/op) [     
>> 5.68,      5.66]
>>            3 threads, Tavg =      5.65 ns/op (? = 0.00 ns/op) [     
>> 5.65,      5.65,      5.65]
>>            4 threads, Tavg =      5.66 ns/op (? = 0.01 ns/op) [     
>> 5.65,      5.65,      5.67,      5.67]
>>
>> << JVM END
>>
>>
>> It appears the speed-up is visible and varies from 1.6x to 2.6x, 
>> depending on other factors that also play role in the overall speed 
>> (like JIT optimizations).
>>
>> I only presented the results for PlatformLogger.isLoggable(FINEST), 
>> because this is the most sensitive call in tight loops. Other methods 
>> perform similarly.
>>
>> This is the test code I used:
>>
>>
>> package test;
>>
>> import si.pele.microbench.TestRunner;
>> import sun.util.logging.PlatformLogger;
>>
>> import java.util.logging.LogManager;
>>
>> public class PlatformLoggerBenchmark extends TestRunner {
>>
>>     static final PlatformLogger log = 
>> PlatformLogger.getLogger(PlatformLoggerBenchmark.class.getName());
>>
>>     static {
>>         log.setLevel(PlatformLogger.SEVERE); // almost OFF
>>     }
>>
>>     public static class isLoggableFinest extends Test {
>>         @Override
>>         protected void doLoop(Loop loop, DevNull devNull1, DevNull 
>> devNull2, DevNull devNull3, DevNull devNull4, DevNull devNull5) {
>>             while (loop.nextIteration()) {
>> devNull1.yield(log.isLoggable(PlatformLogger.FINEST));
>>             }
>>         }
>>     }
>>
>>     public static void main(String[] args) throws Exception {
>>
>>         System.out.println(">> JVM START");
>>
>>         doTest(isLoggableFinest.class, 5000L, 1, 4, 1);
>>
>>         // enable java.util.logging
>> LogManager.getLogManager().getLogger(log.getName());
>>         System.out.println("\n>> java.util.logging enabled\n");
>>
>>         doTest(isLoggableFinest.class, 5000L, 1, 4, 1);
>>
>>         System.out.println("<< JVM END");
>>     }
>> }
>>
>>
>> The test uses a simple microbenchmark runner that I coded together 
>> using some ideas from the sessions with Alexey Shipilev and his 
>> benchmark suite.
>>
>> Here's the source to my dirty implementation:
>>
>> https://github.com/plevart/micro-bench/tree/v2
>>
>>
>> Regards, Peter
>>
>> On 03/22/2013 02:28 PM, Peter Levart wrote:
>>> Ok, Lauret, Mandy,
>>>
>>> Here are the final touches:
>>>
>>> https://dl.dropboxusercontent.com/u/101777488/jdk8-tl/PlatformLogger/webrev.07/index.html
>>>
>>> Changes from webrev.06:
>>>
>>> - renamed back Level -> LevelEnum
>>> - renamed JavaLogger -> JavaLoggerProxy
>>> - moved javaLevel(int) static method from LevelEnum to 
>>> JavaLoggerProxy and made it private (only used there)
>>> - consistent use of variable name 'level' to refer to 
>>> PlatformLogger's int level value
>>> - consistent use of variable name 'levelEnum' to refer to LevelEnum 
>>> member
>>> - consistent use of variable name 'javaLevel' to refer to 
>>> java.util.logging.Level instance
>>> - consistent use of variable name 'javaLogger' to refer to 
>>> java.util.logging.Logger instance
>>> - renamed PlatformLogger.newJavaLogger() private method -> 
>>> PlatformLogger.redirectToJavaLoggerProxy()
>>> - renamed PlatformLogger.logger private field -> 
>>> PlatformLogger.loggerProxy
>>> - some additional comments
>>>
>>> I think that these changes make code more consistent and 
>>> self-explanatory.
>>>
>>> What remains is a possible rename from: javaLogger, javaLevel, 
>>> JavaLoggerProxy -> julLogger, julLevel, JulLoggerProxy if that's the 
>>> final decision.
>>>
>>> Regards, Peter
>>>
>>>
>>> On 03/22/2013 01:26 PM, Peter Levart wrote:
>>>> On 03/22/2013 11:34 AM, Laurent Bourg?s wrote:
>>>>> Peter,
>>>>>
>>>>>     You've beaten me! I have been preparing them too ;-) ...
>>>>>
>>>>>
>>>>> Ok I definitely stop working on the code and let you do it.
>>>>
>>>> Ok. I'll make the final touches, incorporating also comments and 
>>>> changes from your code...
>>>>
>>>>>
>>>>>     I also did some some renames, that I think make the code more
>>>>>     consistent:
>>>>>     - LevelEnum -> Level (the code is not dependent on
>>>>>     java.util.logging.Level, so the name can be reused, its
>>>>>     private anyway)
>>>>>     - julLevel -> javaLevel (javaLevel / JavaLogger)
>>>>>     - LevelEnum.forValue -> Level.valueOf (Mandy)
>>>>>     - JavaLogger.julLevelToEnum -> JavaLogger.javaLevelToLevel
>>>>>
>>>>>
>>>>> For consistency and clarity, I would prefer having following 
>>>>> conventions:
>>>>> - int levelValue (= PlatformLevel as int) and not int level 
>>>>> (conflict with Level enum ...)
>>>>
>>>> I think that PlatformLogger public API should stay as is. Public 
>>>> method's parameter names are just called 'level' and values of 
>>>> public constants are expected to be passed to them. There are only 
>>>> two places where 'level' is the name of a local variable of type 
>>>> Level (and not int) and at both places there is not conflict, since 
>>>> there's no 'int level' variable in scope.
>>>>
>>>> I renamed LevelEnum to Level because the following most frequently 
>>>> used pattern looks strange:
>>>>
>>>>     LevelEnum.javaLevel(int)
>>>>
>>>> Neither parameter nor the result has anything to do with LevelEnum 
>>>> directly.
>>>>
>>>> But if we move the javaLevel(int) method out of the Level enum into 
>>>> the JavaLogger, then Level can be renamed back to LevelEnum (or 
>>>> anything else?).
>>>>
>>>>
>>>>> - julLevel / julLogger: more explicit than javaLevel / javaLogger 
>>>>> (java means everything  ... but jul means java.util.logging and 
>>>>> javaLogger is in conflict with JavaLogger class)
>>>>
>>>>
>>>> But javaLogger is not in conflict with javaLevel. I suggest 
>>>> renaming JavaLoger class to JavaLoggerProxy, so we would have:
>>>>
>>>> Object javaLogger // holding java.util.logging.Logger instance
>>>> Object javaLevel    // holding java.util.logging.Level instance
>>>>
>>>> class JavaLoggerProxy  // a specialization of LoggerProxy, 
>>>> delegating to javaLogger
>>>>
>>>> If 'jul' is a prefered prefix to 'java', I suggest renaming all 3: 
>>>> julLogger, julLevel, JulLoggerProxy. I don't have a preference for 
>>>> either, so perhaps Mandy, Laurent or anybody else can express them...
>>>>
>>>>
>>>> Regards, Peter
>>>>
>>>>>
>>>>>     Other changes (to webrev.05):
>>>>>     - removed the occurrence counts in switch comments (as per
>>>>>     Mandy's suggestion)
>>>>>     - made LoggerProxy and JavaLogger private
>>>>>     - fixed double-read of volatile LoggerProxy.levelValue in
>>>>>     LoggerProxy.isLoggable()
>>>>>     - added static Level.javaLevel(int value) shortcut (Mandy)
>>>>>
>>>>>     I also updated the test to exercise the correctness of mappings.
>>>>>
>>>>>
>>>>> Well done.
>>>>>
>>>>> cheers,
>>>>> Laurent
>>>>>
>>>>
>>>
>>
>



From daniel.fuchs at oracle.com  Mon Mar 25 16:35:08 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 25 Mar 2013 17:35:08 +0100
Subject: JDK-8010495: Update JAXP NetBeans project - add support for
	generating javadoc
In-Reply-To: <51507946.6050400@oracle.com>
References: <515038DA.3010802@oracle.com> <51507946.6050400@oracle.com>
Message-ID: <51507CBC.1070904@oracle.com>

On 3/25/13 5:20 PM, huizhe wang wrote:
> Hi Daniel,
>
> Thanks for doing this.
>
> JAXP doesn't have these packages: "java/", "org/ietf/jgss/", and
> "org/omg/".  Since this is the jaxp repo, it would be fine if only
> 'javax/' and 'org/' are included, or 'com/' be excluded.

OK - I just copied the pattern shared by all
jdk/make/netbeans projects - but I guess I can safely restrict
the list to what is actually present in JAXP.

That would make it:

  203             
  204                 
  205
  206                     
  207
  208
  209                     
  210                     
  211                 


-- daniel

>
> Regards,
> Joe
>
> On 3/25/2013 4:45 AM, Daniel Fuchs wrote:
>> Hi guys,
>>
>> I'd like to propose a small change to jaxp/build.xml and
>> jaxp/nbproject/project.xml - in order to allow editing
>> JAXP sources in NetBeans, as well as generating the JAXP
>> javadoc for previewing purposes.
>>
>> I actually stole the javadoc target from
>> jdk/make/netbeans/common/shared.xml
>>
>> The changes are small & targeted at developers.
>> There should be no impact on the build process.
>>
>> Here is the webrev:
>>
>> http://cr.openjdk.java.net/~dfuchs/JDK-8010495/jdk8/webrev.00/
>>
>> best regards,
>>
>> -- daniel
>



From huizhe.wang at oracle.com  Mon Mar 25 16:52:10 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 25 Mar 2013 09:52:10 -0700
Subject: JDK-8010495: Update JAXP NetBeans project - add support for
	generating javadoc
In-Reply-To: <51507CBC.1070904@oracle.com>
References: <515038DA.3010802@oracle.com> <51507946.6050400@oracle.com>
	<51507CBC.1070904@oracle.com>
Message-ID: <515080BA.3090000@oracle.com>


On 3/25/2013 9:35 AM, Daniel Fuchs wrote:
> On 3/25/13 5:20 PM, huizhe wang wrote:
>> Hi Daniel,
>>
>> Thanks for doing this.
>>
>> JAXP doesn't have these packages: "java/", "org/ietf/jgss/", and
>> "org/omg/".  Since this is the jaxp repo, it would be fine if only
>> 'javax/' and 'org/' are included, or 'com/' be excluded.
>
> OK - I just copied the pattern shared by all
> jdk/make/netbeans projects - but I guess I can safely restrict
> the list to what is actually present in JAXP.
>
> That would make it:
>
>  203                                   includes="${includes}" excludes="${excludes}">
>  204                 
>  205
>  206                     
>  207
>  208
>  209                     
>  210                     
>  211                 

I'm not familiar with this usage. Does the 'includes' attribute take 
precedence over the package names in  tags?  Will they be ignored 
since 'includes' includes all packages.

-Joe

>
>
> -- daniel
>
>>
>> Regards,
>> Joe
>>
>> On 3/25/2013 4:45 AM, Daniel Fuchs wrote:
>>> Hi guys,
>>>
>>> I'd like to propose a small change to jaxp/build.xml and
>>> jaxp/nbproject/project.xml - in order to allow editing
>>> JAXP sources in NetBeans, as well as generating the JAXP
>>> javadoc for previewing purposes.
>>>
>>> I actually stole the javadoc target from
>>> jdk/make/netbeans/common/shared.xml
>>>
>>> The changes are small & targeted at developers.
>>> There should be no impact on the build process.
>>>
>>> Here is the webrev:
>>>
>>> http://cr.openjdk.java.net/~dfuchs/JDK-8010495/jdk8/webrev.00/
>>>
>>> best regards,
>>>
>>> -- daniel
>>
>



From dmitry.samersoff at oracle.com  Mon Mar 25 17:11:33 2013
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Mon, 25 Mar 2013 21:11:33 +0400
Subject: RFR: Project files for Solaris Studio / NetBeans
In-Reply-To: <51507B60.6030809@oracle.com>
References: <51507B60.6030809@oracle.com>
Message-ID: <51508545.6040102@oracle.com>

Jesper,

Tryed to apply your patch as I'm quite inetresting to have really
working NB project for jdk and hotspot.

1. Directory structure looks strange (see screenshot1)

2. netbeans doesn't work for JDK tests (see screenshot2) -

   netbeans doesn't pick files
   from test directory (JDK-only project have the same issue)

   netbeans doesn't pick changes from files in JDK tree - i.e
   if I add/change class name in JDK tree, netbeans still treated it
   as unresolved within test (JDK-only project have the same issue)

-Dmitry



On 2013-03-25 20:29, Jesper Wilhelmsson wrote:
> Hi,
> 
> Sorry for cross posting, but I think this could be useful for several
> areas.
> 
> I would like to add Solaris Studio / NetBeans project files for the
> entire OpenJDK project. To clarify: One project that contains the entire
> OpenJDK.
> 
> 
> With the new build infrastructure in JDK 8 building the entire OpenJDK
> is fairly fast and even though I personally mostly work in the HotSpot
> tree, I tend to always clone and build the entire JDK forest. I find
> this to have several benefits.
> 
> Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/
> 
> The configuration in this project is currently Mac only. Linux and
> Solaris configurations are also planned.
> 
> The webrev is made from the jdk8/build repository which is where I think
> a change like this should go in. Let me know if you think something else.
> 
> 
> 
> To use this project (once pushed):
> 
> 1. Clone your favorite repository
>    hg clone http://hg.openjdk.java.net/hsx/hotspot-gc
> 
> 2. Get the whole forest
>    cd hotspot-gc
>    sh get_source.sh
> 
> 3. Configure
>    sh configure
> 
> 4. Open Solaris studio / NetBeans and load the project.
>    The project in located in the common directory.
> 
> 
> Thanks,
> /Jesper


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer

From dmitry.samersoff at oracle.com  Mon Mar 25 17:11:54 2013
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Mon, 25 Mar 2013 21:11:54 +0400
Subject: RFR: Project files for Solaris Studio / NetBeans
In-Reply-To: <51507B60.6030809@oracle.com>
References: <51507B60.6030809@oracle.com>
Message-ID: <5150855A.9020909@oracle.com>

Jesper,

Tried to apply your patch as I'm quite interesting to have really
working NB project for jdk and hotspot.

1. Directory structure looks strange (see screenshot1)

2. netbeans doesn't work for JDK tests (see screenshot2) -

   netbeans doesn't pick files
   from test directory (JDK-only project have the same issue)

   netbeans doesn't pick changes from files in JDK tree - i.e
   if I add/change class name in JDK tree, netbeans still treated it
   as unresolved within test (JDK-only project have the same issue)

-Dmitry



On 2013-03-25 20:29, Jesper Wilhelmsson wrote:
> Hi,
> 
> Sorry for cross posting, but I think this could be useful for several
> areas.
> 
> I would like to add Solaris Studio / NetBeans project files for the
> entire OpenJDK project. To clarify: One project that contains the entire
> OpenJDK.
> 
> 
> With the new build infrastructure in JDK 8 building the entire OpenJDK
> is fairly fast and even though I personally mostly work in the HotSpot
> tree, I tend to always clone and build the entire JDK forest. I find
> this to have several benefits.
> 
> Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/
> 
> The configuration in this project is currently Mac only. Linux and
> Solaris configurations are also planned.
> 
> The webrev is made from the jdk8/build repository which is where I think
> a change like this should go in. Let me know if you think something else.
> 
> 
> 
> To use this project (once pushed):
> 
> 1. Clone your favorite repository
>    hg clone http://hg.openjdk.java.net/hsx/hotspot-gc
> 
> 2. Get the whole forest
>    cd hotspot-gc
>    sh get_source.sh
> 
> 3. Configure
>    sh configure
> 
> 4. Open Solaris studio / NetBeans and load the project.
>    The project in located in the common directory.
> 
> 
> Thanks,
> /Jesper


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer

From volker.simonis at gmail.com  Mon Mar 25 17:15:11 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 25 Mar 2013 18:15:11 +0100
Subject: RFR: Project files for Solaris Studio / NetBeans
In-Reply-To: <51507B60.6030809@oracle.com>
References: <51507B60.6030809@oracle.com>
Message-ID: 

Hi Jesper,

first of all I highly welcome your initiative!

Nevertheless I have some questions:

- Who will support these project files? As far as I can see, they will
have to be updated at least every time a file will be added, renamed
or deleted. Experience shows that such kind of project files tend to
get outdated very fast. Do you have any ideas how this problem can be
addressed?
- Where will other platform configurations go to? Will they be all
stored in "configurations.xml"
- What about other configurations (i.e. DEBUG, PRODUCT, 32/64bit,
CC_INTERP, etc..)? Will they all have to go into the same
"configurations.xml"

It seems that the "configurations.xml" might get quite big and complex
with all these configurations.

Thank you and best regards,
Volker

On Mon, Mar 25, 2013 at 5:29 PM, Jesper Wilhelmsson
 wrote:
> Hi,
>
> Sorry for cross posting, but I think this could be useful for several areas.
>
> I would like to add Solaris Studio / NetBeans project files for the entire
> OpenJDK project. To clarify: One project that contains the entire OpenJDK.
>
>
> With the new build infrastructure in JDK 8 building the entire OpenJDK is
> fairly fast and even though I personally mostly work in the HotSpot tree, I
> tend to always clone and build the entire JDK forest. I find this to have
> several benefits.
>
> Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/
>
> The configuration in this project is currently Mac only. Linux and Solaris
> configurations are also planned.
>
> The webrev is made from the jdk8/build repository which is where I think a
> change like this should go in. Let me know if you think something else.
>
>
>
> To use this project (once pushed):
>
> 1. Clone your favorite repository
>    hg clone http://hg.openjdk.java.net/hsx/hotspot-gc
>
> 2. Get the whole forest
>    cd hotspot-gc
>    sh get_source.sh
>
> 3. Configure
>    sh configure
>
> 4. Open Solaris studio / NetBeans and load the project.
>    The project in located in the common directory.
>
>
> Thanks,
> /Jesper


From bourges.laurent at gmail.com  Mon Mar 25 17:33:11 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Mon, 25 Mar 2013 18:33:11 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due to
	HashMap leads to Integer allocations (boxing)
In-Reply-To: <51507BE0.6000502@gmail.com>
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com> <514B2E8D.8060701@gmail.com>
	<514B92A7.1000305@oracle.com>
	
	<514C2C94.60700@gmail.com>
	
	<514C4E09.3020008@gmail.com> <514C5C8D.1090406@gmail.com>
	<514C859D.1050705@gmail.com> <51503925.1020403@gmail.com>
	<51507BE0.6000502@gmail.com>
Message-ID: 

Peter,

Here are the results
Sorry I have no performance gain !

maybe I should use java server VM ?

Any idea ?

java -Xms8m -Xmx8m

jdk7_13

>> JVM START: 1.7.0_13 [Java HotSpot(TM) 64-Bit Server VM 23.7-b01]
SEVERE: PlatformLogger started
#
# isLoggableFinest: run duration:  5 000 ms, #of logical CPUS: 4
#
# Warm up:
           1 threads, Tavg =      1,75 ns/op (? =   0,00 ns/op) [     1,75]
           1 threads, Tavg =      1,75 ns/op (? =   0,00 ns/op) [     1,75]
# Measure:
           1 threads, Tavg =      1,76 ns/op (? =   0,00 ns/op) [     1,76]
           2 threads, Tavg =      2,02 ns/op (? =   0,00 ns/op) [
2,02,      2,01]


>> java.util.logging enabled

#
# isLoggableFinest: run duration:  5 000 ms, #of logical CPUS: 4
#
# Warm up:
           1 threads, Tavg =     28,17 ns/op (? =   0,00 ns/op) [    28,17]
           1 threads, Tavg =     20,17 ns/op (? =   0,00 ns/op) [    20,17]
# Measure:
           1 threads, Tavg =     19,15 ns/op (? =   0,00 ns/op) [    19,15]
           2 threads, Tavg =     23,99 ns/op (? =   0,09 ns/op) [
23,90,     24,09]

<< JVM END
BUILD SUCCESSFUL (total time: 40 seconds)
jdk 1.8 patched (webrev.08):

>> JVM START: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
SEVERE: PlatformLogger started
#
# isLoggableFinest: run duration:  5 000 ms, #of logical CPUS: 4
#
# Warm up:
           1 threads, Tavg =      1,75 ns/op (? =   0,00 ns/op) [     1,75]
           1 threads, Tavg =      1,75 ns/op (? =   0,00 ns/op) [     1,75]
# Measure:
           1 threads, Tavg =      1,75 ns/op (? =   0,00 ns/op) [     1,75]
           2 threads, Tavg =      2,01 ns/op (? =   0,02 ns/op) [
2,00,      2,03]


>> java.util.logging enabled

#
# isLoggableFinest: run duration:  5 000 ms, #of logical CPUS: 4
#
# Warm up:
           1 threads, Tavg =      7,60 ns/op (? =   0,00 ns/op) [     7,60]
           1 threads, Tavg =      7,58 ns/op (? =   0,00 ns/op) [     7,58]
# Measure:
           1 threads, Tavg =      7,63 ns/op (? =   0,00 ns/op) [     7,63]
           2 threads, Tavg =      9,89 ns/op (? =   0,08 ns/op) [
9,82,      9,97]

<< JVM END
BUILD SUCCESSFUL (total time: 40 seconds)


2013/3/25 Peter Levart 

>  Well, Laurent, Mandy,
>
> It turns out that the dispatch speed-up (or lack of slow-down to be
> precise) is possible without MethodHandles too. Maybe some VM guru could
> shed some light on this, but the following is currently the fastest variant:
>
>
> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.08/index.html
>
> What I did is a simple "if" deciding between two call-sites, making sure
> that each is only dispatching to single class. This only works, if both
> classes (LoggerProxy and JavaLoggerProxy) are loaded in advance, before 1st
> invocation on any of them is made (might be that using MethodHandles forced
> initialization of both classes beforehand and hence the speed-up). If I
> don't load JavaLoggerProxy before warming-up with LoggerProxy, then when
> j.u.logging is enabled, speed drops for a factor of almost 4 and never
> catches up even after very long time.
> This pre-loading also helps for a normal single call site dispatch that
> dispatches to two distinct classes, but the speed 1st drops when the class
> changes, and only catches-up after several billions of iterations (30s
> tight loop on i7).
> Now, because JavaLoggerProxy is initialized early, I had to move the
> initialization of j.u.logging.Level objects and mappings to a separate
> class "JavaLevel".
>
> Here are the benchmark results for this last iteration...
>
> When j.u.logging is enabled from the beginning:
>
> ** Patched code (webrev.08)
>
>
> >> JVM START
>
> >> java.util.logging enabled
>
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      1.62 ns/op (? =   0.00 ns/op) [     1.62]
>            1 threads, Tavg =      1.64 ns/op (? =   0.00 ns/op) [     1.64]
> # Measure:
>            1 threads, Tavg =      1.62 ns/op (? =   0.00 ns/op) [     1.62]
>            2 threads, Tavg =      1.60 ns/op (? =   0.00 ns/op) [
> 1.60,      1.60]
>            3 threads, Tavg =      1.60 ns/op (? =   0.00 ns/op) [
> 1.60,      1.60,      1.60]
>            4 threads, Tavg =      1.61 ns/op (? =   0.01 ns/op) [
> 1.60,      1.62,      1.60,      1.61]
>
> << JVM END
>
>
> And when it first runs with j.u.logging disabled and is enabled in the
> middle:
>
>
>
> >> JVM START
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      1.33 ns/op (? =   0.00 ns/op) [     1.33]
>            1 threads, Tavg =      1.36 ns/op (? =   0.00 ns/op) [     1.36]
> # Measure:
>            1 threads, Tavg =      1.36 ns/op (? =   0.00 ns/op) [     1.36]
>            2 threads, Tavg =      1.30 ns/op (? =   0.04 ns/op) [
> 1.34,      1.25]
>            3 threads, Tavg =      1.29 ns/op (? =   0.06 ns/op) [
> 1.37,      1.25,      1.27]
>            4 threads, Tavg =      1.32 ns/op (? =   0.10 ns/op) [
> 1.24,      1.25,      1.31,      1.49]
>
>
>
> >> java.util.logging enabled
>
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      1.74 ns/op (? =   0.00 ns/op) [     1.74]
>            1 threads, Tavg =      1.73 ns/op (? =   0.00 ns/op) [     1.73]
> # Measure:
>            1 threads, Tavg =      1.57 ns/op (? =   0.00 ns/op) [     1.57]
>            2 threads, Tavg =      1.57 ns/op (? =   0.00 ns/op) [
> 1.58,      1.57]
>            3 threads, Tavg =      1.58 ns/op (? =   0.00 ns/op) [
> 1.57,      1.58,      1.57]
>            4 threads, Tavg =      1.59 ns/op (? =   0.01 ns/op) [
> 1.61,      1.58,      1.58,      1.59]
>
> << JVM END
>
>
> It can be seen that performance is stable as it does not change a bit if
> the "switch" occurs at start or in the middle.
>
> With this patch, we have a 2.9x - 5.7x speed-up compared to original code
> (depending on test).
>
> Laurent, can you try this one on your machine? Would be fine to see also
> the webrev.07 tested on your machine (I'm curious if this
> slow-down-due-to-deoptimization also happens on your environment and what
> the impact is).
>
> Regards, Peter
>
>
>
> On 03/25/2013 12:46 PM, Peter Levart wrote:
>
> Hi Laurent, Mandy,
>
> MethodHandles.guardWithCheck() rocks!
>
> Out of curiosity, I put the MethodHandles in latest JDK8 build to the
> test. It turns out that they are surprisingly good. I optimized the
> dispatch logic of the most critical method: PlatformLogger.isLoggable(int)
> which I have shown in previous mail, is performance-dependent on whether
> java.util.logging is enabled from the beginning so that the dispatch is
> compiled by JIT into an in-lined monomorphic call or it is enabled later-on
> when the code has already been warmed-up using LoggerProxy. The method's
> performance drops by factor of 3 in the later situation.
>
> Here's what I did:
>
>
> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.mh.01/index.html
>
> The benchmark results are as follows (only showing the patched
> PlatformLogger - for original code results, refer to previous mail or see
> below quoted message):
>
> ** Patched code (webrev.mh.01)
>
> >> JVM START
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      1.40 ns/op (? =   0.00 ns/op) [     1.40]
>            1 threads, Tavg =      1.39 ns/op (? =   0.00 ns/op) [     1.39]
> # Measure:
>            1 threads, Tavg =      1.42 ns/op (? =   0.00 ns/op) [     1.42]
>            2 threads, Tavg =      1.31 ns/op (? =   0.00 ns/op) [
> 1.31,      1.31]
>            3 threads, Tavg =      1.43 ns/op (? =   0.20 ns/op) [
> 1.74,      1.32,      1.32]
>            4 threads, Tavg =      1.34 ns/op (? =   0.01 ns/op) [
> 1.35,      1.35,      1.33,      1.35]
>
> << JVM END
>
> >> JVM START
>
> >> java.util.logging enabled
>
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      1.69 ns/op (? =   0.00 ns/op) [     1.69]
>            1 threads, Tavg =      1.77 ns/op (? =   0.00 ns/op) [     1.77]
> # Measure:
>            1 threads, Tavg =      1.73 ns/op (? =   0.00 ns/op) [     1.73]
>            2 threads, Tavg =      1.73 ns/op (? =   0.00 ns/op) [
> 1.72,      1.73]
>            3 threads, Tavg =      1.97 ns/op (? =   0.49 ns/op) [
> 2.74,      1.72,      1.73]
>            4 threads, Tavg =      1.80 ns/op (? =   0.05 ns/op) [
> 1.83,      1.73,      1.79,      1.87]
>
> << JVM END
>
> >> JVM START
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      1.35 ns/op (? =   0.00 ns/op) [     1.35]
>            1 threads, Tavg =      1.74 ns/op (? =   0.00 ns/op) [     1.74]
> # Measure:
>            1 threads, Tavg =      1.33 ns/op (? =   0.00 ns/op) [     1.33]
>            2 threads, Tavg =      1.44 ns/op (? =   0.00 ns/op) [
> 1.44,      1.44]
>            3 threads, Tavg =      1.28 ns/op (? =   0.01 ns/op) [
> 1.30,      1.27,      1.29]
>            4 threads, Tavg =      1.31 ns/op (? =   0.03 ns/op) [
> 1.34,      1.27,      1.29,      1.33]
>
>
> >> java.util.logging enabled
>
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      2.04 ns/op (? =   0.00 ns/op) [     2.04]
>            1 threads, Tavg =      2.04 ns/op (? =   0.00 ns/op) [     2.04]
> # Measure:
>            1 threads, Tavg =      2.04 ns/op (? =   0.00 ns/op) [     2.04]
>            2 threads, Tavg =      2.04 ns/op (? =   0.00 ns/op) [
> 2.04,      2.04]
>            3 threads, Tavg =      2.04 ns/op (? =   0.00 ns/op) [
> 2.04,      2.03,      2.04]
>            4 threads, Tavg =      2.04 ns/op (? =   0.00 ns/op) [
> 2.04,      2.04,      2.04,      2.05]
>
> << JVM END
>
>
> There's still a small drop in speed when "the switch to java.util.logging"
> happens, but it's negligible. So compared to original code, with both
> optimizations combined, the speed-up is 2.6x - 4.5x (depending on test).
>
> I don't know how this performs on JDK7 though, so perhaps a backport
> should not use MethodHandles.
>
> Regards, Peter
>
> On 03/22/2013 05:23 PM, Peter Levart wrote:
>
> Hi Laurent,
>
> I have run your performance test on my machine (i7 CPU, Linux) and with
> original code on JDK8 64bit (CompressedOOPS enabled by default, no TLAB
> options), i get:
>
> ...
> INFO: testPerf[100000000 iterations]: duration = 1767.6329779999999 ms.
> INFO: testPerf[100000000 iterations]: duration = 1758.7931449999999 ms.
> INFO: testPerf[100000000 iterations]: duration = 1763.386362 ms.
> ...
>
> While with latest patch (webrev.07), the results are:
>
> ...
> INFO: testPerf[100000000 iterations]: duration = 660.940466 ms.
> INFO: testPerf[100000000 iterations]: duration = 662.4854379999999 ms.
> INFO: testPerf[100000000 iterations]: duration = 656.497199 ms.
> ...
>
>
> So it's apparently a 2.5x improvement in speed.
>
> This test is designed to test the PlatformLogger.isLoggable() for levels
> that don't result in log messages being actually written out, but there are
> some caveats:
>
> - the test is using a loop with local variables and counters, which is
> very prone to JIT optimizations such as loop-unrolling. This might or might
> not be happening and even if it is, the impact might be the same on
> unpatched vs. patched PlatformLogger code.
> - the test is testing the performance when the PlatformLogger is directed
> to java.util.logging from the beginning. That means JIT is compiling calls
> to virtual methods of JavaLoggerProxy into monomorphic inlined calls. The
> results are different if the test is 1st warmed-up while no
> java.util.logging is initialized yet (calls directed to LoggerProxy) and
> later java.util.logging is enabled (PlatformLoggers are redirected to
> JavaLoggerProxys) and the same test repeated.
>
> I have created a special test that demonstrates this (all tests run on
> recent JDK8 build, i7 (4 cores) Linux, 64bit, no TLAB option,
> CompressedOOPS enabled by default):
>
> ** Original code
>
> >> JVM START
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      1.78 ns/op (? =   0.00 ns/op) [     1.78]
>            1 threads, Tavg =      1.67 ns/op (? =   0.00 ns/op) [     1.67]
> # Measure:
>            1 threads, Tavg =      1.44 ns/op (? =   0.00 ns/op) [     1.44]
>            2 threads, Tavg =      1.37 ns/op (? =   0.01 ns/op) [
> 1.37,      1.38]
>            3 threads, Tavg =      1.53 ns/op (? =   0.13 ns/op) [
> 1.41,      1.49,      1.71]
>            4 threads, Tavg =      1.43 ns/op (? =   0.10 ns/op) [
> 1.36,      1.62,      1.39,      1.38]
>
> << JVM END
>
> >> JVM START
>
> >> java.util.logging enabled
>
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      4.81 ns/op (? =   0.00 ns/op) [     4.81]
>            1 threads, Tavg =      4.79 ns/op (? =   0.00 ns/op) [     4.79]
> # Measure:
>            1 threads, Tavg =      4.67 ns/op (? =   0.00 ns/op) [     4.67]
>            2 threads, Tavg =      4.67 ns/op (? =   0.00 ns/op) [
> 4.67,      4.67]
>            3 threads, Tavg =      4.87 ns/op (? =   0.31 ns/op) [
> 4.67,      4.68,      5.32]
>            4 threads, Tavg =      4.68 ns/op (? =   0.01 ns/op) [
> 4.68,      4.67,      4.68,      4.69]
>
> << JVM END
>
> >> JVM START
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      1.39 ns/op (? =   0.00 ns/op) [     1.39]
>            1 threads, Tavg =      1.80 ns/op (? =   0.00 ns/op) [     1.80]
> # Measure:
>            1 threads, Tavg =      1.38 ns/op (? =   0.00 ns/op) [     1.38]
>            2 threads, Tavg =      1.38 ns/op (? =   0.00 ns/op) [
> 1.38,      1.38]
>            3 threads, Tavg =      1.38 ns/op (? =   0.01 ns/op) [
> 1.39,      1.38,      1.37]
>            4 threads, Tavg =      1.38 ns/op (? =   0.02 ns/op) [
> 1.42,      1.37,      1.37,      1.37]
>
>
> >> java.util.logging enabled
>
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =     11.87 ns/op (? =   0.00 ns/op) [    11.87]
>            1 threads, Tavg =      9.08 ns/op (? =   0.00 ns/op) [     9.08]
> # Measure:
>            1 threads, Tavg =      9.12 ns/op (? =   0.00 ns/op) [     9.12]
>            2 threads, Tavg =      9.02 ns/op (? =   0.02 ns/op) [
> 9.05,      9.00]
>            3 threads, Tavg =      9.20 ns/op (? =   0.04 ns/op) [
> 9.26,      9.19,      9.17]
>            4 threads, Tavg =      9.33 ns/op (? =   0.07 ns/op) [
> 9.44,      9.34,      9.26,      9.28]
>
> << JVM END
>
>
> ** Patched code (webrev.07)
>
> >> JVM START
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      1.38 ns/op (? =   0.00 ns/op) [     1.38]
>            1 threads, Tavg =      1.68 ns/op (? =   0.00 ns/op) [     1.68]
> # Measure:
>            1 threads, Tavg =      1.38 ns/op (? =   0.00 ns/op) [     1.38]
>            2 threads, Tavg =      1.40 ns/op (? =   0.02 ns/op) [
> 1.37,      1.42]
>            3 threads, Tavg =      1.49 ns/op (? =   0.21 ns/op) [
> 1.80,      1.38,      1.36]
>            4 threads, Tavg =      1.50 ns/op (? =   0.13 ns/op) [
> 1.47,      1.73,      1.41,      1.42]
>
> << JVM END
>
> >> JVM START
>
> >> java.util.logging enabled
>
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      1.80 ns/op (? =   0.00 ns/op) [     1.80]
>            1 threads, Tavg =      1.74 ns/op (? =   0.00 ns/op) [     1.74]
> # Measure:
>            1 threads, Tavg =      1.78 ns/op (? =   0.00 ns/op) [     1.78]
>            2 threads, Tavg =      1.80 ns/op (? =   0.00 ns/op) [
> 1.80,      1.80]
>            3 threads, Tavg =      1.84 ns/op (? =   0.03 ns/op) [
> 1.80,      1.88,      1.86]
>            4 threads, Tavg =      1.78 ns/op (? =   0.00 ns/op) [
> 1.78,      1.77,      1.77,      1.78]
>
> << JVM END
>
> >> JVM START
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      1.73 ns/op (? =   0.00 ns/op) [     1.73]
>            1 threads, Tavg =      1.72 ns/op (? =   0.00 ns/op) [     1.72]
> # Measure:
>            1 threads, Tavg =      1.38 ns/op (? =   0.00 ns/op) [     1.38]
>            2 threads, Tavg =      1.37 ns/op (? =   0.00 ns/op) [
> 1.37,      1.37]
>            3 threads, Tavg =      1.52 ns/op (? =   0.19 ns/op) [
> 1.37,      1.45,      1.79]
>            4 threads, Tavg =      1.58 ns/op (? =   0.19 ns/op) [
> 1.42,      1.79,      1.81,      1.41]
>
>
> >> java.util.logging enabled
>
> #
> # isLoggableFinest: run duration:  5,000 ms, #of logical CPUS: 8
> #
> # Warm up:
>            1 threads, Tavg =      5.43 ns/op (? =   0.00 ns/op) [     5.43]
>            1 threads, Tavg =      5.65 ns/op (? =   0.00 ns/op) [     5.65]
> # Measure:
>            1 threads, Tavg =      5.66 ns/op (? =   0.00 ns/op) [     5.66]
>            2 threads, Tavg =      5.67 ns/op (? =   0.01 ns/op) [
> 5.68,      5.66]
>            3 threads, Tavg =      5.65 ns/op (? =   0.00 ns/op) [
> 5.65,      5.65,      5.65]
>            4 threads, Tavg =      5.66 ns/op (? =   0.01 ns/op) [
> 5.65,      5.65,      5.67,      5.67]
>
> << JVM END
>
>
> It appears the speed-up is visible and varies from 1.6x to 2.6x, depending
> on other factors that also play role in the overall speed (like JIT
> optimizations).
>
> I only presented the results for PlatformLogger.isLoggable(FINEST),
> because this is the most sensitive call in tight loops. Other methods
> perform similarly.
>
> This is the test code I used:
>
>
> package test;
>
> import si.pele.microbench.TestRunner;
> import sun.util.logging.PlatformLogger;
>
> import java.util.logging.LogManager;
>
> public class PlatformLoggerBenchmark extends TestRunner {
>
>     static final PlatformLogger log =
> PlatformLogger.getLogger(PlatformLoggerBenchmark.class.getName());
>
>     static {
>         log.setLevel(PlatformLogger.SEVERE); // almost OFF
>     }
>
>     public static class isLoggableFinest extends Test {
>         @Override
>         protected void doLoop(Loop loop, DevNull devNull1, DevNull
> devNull2, DevNull devNull3, DevNull devNull4, DevNull devNull5) {
>             while (loop.nextIteration()) {
>                 devNull1.yield(log.isLoggable(PlatformLogger.FINEST));
>             }
>         }
>     }
>
>     public static void main(String[] args) throws Exception {
>
>         System.out.println(">> JVM START");
>
>         doTest(isLoggableFinest.class, 5000L, 1, 4, 1);
>
>         // enable java.util.logging
>         LogManager.getLogManager().getLogger(log.getName());
>         System.out.println("\n>> java.util.logging enabled\n");
>
>         doTest(isLoggableFinest.class, 5000L, 1, 4, 1);
>
>         System.out.println("<< JVM END");
>     }
> }
>
>
> The test uses a simple microbenchmark runner that I coded together using
> some ideas from the sessions with Alexey Shipilev and his benchmark suite.
>
> Here's the source to my dirty implementation:
>
>     https://github.com/plevart/micro-bench/tree/v2
>
>
> Regards, Peter
>
> On 03/22/2013 02:28 PM, Peter Levart wrote:
>
> Ok, Lauret, Mandy,
>
> Here are the final touches:
>
>
> https://dl.dropboxusercontent.com/u/101777488/jdk8-tl/PlatformLogger/webrev.07/index.html
>
> Changes from webrev.06:
>
> - renamed back Level -> LevelEnum
> - renamed JavaLogger -> JavaLoggerProxy
> - moved javaLevel(int) static method from LevelEnum to JavaLoggerProxy and
> made it private (only used there)
> - consistent use of variable name 'level' to refer to PlatformLogger's int
> level value
> - consistent use of variable name 'levelEnum' to refer to LevelEnum member
> - consistent use of variable name 'javaLevel' to refer to
> java.util.logging.Level instance
> - consistent use of variable name 'javaLogger' to refer to
> java.util.logging.Logger instance
> - renamed PlatformLogger.newJavaLogger() private method ->
> PlatformLogger.redirectToJavaLoggerProxy()
> - renamed PlatformLogger.logger private field -> PlatformLogger.loggerProxy
> - some additional comments
>
> I think that these changes make code more consistent and self-explanatory.
>
> What remains is a possible rename from: javaLogger, javaLevel,
> JavaLoggerProxy -> julLogger, julLevel, JulLoggerProxy if that's the final
> decision.
>
> Regards, Peter
>
>
> On 03/22/2013 01:26 PM, Peter Levart wrote:
>
> On 03/22/2013 11:34 AM, Laurent Bourg?s wrote:
>
> Peter,
>
>   You've beaten me! I have been preparing them too ;-) ...
>>
>
> Ok I definitely stop working on the code and let you do it.
>
>
> Ok. I'll make the final touches, incorporating also comments and changes
> from your code...
>
>
>
>>  I also did some some renames, that I think make the code more consistent:
>> - LevelEnum -> Level (the code is not dependent on
>> java.util.logging.Level, so the name can be reused, its private anyway)
>> - julLevel -> javaLevel (javaLevel / JavaLogger)
>> - LevelEnum.forValue -> Level.valueOf (Mandy)
>> - JavaLogger.julLevelToEnum -> JavaLogger.javaLevelToLevel
>>
>
> For consistency and clarity, I would prefer having following conventions:
> - int levelValue (= PlatformLevel as int) and not int level (conflict with
> Level enum ...)
>
>
> I think that PlatformLogger public API should stay as is. Public method's
> parameter names are just called 'level' and values of public constants are
> expected to be passed to them. There are only two places where 'level' is
> the name of a local variable of type Level (and not int) and at both places
> there is not conflict, since there's no 'int level' variable in scope.
>
> I renamed LevelEnum to Level because the following most frequently used
> pattern looks strange:
>
>     LevelEnum.javaLevel(int)
>
> Neither parameter nor the result has anything to do with LevelEnum
> directly.
>
> But if we move the javaLevel(int) method out of the Level enum into the
> JavaLogger, then Level can be renamed back to LevelEnum (or anything else?).
>
>
>   - julLevel / julLogger: more explicit than javaLevel / javaLogger (java
> means everything  ... but jul means java.util.logging and javaLogger is in
> conflict with JavaLogger class)
>
>
>
> But javaLogger is not in conflict with javaLevel. I suggest renaming
> JavaLoger class to JavaLoggerProxy, so we would have:
>
> Object javaLogger // holding java.util.logging.Logger instance
> Object javaLevel    // holding java.util.logging.Level instance
>
> class JavaLoggerProxy  // a specialization of LoggerProxy, delegating to
> javaLogger
>
> If 'jul' is a prefered prefix to 'java', I suggest renaming all 3:
> julLogger, julLevel, JulLoggerProxy. I don't have a preference for either,
> so perhaps Mandy, Laurent or anybody else can express them...
>
>
> Regards, Peter
>
>
>   Other changes (to webrev.05):
>> - removed the occurrence counts in switch comments (as per Mandy's
>> suggestion)
>> - made LoggerProxy and JavaLogger private
>> - fixed double-read of volatile LoggerProxy.levelValue in
>> LoggerProxy.isLoggable()
>> - added static Level.javaLevel(int value) shortcut (Mandy)
>>
>> I also updated the test to exercise the correctness of mappings.
>>
>
> Well done.
>
> cheers,
> Laurent
>
>
>
>
>
>
>


From dmitry.samersoff at oracle.com  Mon Mar 25 18:56:17 2013
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Mon, 25 Mar 2013 22:56:17 +0400
Subject: RFR: Project files for Solaris Studio / NetBeans
In-Reply-To: <515098D6.4080404@oracle.com>
References: <51507B60.6030809@oracle.com> <51508545.6040102@oracle.com>
	<515098D6.4080404@oracle.com>
Message-ID: <51509DD1.3020308@oracle.com>

Jesper,

On 2013-03-25 22:35, Jesper Wilhelmsson wrote:
> Dmitry Samersoff skrev 25/3/13 6:11 PM:
>> Jesper,
>>
>> Tryed to apply your patch as I'm quite inetresting to have really
>> working NB project for jdk and hotspot.
>>
>> 1. Directory structure looks strange (see screenshot1)
> 
> The structure in the Projects tab shows the NetBeans project hierarchy.
> It's not related to the OpenJDK project hierarchy. The "Files" tab (to
> the right of the project tab) will show you the directory structure as
> it looks on disk. I think this is the tab you want to use for browsing
> the directories.

I'm using Linux and fresh netbeans copy, so fd and macosx_* projects
comes from your patch for sure.

Please take a look at it.

-Dmitry

> 
>> 2. netbeans doesn't work for JDK tests (see screenshot2) -
>>
>>     netbeans doesn't pick files
>>     from test directory (JDK-only project have the same issue)
>>
>>     netbeans doesn't pick changes from files in JDK tree - i.e
>>     if I add/change class name in JDK tree, netbeans still treated it
>>     as unresolved within test (JDK-only project have the same issue)
> 
> I have mainly looked at the hotspot code when creating the project so
> I'm not surprised to see that there are things that don't work in for
> instance the jdk. I'll look at this tomorrow.
> 
> Thank you for your comments,
> /Jesper
> 
>>
>> -Dmitry
>>
>>
>>
>> On 2013-03-25 20:29, Jesper Wilhelmsson wrote:
>>> Hi,
>>>
>>> Sorry for cross posting, but I think this could be useful for several
>>> areas.
>>>
>>> I would like to add Solaris Studio / NetBeans project files for the
>>> entire OpenJDK project. To clarify: One project that contains the entire
>>> OpenJDK.
>>>
>>>
>>> With the new build infrastructure in JDK 8 building the entire OpenJDK
>>> is fairly fast and even though I personally mostly work in the HotSpot
>>> tree, I tend to always clone and build the entire JDK forest. I find
>>> this to have several benefits.
>>>
>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/
>>>
>>> The configuration in this project is currently Mac only. Linux and
>>> Solaris configurations are also planned.
>>>
>>> The webrev is made from the jdk8/build repository which is where I think
>>> a change like this should go in. Let me know if you think something
>>> else.
>>>
>>>
>>>
>>> To use this project (once pushed):
>>>
>>> 1. Clone your favorite repository
>>>     hg clone http://hg.openjdk.java.net/hsx/hotspot-gc
>>>
>>> 2. Get the whole forest
>>>     cd hotspot-gc
>>>     sh get_source.sh
>>>
>>> 3. Configure
>>>     sh configure
>>>
>>> 4. Open Solaris studio / NetBeans and load the project.
>>>     The project in located in the common directory.
>>>
>>>
>>> Thanks,
>>> /Jesper
>>
>>


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer


From volker.simonis at gmail.com  Mon Mar 25 19:59:18 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 25 Mar 2013 20:59:18 +0100
Subject: RFR: Project files for Solaris Studio / NetBeans
In-Reply-To: <51509173.6020803@oracle.com>
References: <51507B60.6030809@oracle.com>
	
	<51509173.6020803@oracle.com>
Message-ID: 

On Mon, Mar 25, 2013 at 7:03 PM, Jesper Wilhelmsson <
jesper.wilhelmsson at oracle.com> wrote:

> Volker Simonis skrev 25/3/13 6:15 PM:
>
>  Hi Jesper,
>>
>> first of all I highly welcome your initiative!
>>
>
> This is a joint initiative with Vladimir Voskresensky who works in the
> Solaris Studio team.
>
>
>
>> Nevertheless I have some questions:
>>
>> - Who will support these project files? As far as I can see, they will
>> have to be updated at least every time a file will be added, renamed
>> or deleted. Experience shows that such kind of project files tend to
>> get outdated very fast. Do you have any ideas how this problem can be
>> addressed?
>>
>
> One thing that was a pleasant surprise to me when I created the nbproject
> was that if I add new source files, they are automatically brought into the
> project. And when running make, the code assistant will be updated with the
> new definitions in the new files. So even if the project file is slightly
> out of date it will auto-update itself once you run make the first time.
>
> I don't think I should volunteer to keep the project files up to date, but
> since I will be using Solaris Studio for my daily work, and since I will be
> notified about changes in the project files every time I run "hg status",
> it seems pretty likely that I will push an updated project once in a while.
> - At least for Mac.
>
>
>  - Where will other platform configurations go to? Will they be all
>> stored in "configurations.xml"
>>
>
> Yes, I think so.
>
>
>  - What about other configurations (i.e. DEBUG, PRODUCT, 32/64bit,
>> CC_INTERP, etc..)? Will they all have to go into the same
>> "configurations.xml"
>>
>
> If I'm not mistaken these are different make targets, right? I don't think
> you need to have separate configurations saved in the project files for
> different make targets. Vladimir can answer this much better, but the way I
> have done it previously has simply been to edit the make command if I
> wanted to build a different target, and the code assistant is automatically
> updated when running make ("make clean" may be needed in some cases).
>
>
These are partially make targets but also preprocessor defines set by
various make targets. For example you may have different class definitions
depending on whether "DEBUG" is defined or not. Actually I don't understand
how code assistants is automatically updated if I do a "make clean" with a
different make target if I haven't defined the new preprocessor defines for
the project. Is this by parsing the generated libjvm.so? That's a neat
feature of NetBeans but as far as I know it only works if the VM is
compiled with '-g3' which HotSpot isn't by default.


>
>
>> It seems that the "configurations.xml" might get quite big and complex
>> with all these configurations.
>>
>
> It's not too big right now IMHO. If it starts to grow unexpectedly in the
> future I agree that we should reconsider the choice to store it in the
> repository.
>
> Thank you for your comments,
> /Jesper
>
>
>
>> Thank you and best regards,
>> Volker
>>
>> On Mon, Mar 25, 2013 at 5:29 PM, Jesper Wilhelmsson
>>  wrote:
>>
>>> Hi,
>>>
>>> Sorry for cross posting, but I think this could be useful for several
>>> areas.
>>>
>>> I would like to add Solaris Studio / NetBeans project files for the
>>> entire
>>> OpenJDK project. To clarify: One project that contains the entire
>>> OpenJDK.
>>>
>>>
>>> With the new build infrastructure in JDK 8 building the entire OpenJDK is
>>> fairly fast and even though I personally mostly work in the HotSpot
>>> tree, I
>>> tend to always clone and build the entire JDK forest. I find this to have
>>> several benefits.
>>>
>>> Webrev: http://cr.openjdk.java.net/~**jwilhelm/7074926/webrev/
>>>
>>> The configuration in this project is currently Mac only. Linux and
>>> Solaris
>>> configurations are also planned.
>>>
>>> The webrev is made from the jdk8/build repository which is where I think
>>> a
>>> change like this should go in. Let me know if you think something else.
>>>
>>>
>>>
>>> To use this project (once pushed):
>>>
>>> 1. Clone your favorite repository
>>>     hg clone http://hg.openjdk.java.net/**hsx/hotspot-gc
>>>
>>> 2. Get the whole forest
>>>     cd hotspot-gc
>>>     sh get_source.sh
>>>
>>> 3. Configure
>>>     sh configure
>>>
>>> 4. Open Solaris studio / NetBeans and load the project.
>>>     The project in located in the common directory.
>>>
>>>
>>> Thanks,
>>> /Jesper
>>>
>>


From mandy.chung at oracle.com  Mon Mar 25 20:11:37 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 25 Mar 2013 13:11:37 -0700
Subject: Review 8007703: Remove com.sun.servicetag API
In-Reply-To: <511E0597.2080902@oracle.com>
References: <511D73CA.90503@oracle.com> <511E0597.2080902@oracle.com>
Message-ID: <5150AF79.9010206@oracle.com>

On 2/15/13 1:53 AM, David Holmes wrote:
> Hi Mandy,
>
> On 15/02/2013 9:31 AM, Mandy Chung wrote:
>> Remove com.sun.servicetag that we no longer support.  This includes
>> updates the makefiles and so include build-infra to review this
>> change.
>
> This will require a tweak to profile-rtjar-includes.txt once it gets 
> pushed next week. It won't cause any build problems though so it is 
> okay for us to do a follow up CR to make the adjustment.
>

David,

I have modified profile-includes.txt and profile-rtjar-includes.txt:
    http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8007703/webrev.01/

Other files are the same as in webrev.00.

Mandy

> David
>
>> It's solely JDK implementation-specific that was added to
>> support JDK product registration and service tag as legacy
>> Sun-software requirement in 2007.
>>
>> Webrev at:
>>     http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8007703/webrev.00/
>>
>> Thanks
>> Mandy



From Lance.Andersen at oracle.com  Mon Mar 25 20:25:38 2013
From: Lance.Andersen at oracle.com (Lance Andersen)
Date: Mon, 25 Mar 2013 16:25:38 -0400
Subject: netbeans and openjdk
Message-ID: <63D9462D-2B6B-4BD3-89EA-8B93728DEDC3@oracle.com>

Hi all,

I am trying to set up a netbeans project for JDBC within openjdk leveraging the existing projects that are already in jdk/make/netbeans

I have getting the following error and not sure why so wondered if anyone has encountered this before:

------------------------------------------------------


ant -f /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/jdbc clean build
Deleting directory /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/depcache
shared.clean:
clean:
/Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:128: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds
Compiling 96 source files to /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/classes
warning: [options] bootstrap class path not set in conjunction with -source 1.5
/Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/src/share/classes/javax/sql/rowset/serial/SerialClob.java:148: error: try-with-resources is not supported in -source 1.5
        try (Reader charStream = clob.getCharacterStream()) {
  (use -source 7 or higher to enable try-with-resources)
/Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/src/share/classes/javax/sql/rowset/spi/SyncFactory.java:370: error: try-with-resources is not supported in -source 1.5
                    try (FileInputStream fis = new FileInputStream(ROWSET_PROPERTIES)) {
  (use -source 7 or higher to enable try-with-resources)
2 errors
1 warning
/Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:170: The following error occurred while executing this line:
/Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:155: The following error occurred while executing this line:
/Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:128: Compile failed; see the compiler error output for details.
BUILD FAILED (total time: 2 seconds)

----------------------------------------

If I open the project properties in netbeans, it shows 1.7 source.  This is with netbeans 7.3

Best
Lance


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com






From huizhe.wang at oracle.com  Mon Mar 25 21:12:55 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 25 Mar 2013 14:12:55 -0700
Subject: netbeans and openjdk
In-Reply-To: <63D9462D-2B6B-4BD3-89EA-8B93728DEDC3@oracle.com>
References: <63D9462D-2B6B-4BD3-89EA-8B93728DEDC3@oracle.com>
Message-ID: <5150BDD7.6060804@oracle.com>

Hi Lance,

Are you setting it up as a free-form project?  In a free-form project, 
the custom build script is separate from those generated by the IDE.  
Although you can map targets from the custom build script to project 
actions, you won't see properties such as source in the script reflected 
in the IDE. Your ide may be configured so that you may right-click and 
compile selected file using IDE generated scripts, but when you 'build' 
the whole project, you're using the target in your customer script.  In 
this case, your build script must have defined to compile to source 1.5 
that seems to be in the shared.xml.

-Joe

On 3/25/2013 1:25 PM, Lance Andersen wrote:
> Hi all,
>
> I am trying to set up a netbeans project for JDBC within openjdk leveraging the existing projects that are already in jdk/make/netbeans
>
> I have getting the following error and not sure why so wondered if anyone has encountered this before:
>
> ------------------------------------------------------
>
>
> ant -f /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/jdbc clean build
> Deleting directory /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/depcache
> shared.clean:
> clean:
> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:128: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds
> Compiling 96 source files to /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/classes
> warning: [options] bootstrap class path not set in conjunction with -source 1.5
> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/src/share/classes/javax/sql/rowset/serial/SerialClob.java:148: error: try-with-resources is not supported in -source 1.5
>          try (Reader charStream = clob.getCharacterStream()) {
>    (use -source 7 or higher to enable try-with-resources)
> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/src/share/classes/javax/sql/rowset/spi/SyncFactory.java:370: error: try-with-resources is not supported in -source 1.5
>                      try (FileInputStream fis = new FileInputStream(ROWSET_PROPERTIES)) {
>    (use -source 7 or higher to enable try-with-resources)
> 2 errors
> 1 warning
> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:170: The following error occurred while executing this line:
> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:155: The following error occurred while executing this line:
> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:128: Compile failed; see the compiler error output for details.
> BUILD FAILED (total time: 2 seconds)
>
> ----------------------------------------
>
> If I open the project properties in netbeans, it shows 1.7 source.  This is with netbeans 7.3
>
> Best
> Lance
>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>
>
>
>



From Lance.Andersen at oracle.com  Mon Mar 25 21:28:05 2013
From: Lance.Andersen at oracle.com (Lance Andersen)
Date: Mon, 25 Mar 2013 17:28:05 -0400
Subject: netbeans and openjdk
In-Reply-To: <5150BDD7.6060804@oracle.com>
References: <63D9462D-2B6B-4BD3-89EA-8B93728DEDC3@oracle.com>
	<5150BDD7.6060804@oracle.com>
Message-ID: <9A7DF021-1EE6-49B9-81B4-AC2922712313@oracle.com>

Hi Joe,

On Mar 25, 2013, at 5:12 PM, huizhe wang  wrote:

> Hi Lance,
> 
> Are you setting it up as a free-form project?  In a free-form project, the custom build script is separate from those generated by the IDE.  Although you can map targets from the custom build script to project actions, you won't see properties such as source in the script reflected in the IDE. Your ide may be configured so that you may right-click and compile selected file using IDE generated scripts, but when you 'build' the whole project, you're using the target in your customer script.  In this case, your build script must have defined to compile to source 1.5 that seems to be in the shared.xml.

Yes, I was looking at shared.xml and it has the following


            
            
            
            
            
                
                
                    
                    
                    
                     
                    
                    
                    
                


So this seems to be the issue.

So I changed the values above just now from  1.5 and 1.6 to both be 1.7

Which worked much better.


This works in a jdk7 repository.

It looks like shared.xml was changed for jdk8  so it does not have the values above.


Also, do you know why if this is on osx  it is building in

Copying 3 files to /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/classes
Building jar: /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/dist/lib/jdb42.jar


Thank you for your time Joe

Best
Lance
> -Joe
> 
> On 3/25/2013 1:25 PM, Lance Andersen wrote:
>> Hi all,
>> 
>> I am trying to set up a netbeans project for JDBC within openjdk leveraging the existing projects that are already in jdk/make/netbeans
>> 
>> I have getting the following error and not sure why so wondered if anyone has encountered this before:
>> 
>> ------------------------------------------------------
>> 
>> 
>> ant -f /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/jdbc clean build
>> Deleting directory /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/depcache
>> shared.clean:
>> clean:
>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:128: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds
>> Compiling 96 source files to /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/classes
>> warning: [options] bootstrap class path not set in conjunction with -source 1.5
>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/src/share/classes/javax/sql/rowset/serial/SerialClob.java:148: error: try-with-resources is not supported in -source 1.5
>>         try (Reader charStream = clob.getCharacterStream()) {
>>   (use -source 7 or higher to enable try-with-resources)
>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/src/share/classes/javax/sql/rowset/spi/SyncFactory.java:370: error: try-with-resources is not supported in -source 1.5
>>                     try (FileInputStream fis = new FileInputStream(ROWSET_PROPERTIES)) {
>>   (use -source 7 or higher to enable try-with-resources)
>> 2 errors
>> 1 warning
>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:170: The following error occurred while executing this line:
>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:155: The following error occurred while executing this line:
>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:128: Compile failed; see the compiler error output for details.
>> BUILD FAILED (total time: 2 seconds)
>> 
>> ----------------------------------------
>> 
>> If I open the project properties in netbeans, it shows 1.7 source.  This is with netbeans 7.3
>> 
>> Best
>> Lance
>> 
>> 
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com
>> 
>> 
>> 
>> 
> 




Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com






From martinrb at google.com  Mon Mar 25 21:30:55 2013
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 25 Mar 2013 14:30:55 -0700
Subject: RFR-8008118
In-Reply-To: <70b1d9e4-bee6-4355-8694-a7c7771861bf@default>
References: <70b1d9e4-bee6-4355-8694-a7c7771861bf@default>
Message-ID: 

Since we're all on this perfectionist quest for quality here, I noticed
that we could replace allocation for path components with a single
allocation using NUL as a separator.  I think I'll go code that up.

Also note to all: if java VMs are created and destroyed without the process
terminating, there is a small leak here (and in many other places in the
JDK).  There would be a huge amount of work if we ever wanted to get that
right (especially if we supported concurrently active JVMs).


On Fri, Mar 22, 2013 at 7:38 AM, John Zavgren wrote:

> Greetings:
>
> I made modifications as per Martin's suggestions:
> 1.) free pathv on "abort".
> 2.) allocate memory for storing the "cwd" string, and then copy it into
> the memory location (to make sure that the contents of the pathv[] array
> don't refer to memory that's from the stack of the procedure that created
> it.)
>
> Thanks!
> John
>
>
> http://cr.openjdk.java.net/~jzavgren/8008118/webrev.06/
>
> ----- Original Message -----
> From: martinrb at google.com
> To: christos at zoulas.com
> Cc: john.zavgren at oracle.com, core-libs-dev at openjdk.java.net
> Sent: Friday, March 22, 2013 10:19:24 AM GMT -05:00 US/Canada Eastern
> Subject: Re: RFR-8008118
>
>
>
>
> On Thu, Mar 21, 2013 at 12:11 PM, Christos Zoulas wrote:
>
>> On Mar 21, 11:36am, john.zavgren at oracle.com (John Zavgren) wrote:
>> -- Subject: Re: RFR-8008118
>>
>> | All:
>> |
>> | How does this look?
>> | 1.) I reverted the for statement formatting change.
>>
>> Not exactly. Now it is indented incorrectly.
>>
>>
> Agreed.  Really revert.
>
>
>> | 2.) I removed the goto statement and "inlined" some code instead.
>>
>> I prefer to write simpler code that works with both signed and unsigned
>> indexes:
>>
>> +                while (i > 0)
>> +                    if (pathv[--i] != cwd)
>> +                        free(pathv[i]);
>> +
>>
>>
> Christos' suggestion looks pretty good.
>
> As Mark noted, need to add missing free of pathv itself.
>
>
>> | 3.) I checked to make sure that we're not freeing memory that we didn't
>> act=
>> | ually allocate. (Path vector elements that are empty.)
>>
>> You are still using the "./" string literal constant in the code so you'll
>> end up freeing it (the compiler will prolly merge the two instances and
>> you'll get lucky but it is semantically incorrect).
>>
>
> Agreed,
>
> pathv[i] = cwd;
>


From the.rob.leland at gmail.com  Wed Mar 20 04:43:25 2013
From: the.rob.leland at gmail.com (Rob Leland)
Date: Wed, 20 Mar 2013 00:43:25 -0400
Subject: hg: jdk8/tl/jdk: 8001642: Add Optional, OptionalDouble,
	OptionalInt, OptionalLong
In-Reply-To: <20130319231031.7F46B48272@hg.openjdk.java.net>
References: <20130319231031.7F46B48272@hg.openjdk.java.net>
Message-ID: 

Has the optional classes been verified to serialize/deserialize correctly?
I noticed it tries to use the null object pattern with the use of EMPTY
private instance. When I have implemented the NULL pattern I have used a
private subclass of the object as opposed to an instance variable to insure
it unmarshalls correctly with a simple override of the default
desearization to insure this.

I also wonder why a marker interface wasn't used or something more
substantial at least for methods like isPresent(). Also why does the static
factory initialization parameters use primatives as opposed to objects? If
objects were used then there would be the oppertunity to use a abstract
base class, which has the potential to move the use of isPresent()
strictly  into the base class.

Finally, are these utilities critical to some other part JDK 8 that they
were pushed out now as opposed to JDK 9?
On Mar 19, 2013 7:18 PM,  wrote:

> Changeset: 2241a2d34085
> Author:    mduigou
> Date:      2013-03-19 16:05 -0700
> URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2241a2d34085
>
> 8001642: Add Optional, OptionalDouble, OptionalInt, OptionalLong
> Reviewed-by: mduigou, darcy, alanb, jjb
> Contributed-by: Brian Goetz 
>
> + src/share/classes/java/util/Optional.java
> + src/share/classes/java/util/OptionalDouble.java
> + src/share/classes/java/util/OptionalInt.java
> + src/share/classes/java/util/OptionalLong.java
> + test/java/util/Optional/Basic.java
> + test/java/util/Optional/BasicDouble.java
> + test/java/util/Optional/BasicInt.java
> + test/java/util/Optional/BasicLong.java
>
>


From jesper.wilhelmsson at oracle.com  Mon Mar 25 16:29:20 2013
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Mon, 25 Mar 2013 17:29:20 +0100
Subject: RFR: Project files for Solaris Studio / NetBeans
Message-ID: <51507B60.6030809@oracle.com>

Hi,

Sorry for cross posting, but I think this could be useful for several areas.

I would like to add Solaris Studio / NetBeans project files for the entire 
OpenJDK project. To clarify: One project that contains the entire OpenJDK.


With the new build infrastructure in JDK 8 building the entire OpenJDK is fairly 
fast and even though I personally mostly work in the HotSpot tree, I tend to 
always clone and build the entire JDK forest. I find this to have several benefits.

Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/

The configuration in this project is currently Mac only. Linux and Solaris 
configurations are also planned.

The webrev is made from the jdk8/build repository which is where I think a 
change like this should go in. Let me know if you think something else.



To use this project (once pushed):

1. Clone your favorite repository
    hg clone http://hg.openjdk.java.net/hsx/hotspot-gc

2. Get the whole forest
    cd hotspot-gc
    sh get_source.sh

3. Configure
    sh configure

4. Open Solaris studio / NetBeans and load the project.
    The project in located in the common directory.


Thanks,
/Jesper


From jesper.wilhelmsson at oracle.com  Mon Mar 25 18:03:31 2013
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Mon, 25 Mar 2013 19:03:31 +0100
Subject: RFR: Project files for Solaris Studio / NetBeans
In-Reply-To: 
References: <51507B60.6030809@oracle.com>
	
Message-ID: <51509173.6020803@oracle.com>

Volker Simonis skrev 25/3/13 6:15 PM:
> Hi Jesper,
>
> first of all I highly welcome your initiative!

This is a joint initiative with Vladimir Voskresensky who works in the Solaris 
Studio team.

>
> Nevertheless I have some questions:
>
> - Who will support these project files? As far as I can see, they will
> have to be updated at least every time a file will be added, renamed
> or deleted. Experience shows that such kind of project files tend to
> get outdated very fast. Do you have any ideas how this problem can be
> addressed?

One thing that was a pleasant surprise to me when I created the nbproject was 
that if I add new source files, they are automatically brought into the project. 
And when running make, the code assistant will be updated with the new 
definitions in the new files. So even if the project file is slightly out of 
date it will auto-update itself once you run make the first time.

I don't think I should volunteer to keep the project files up to date, but since 
I will be using Solaris Studio for my daily work, and since I will be notified 
about changes in the project files every time I run "hg status", it seems pretty 
likely that I will push an updated project once in a while.
- At least for Mac.

> - Where will other platform configurations go to? Will they be all
> stored in "configurations.xml"

Yes, I think so.

> - What about other configurations (i.e. DEBUG, PRODUCT, 32/64bit,
> CC_INTERP, etc..)? Will they all have to go into the same
> "configurations.xml"

If I'm not mistaken these are different make targets, right? I don't think you 
need to have separate configurations saved in the project files for different 
make targets. Vladimir can answer this much better, but the way I have done it 
previously has simply been to edit the make command if I wanted to build a 
different target, and the code assistant is automatically updated when running 
make ("make clean" may be needed in some cases).

>
> It seems that the "configurations.xml" might get quite big and complex
> with all these configurations.

It's not too big right now IMHO. If it starts to grow unexpectedly in the future 
I agree that we should reconsider the choice to store it in the repository.

Thank you for your comments,
/Jesper

>
> Thank you and best regards,
> Volker
>
> On Mon, Mar 25, 2013 at 5:29 PM, Jesper Wilhelmsson
>  wrote:
>> Hi,
>>
>> Sorry for cross posting, but I think this could be useful for several areas.
>>
>> I would like to add Solaris Studio / NetBeans project files for the entire
>> OpenJDK project. To clarify: One project that contains the entire OpenJDK.
>>
>>
>> With the new build infrastructure in JDK 8 building the entire OpenJDK is
>> fairly fast and even though I personally mostly work in the HotSpot tree, I
>> tend to always clone and build the entire JDK forest. I find this to have
>> several benefits.
>>
>> Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/
>>
>> The configuration in this project is currently Mac only. Linux and Solaris
>> configurations are also planned.
>>
>> The webrev is made from the jdk8/build repository which is where I think a
>> change like this should go in. Let me know if you think something else.
>>
>>
>>
>> To use this project (once pushed):
>>
>> 1. Clone your favorite repository
>>     hg clone http://hg.openjdk.java.net/hsx/hotspot-gc
>>
>> 2. Get the whole forest
>>     cd hotspot-gc
>>     sh get_source.sh
>>
>> 3. Configure
>>     sh configure
>>
>> 4. Open Solaris studio / NetBeans and load the project.
>>     The project in located in the common directory.
>>
>>
>> Thanks,
>> /Jesper


From jesper.wilhelmsson at oracle.com  Mon Mar 25 18:35:02 2013
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Mon, 25 Mar 2013 19:35:02 +0100
Subject: RFR: Project files for Solaris Studio / NetBeans
In-Reply-To: <51508545.6040102@oracle.com>
References: <51507B60.6030809@oracle.com> <51508545.6040102@oracle.com>
Message-ID: <515098D6.4080404@oracle.com>

Dmitry Samersoff skrev 25/3/13 6:11 PM:
> Jesper,
>
> Tryed to apply your patch as I'm quite inetresting to have really
> working NB project for jdk and hotspot.
>
> 1. Directory structure looks strange (see screenshot1)

The structure in the Projects tab shows the NetBeans project hierarchy. It's not 
related to the OpenJDK project hierarchy. The "Files" tab (to the right of the 
project tab) will show you the directory structure as it looks on disk. I think 
this is the tab you want to use for browsing the directories.


> 2. netbeans doesn't work for JDK tests (see screenshot2) -
>
>     netbeans doesn't pick files
>     from test directory (JDK-only project have the same issue)
>
>     netbeans doesn't pick changes from files in JDK tree - i.e
>     if I add/change class name in JDK tree, netbeans still treated it
>     as unresolved within test (JDK-only project have the same issue)

I have mainly looked at the hotspot code when creating the project so I'm not 
surprised to see that there are things that don't work in for instance the jdk. 
I'll look at this tomorrow.

Thank you for your comments,
/Jesper

>
> -Dmitry
>
>
>
> On 2013-03-25 20:29, Jesper Wilhelmsson wrote:
>> Hi,
>>
>> Sorry for cross posting, but I think this could be useful for several
>> areas.
>>
>> I would like to add Solaris Studio / NetBeans project files for the
>> entire OpenJDK project. To clarify: One project that contains the entire
>> OpenJDK.
>>
>>
>> With the new build infrastructure in JDK 8 building the entire OpenJDK
>> is fairly fast and even though I personally mostly work in the HotSpot
>> tree, I tend to always clone and build the entire JDK forest. I find
>> this to have several benefits.
>>
>> Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/
>>
>> The configuration in this project is currently Mac only. Linux and
>> Solaris configurations are also planned.
>>
>> The webrev is made from the jdk8/build repository which is where I think
>> a change like this should go in. Let me know if you think something else.
>>
>>
>>
>> To use this project (once pushed):
>>
>> 1. Clone your favorite repository
>>     hg clone http://hg.openjdk.java.net/hsx/hotspot-gc
>>
>> 2. Get the whole forest
>>     cd hotspot-gc
>>     sh get_source.sh
>>
>> 3. Configure
>>     sh configure
>>
>> 4. Open Solaris studio / NetBeans and load the project.
>>     The project in located in the common directory.
>>
>>
>> Thanks,
>> /Jesper
>
>


From jesper.wilhelmsson at oracle.com  Mon Mar 25 19:30:32 2013
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Mon, 25 Mar 2013 20:30:32 +0100
Subject: RFR: Project files for Solaris Studio / NetBeans
In-Reply-To: <51509DD1.3020308@oracle.com>
References: <51507B60.6030809@oracle.com> <51508545.6040102@oracle.com>
	<515098D6.4080404@oracle.com> <51509DD1.3020308@oracle.com>
Message-ID: <5150A5D8.1000800@oracle.com>

Dmitry,

Dmitry Samersoff skrev 25/3/13 7:56 PM:
> Jesper,
>
> On 2013-03-25 22:35, Jesper Wilhelmsson wrote:
>> Dmitry Samersoff skrev 25/3/13 6:11 PM:
>>> Jesper,
>>>
>>> Tryed to apply your patch as I'm quite inetresting to have really
>>> working NB project for jdk and hotspot.
>>>
>>> 1. Directory structure looks strange (see screenshot1)
>>
>> The structure in the Projects tab shows the NetBeans project hierarchy.
>> It's not related to the OpenJDK project hierarchy. The "Files" tab (to
>> the right of the project tab) will show you the directory structure as
>> it looks on disk. I think this is the tab you want to use for browsing
>> the directories.
>
> I'm using Linux and fresh netbeans copy, so fd and macosx_* projects
> comes from your patch for sure.
>
> Please take a look at it.

Sorry, I misinterpreted your initial comment. Yes, that is a bug. I have found 
the cause and will fix it.

Thanks,
/Jesper

>
> -Dmitry
>
>>
>>> 2. netbeans doesn't work for JDK tests (see screenshot2) -
>>>
>>>      netbeans doesn't pick files
>>>      from test directory (JDK-only project have the same issue)
>>>
>>>      netbeans doesn't pick changes from files in JDK tree - i.e
>>>      if I add/change class name in JDK tree, netbeans still treated it
>>>      as unresolved within test (JDK-only project have the same issue)
>>
>> I have mainly looked at the hotspot code when creating the project so
>> I'm not surprised to see that there are things that don't work in for
>> instance the jdk. I'll look at this tomorrow.
>>
>> Thank you for your comments,
>> /Jesper
>>
>>>
>>> -Dmitry
>>>
>>>
>>>
>>> On 2013-03-25 20:29, Jesper Wilhelmsson wrote:
>>>> Hi,
>>>>
>>>> Sorry for cross posting, but I think this could be useful for several
>>>> areas.
>>>>
>>>> I would like to add Solaris Studio / NetBeans project files for the
>>>> entire OpenJDK project. To clarify: One project that contains the entire
>>>> OpenJDK.
>>>>
>>>>
>>>> With the new build infrastructure in JDK 8 building the entire OpenJDK
>>>> is fairly fast and even though I personally mostly work in the HotSpot
>>>> tree, I tend to always clone and build the entire JDK forest. I find
>>>> this to have several benefits.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/
>>>>
>>>> The configuration in this project is currently Mac only. Linux and
>>>> Solaris configurations are also planned.
>>>>
>>>> The webrev is made from the jdk8/build repository which is where I think
>>>> a change like this should go in. Let me know if you think something
>>>> else.
>>>>
>>>>
>>>>
>>>> To use this project (once pushed):
>>>>
>>>> 1. Clone your favorite repository
>>>>      hg clone http://hg.openjdk.java.net/hsx/hotspot-gc
>>>>
>>>> 2. Get the whole forest
>>>>      cd hotspot-gc
>>>>      sh get_source.sh
>>>>
>>>> 3. Configure
>>>>      sh configure
>>>>
>>>> 4. Open Solaris studio / NetBeans and load the project.
>>>>      The project in located in the common directory.
>>>>
>>>>
>>>> Thanks,
>>>> /Jesper
>>>
>>>
>
>


From jesper.wilhelmsson at oracle.com  Mon Mar 25 20:11:28 2013
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Mon, 25 Mar 2013 21:11:28 +0100
Subject: RFR: Project files for Solaris Studio / NetBeans
In-Reply-To: 
References: <51507B60.6030809@oracle.com>
	
	<51509173.6020803@oracle.com>
	
Message-ID: <5150AF70.8080508@oracle.com>

Volker Simonis skrev 25/3/13 8:59 PM:
>
>
> On Mon, Mar 25, 2013 at 7:03 PM, Jesper Wilhelmsson
> > wrote:
>
>     Volker Simonis skrev 25/3/13 6:15 PM:
>
>         Hi Jesper,
>
>         first of all I highly welcome your initiative!
>
>
>     This is a joint initiative with Vladimir Voskresensky who works in the
>     Solaris Studio team.
>
>
>
>         Nevertheless I have some questions:
>
>         - Who will support these project files? As far as I can see, they will
>         have to be updated at least every time a file will be added, renamed
>         or deleted. Experience shows that such kind of project files tend to
>         get outdated very fast. Do you have any ideas how this problem can be
>         addressed?
>
>
>     One thing that was a pleasant surprise to me when I created the nbproject
>     was that if I add new source files, they are automatically brought into the
>     project. And when running make, the code assistant will be updated with the
>     new definitions in the new files. So even if the project file is slightly
>     out of date it will auto-update itself once you run make the first time.
>
>     I don't think I should volunteer to keep the project files up to date, but
>     since I will be using Solaris Studio for my daily work, and since I will be
>     notified about changes in the project files every time I run "hg status", it
>     seems pretty likely that I will push an updated project once in a while.
>     - At least for Mac.
>
>
>         - Where will other platform configurations go to? Will they be all
>         stored in "configurations.xml"
>
>
>     Yes, I think so.
>
>
>         - What about other configurations (i.e. DEBUG, PRODUCT, 32/64bit,
>         CC_INTERP, etc..)? Will they all have to go into the same
>         "configurations.xml"
>
>
>     If I'm not mistaken these are different make targets, right? I don't think
>     you need to have separate configurations saved in the project files for
>     different make targets. Vladimir can answer this much better, but the way I
>     have done it previously has simply been to edit the make command if I wanted
>     to build a different target, and the code assistant is automatically updated
>     when running make ("make clean" may be needed in some cases).
>
>
> These are partially make targets but also preprocessor defines set by various
> make targets. For example you may have different class definitions depending on
> whether "DEBUG" is defined or not. Actually I don't understand how code
> assistants is automatically updated if I do a "make clean" with a different make
> target if I haven't defined the new preprocessor defines for the project. Is
> this by parsing the generated libjvm.so? That's a neat feature of NetBeans but
> as far as I know it only works if the VM is compiled with '-g3' which HotSpot
> isn't by default.

In the current project all info about how the files are compiled are taken from 
the make logs.
/Jesper


>
>
>
>         It seems that the "configurations.xml" might get quite big and complex
>         with all these configurations.
>
>
>     It's not too big right now IMHO. If it starts to grow unexpectedly in the
>     future I agree that we should reconsider the choice to store it in the
>     repository.
>
>     Thank you for your comments,
>     /Jesper
>
>
>
>         Thank you and best regards,
>         Volker
>
>         On Mon, Mar 25, 2013 at 5:29 PM, Jesper Wilhelmsson
>         __>
>         wrote:
>
>             Hi,
>
>             Sorry for cross posting, but I think this could be useful for
>             several areas.
>
>             I would like to add Solaris Studio / NetBeans project files for the
>             entire
>             OpenJDK project. To clarify: One project that contains the entire
>             OpenJDK.
>
>
>             With the new build infrastructure in JDK 8 building the entire
>             OpenJDK is
>             fairly fast and even though I personally mostly work in the HotSpot
>             tree, I
>             tend to always clone and build the entire JDK forest. I find this to
>             have
>             several benefits.
>
>             Webrev: http://cr.openjdk.java.net/~__jwilhelm/7074926/webrev/
>             
>
>             The configuration in this project is currently Mac only. Linux and
>             Solaris
>             configurations are also planned.
>
>             The webrev is made from the jdk8/build repository which is where I
>             think a
>             change like this should go in. Let me know if you think something else.
>
>
>
>             To use this project (once pushed):
>
>             1. Clone your favorite repository
>                  hg clone http://hg.openjdk.java.net/__hsx/hotspot-gc
>             
>
>             2. Get the whole forest
>                  cd hotspot-gc
>                  sh get_source.sh
>
>             3. Configure
>                  sh configure
>
>             4. Open Solaris studio / NetBeans and load the project.
>                  The project in located in the common directory.
>
>
>             Thanks,
>             /Jesper
>
>


From konstantin.shefov at oracle.com  Mon Mar 11 20:07:20 2013
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Tue, 12 Mar 2013 00:07:20 +0400
Subject:  [8] Review request for CR 7145406 - [macosx] Migrate
	Apple tests from macosx-port to 7u
In-Reply-To: <513E3632.20502@oracle.com>
References: <512B3412.1090500@oracle.com> <512B7ED2.8040608@oracle.com>
	<512E0E16.4060708@oracle.com> <512F5553.5030105@oracle.com>
	<512F5FBB.7030203@oracle.com> <512F61EA.9080102@oracle.com>
	<512F6B44.3080808@oracle.com> <513065BB.5070707@oracle.com>
	<513073D7.9030108@oracle.com> <513074FA.2040804@oracle.com>
	<51308269.5070500@oracle.com> <51347B0B.4040709@oracle.com>
	<5137251A.4000607@oracle.com> <513D9DDE.3010600@oracle.com>
	<513E3632.20502@oracle.com>
Message-ID: <513E3978.2000109@oracle.com>

All these tests compile and run under all OSs, not MacOS only.
There are a lot of awt and swing tests that depend on 
test.java.awt.regtesthelpers, they are in the openjdk repo.
Almost none of regression tests are ever run without JTREG.

Konstantin

11.03.2013 23:53, Phil Race ?????:
> Konstantin,
>
> First I am puzzled by the decision to send this to AWT and Swing lists.
> There are a couple of Swing tests and  a large number of AWT tests
> but it seems to be also a very large number of 2D/graphics tests PLUS
> a large scattering in other areas such as
> - hotspot/managment
> - jndi
> - java.io
> - java.nio
> - threading
> - reflection
> - networking.
>
> Next, I am surprised to see jtreg tests that depend on junit.
>
> I just searched our entire regression test suite (including ones that
> are still closed for various reasons) and I didn't find *any* client area
> tests that have this dependency.
>
> All I found are a few core java reflection tests.
> Nor should these tests depend on the harness in "package test.java.awt"
>
> So they should all be standalone tests that can be run without any 
> harness.
>
> On top of that I seriously doubt that these all even *compile* on 
> anything
> besides OS X, and may not pass elsewhere either
>
> cf : 31 import com.apple.eio.FileManager;
> As it is none of this appears appropriate to put into the test directory.
>
> So this
> 1) First needs to be rid of harness dependencies
> 2) Needs to be made to compile on all platforms or invoked by a script
> which builds only on OS X
> 3) All tests that build on all platforms must pass on all platforms
> 4) The review needs to be send to all affected lists - which is pretty 
> much all of them!
> awt, 2d, swing, hotspot, core-libs .. maybe more
>
> -phil.
>
>
>
> On 3/11/2013 2:03 AM, Konstantin Shefov wrote:
>> Please, review the fix.
>>
>> On 06-Mar-13 15:14, Konstantin Shefov wrote:
>>> http://cr.openjdk.java.net/~kshefov/7145406/webrev.02/
>>>
>>> Changed tags to @run junit
>>>
>>> On 04-Mar-13 14:44, Sergey Bylokhov wrote:
>>>> A few options exists:
>>>> 1 Changes tag to @run junit + jtreg 4.1
>>>> 2 Remove usage of junit from these tests.
>>>>
>>>> 01.03.2013 14:26, Alexander Scherbatiy ?????:
>>>>> On 3/1/2013 1:29 PM, Konstantin Shefov wrote:
>>>>>>
>>>>>> On 01-Mar-13 13:24, Sergey Bylokhov wrote:
>>>>>>> 01.03.2013 12:24, Konstantin Shefov wrote:
>>>>>>>> I have already ran those tests on Windows before sending this 
>>>>>>>> request, all is OK 95% pass.
>>>>>>>>
>>>>>>>> I should also note that we (STT regression team) use JTREG 3.2 
>>>>>>>> for testing with option 
>>>>>>>> -cpa:$JEMMY_PATH/jemmy.jar,$JUNIT_PATH/junit.jar
>>>>>>> As far as I understand, jtreg 3 doesn't contain junit.jar.
>>>>>> There is no junit.jar in JTREG 3, but it could be taken elsewhere.
>>>>>> But if it is standard to use @run junit tag, we will replace 
>>>>>> jtreg we use to version 4.1.
>>>>>
>>>>>     The jtreg 3 does not have fix for the issue "7113599 jtreg 
>>>>> should handle GNOME_DESKTOP_SESSION_ID" which affects some L&F 
>>>>> Swing tests on Unix systems.
>>>>>
>>>>>     I would suggest to use the JTreg 4.1. The standard is to use 
>>>>> the @run junit tag for the JTReg 4.1 (in other case the junit lib 
>>>>> is not put to the test JDK classpath).
>>>>>     The junit.jar has been removed from the JTReg 4.1 lib 
>>>>> directory because of the licensing reasons: 
>>>>> https://blogs.oracle.com/jjg/entry/jtreg_update1
>>>>>
>>>>>     Thanks,
>>>>>     Alexandr.
>>>>>
>>>>>>>> JTREG 3.2 is more stable than 4.1. We do not use JTREG 4.1. So 
>>>>>>>> I suggest NOT to replace @run main to @run juint, and, istead 
>>>>>>>> of that add jtreg option -cpa:$JUNIT_PATH/junit.jar
>>>>>>>>
>>>>>>>> On 28-Feb-13 18:35, Sergey Bylokhov wrote:
>>>>>>>>> Hi, Konstantin.
>>>>>>>>> I think yes. Please try to run these tests on windows as well. 
>>>>>>>>> At least they should be compiled.
>>>>>>>>>
>>>>>>>>> 28.02.2013 17:55, Konstantin Shefov wrote:
>>>>>>>>>> I used JTREG 4.1 fcs b03, not b05. Indeed, if one uses b05, 
>>>>>>>>>> one gets compilation errors. So should I replace @run main to 
>>>>>>>>>> @run juint in all 150 tests?
>>>>>>>>>>
>>>>>>>>>> On 28-Feb-13 17:46, Konstantin Shefov wrote:
>>>>>>>>>>> Strange, but I used JTReg 4.1 b05 also and I had no 
>>>>>>>>>>> compilation errors. JUnit is automatically added in the 
>>>>>>>>>>> latest JTREG 4.1.
>>>>>>>>>>>
>>>>>>>>>>> On 28-Feb-13 17:02, Alexander Scherbatiy wrote:
>>>>>>>>>>>> On 2/27/2013 5:45 PM, Konstantin Shefov wrote:
>>>>>>>>>>>>> I replaced Thread.sleep() with toolkit.realSync() and made 
>>>>>>>>>>>>> swing mwthod to run on EDT.
>>>>>>>>>>>>>
>>>>>>>>>>>>> New webrev: 
>>>>>>>>>>>>> http://cr.openjdk.java.net/~kshefov/7145406/webrev.01
>>>>>>>>>>>>>> test/javax/swing/JComponent/DoublePaint/TestDoublePaint.java
>>>>>>>>>>>>>>     - Is it possible to run the test with jtreg or JUnit 
>>>>>>>>>>>>>> is necessary for the test invocation?
>>>>>>>>>>>>
>>>>>>>>>>>>     I run the test and got the compilation error: 
>>>>>>>>>>>> TestDoublePaint.java:34: error: package junit.framework 
>>>>>>>>>>>> does not exist.
>>>>>>>>>>>>     It seems it is because the '@run main TestDoublePaint' 
>>>>>>>>>>>> jtreg task does not put the junit jar to the test jdk class 
>>>>>>>>>>>> path.
>>>>>>>>>>>>     The '@run junit TestDoublePaint' task passes the test. 
>>>>>>>>>>>> (I use the JTReg 4.1 b05 from 
>>>>>>>>>>>> http://download.java.net/openjdk/jtreg/)
>>>>>>>>>>>>     It is also interesting is it necessary to have the main 
>>>>>>>>>>>> method for the junit task?
>>>>>>>>>>>>
>>>>>>>>>>>>    Thanks,
>>>>>>>>>>>>    Alexandr.
>>>>>>>>>>>>
>>>>>>>>>>>>>>     -  line: 68 Thread.sleep(2000); // 2 seconds should 
>>>>>>>>>>>>>> be plenty enough to catch 2 repaints
>>>>>>>>>>>>>>       Is it possible to use the toolkit.realSync() method 
>>>>>>>>>>>>>> here?
>>>>>>>>>>>>>>    - Swing classes should be created and used on the EDT.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   Thanks,
>>>>>>>>>>>>>>   Alexandr.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Konstantin
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>



From konstantin.shefov at oracle.com  Mon Mar 11 20:45:14 2013
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Tue, 12 Mar 2013 00:45:14 +0400
Subject:  [8] Review request for CR 7145406 - [macosx] Migrate
	Apple tests from macosx-port to 7u
In-Reply-To: <513E3D05.8080209@oracle.com>
References: <512B3412.1090500@oracle.com> <512B7ED2.8040608@oracle.com>
	<512E0E16.4060708@oracle.com> <512F5553.5030105@oracle.com>
	<512F5FBB.7030203@oracle.com> <512F61EA.9080102@oracle.com>
	<512F6B44.3080808@oracle.com> <513065BB.5070707@oracle.com>
	<513073D7.9030108@oracle.com> <513074FA.2040804@oracle.com>
	<51308269.5070500@oracle.com> <51347B0B.4040709@oracle.com>
	<5137251A.4000607@oracle.com> <513D9DDE.3010600@oracle.com>
	<513E3632.20502@oracle.com> <513E3978.2000109@oracle.com>
	<513E3D05.8080209@oracle.com>
Message-ID: <513E425A.4030504@oracle.com>

Phil,

12.03.2013 0:22, Phil Race wrote:
> On 3/11/2013 1:07 PM, Konstantin Shefov wrote:
>> All these tests compile and run under all OSs, not MacOS only.
>
> I find that very difficult to believe.
>
> \re\jdk\8\promoted\latest\binaries\windows-i586\bin\javac APIPresent.java
> APIPresent.java:31: error: package com.apple.eio does not exist
> import com.apple.eio.FileManager;
>

Yes, there are actually 6 tests with com.apple.* packages, but the total 
number is about 150, I can send you a pass log on windows and linux later.

>> There are a lot of awt and swing tests that depend on 
>> test.java.awt.regtesthelpers, they are in the openjdk repo.
>
> This is true although that is news to me, I presume this is guaranteed to
> be compiled automatically when you compile the main test.
>

No main test exists, JTREG tags like "@library DIRECTORY_PATH" "@build 
CLASS_NAME" make this test.java.awt.regtesthelpers stuff to compile for 
every single test.

>> Almost none of regression tests are ever run without JTREG.
>
> That's not true. I've been running  and writing reg. tests for 12 years
> and I use jtreg less than 0.01% of the time .. as in I can't remember
> last time I needed to use it. That's the biggest plus we have here.
> You don't *need* a big horrible useless harness that obscures
> the real test. I object strongly to junit dependencies in any of the 
> tests.

SQE teams run automated tests using JTREG rather often (if not always). 
Even manual tests are run with JTREG.

So do you suggest to remove junit from all these tests? All these tests 
depend on junit.

-Konstantin

>
> -phil.
>
>>
>> Konstantin
>>
>> 11.03.2013 23:53, Phil Race wrote:
>>> Konstantin,
>>>
>>> First I am puzzled by the decision to send this to AWT and Swing lists.
>>> There are a couple of Swing tests and  a large number of AWT tests
>>> but it seems to be also a very large number of 2D/graphics tests PLUS
>>> a large scattering in other areas such as
>>> - hotspot/managment
>>> - jndi
>>> - java.io
>>> - java.nio
>>> - threading
>>> - reflection
>>> - networking.
>>>
>>> Next, I am surprised to see jtreg tests that depend on junit.
>>>
>>> I just searched our entire regression test suite (including ones that
>>> are still closed for various reasons) and I didn't find *any* client 
>>> area
>>> tests that have this dependency.
>>>
>>> All I found are a few core java reflection tests.
>>> Nor should these tests depend on the harness in "package test.java.awt"
>>>
>>> So they should all be standalone tests that can be run without any 
>>> harness.
>>>
>>> On top of that I seriously doubt that these all even *compile* on 
>>> anything
>>> besides OS X, and may not pass elsewhere either
>>>
>>> cf : 31 import com.apple.eio.FileManager;
>>> As it is none of this appears appropriate to put into the test 
>>> directory.
>>>
>>> So this
>>> 1) First needs to be rid of harness dependencies
>>> 2) Needs to be made to compile on all platforms or invoked by a script
>>> which builds only on OS X
>>> 3) All tests that build on all platforms must pass on all platforms
>>> 4) The review needs to be send to all affected lists - which is 
>>> pretty much all of them!
>>> awt, 2d, swing, hotspot, core-libs .. maybe more
>>>
>>> -phil.
>>>
>>>
>>>
>>> On 3/11/2013 2:03 AM, Konstantin Shefov wrote:
>>>> Please, review the fix.
>>>>
>>>> On 06-Mar-13 15:14, Konstantin Shefov wrote:
>>>>> http://cr.openjdk.java.net/~kshefov/7145406/webrev.02/
>>>>>
>>>>> Changed tags to @run junit
>>>>>
>>>>> On 04-Mar-13 14:44, Sergey Bylokhov wrote:
>>>>>> A few options exists:
>>>>>> 1 Changes tag to @run junit + jtreg 4.1
>>>>>> 2 Remove usage of junit from these tests.
>>>>>>
>>>>>> 01.03.2013 14:26, Alexander Scherbatiy ?????:
>>>>>>> On 3/1/2013 1:29 PM, Konstantin Shefov wrote:
>>>>>>>>
>>>>>>>> On 01-Mar-13 13:24, Sergey Bylokhov wrote:
>>>>>>>>> 01.03.2013 12:24, Konstantin Shefov wrote:
>>>>>>>>>> I have already ran those tests on Windows before sending this 
>>>>>>>>>> request, all is OK 95% pass.
>>>>>>>>>>
>>>>>>>>>> I should also note that we (STT regression team) use JTREG 
>>>>>>>>>> 3.2 for testing with option 
>>>>>>>>>> -cpa:$JEMMY_PATH/jemmy.jar,$JUNIT_PATH/junit.jar
>>>>>>>>> As far as I understand, jtreg 3 doesn't contain junit.jar.
>>>>>>>> There is no junit.jar in JTREG 3, but it could be taken elsewhere.
>>>>>>>> But if it is standard to use @run junit tag, we will replace 
>>>>>>>> jtreg we use to version 4.1.
>>>>>>>
>>>>>>>     The jtreg 3 does not have fix for the issue "7113599 jtreg 
>>>>>>> should handle GNOME_DESKTOP_SESSION_ID" which affects some L&F 
>>>>>>> Swing tests on Unix systems.
>>>>>>>
>>>>>>>     I would suggest to use the JTreg 4.1. The standard is to use 
>>>>>>> the @run junit tag for the JTReg 4.1 (in other case the junit 
>>>>>>> lib is not put to the test JDK classpath).
>>>>>>>     The junit.jar has been removed from the JTReg 4.1 lib 
>>>>>>> directory because of the licensing reasons: 
>>>>>>> https://blogs.oracle.com/jjg/entry/jtreg_update1
>>>>>>>
>>>>>>>     Thanks,
>>>>>>>     Alexandr.
>>>>>>>
>>>>>>>>>> JTREG 3.2 is more stable than 4.1. We do not use JTREG 4.1. 
>>>>>>>>>> So I suggest NOT to replace @run main to @run juint, and, 
>>>>>>>>>> istead of that add jtreg option -cpa:$JUNIT_PATH/junit.jar
>>>>>>>>>>
>>>>>>>>>> On 28-Feb-13 18:35, Sergey Bylokhov wrote:
>>>>>>>>>>> Hi, Konstantin.
>>>>>>>>>>> I think yes. Please try to run these tests on windows as 
>>>>>>>>>>> well. At least they should be compiled.
>>>>>>>>>>>
>>>>>>>>>>> 28.02.2013 17:55, Konstantin Shefov wrote:
>>>>>>>>>>>> I used JTREG 4.1 fcs b03, not b05. Indeed, if one uses b05, 
>>>>>>>>>>>> one gets compilation errors. So should I replace @run main 
>>>>>>>>>>>> to @run juint in all 150 tests?
>>>>>>>>>>>>
>>>>>>>>>>>> On 28-Feb-13 17:46, Konstantin Shefov wrote:
>>>>>>>>>>>>> Strange, but I used JTReg 4.1 b05 also and I had no 
>>>>>>>>>>>>> compilation errors. JUnit is automatically added in the 
>>>>>>>>>>>>> latest JTREG 4.1.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 28-Feb-13 17:02, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>> On 2/27/2013 5:45 PM, Konstantin Shefov wrote:
>>>>>>>>>>>>>>> I replaced Thread.sleep() with toolkit.realSync() and 
>>>>>>>>>>>>>>> made swing mwthod to run on EDT.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> New webrev: 
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~kshefov/7145406/webrev.01
>>>>>>>>>>>>>>>> test/javax/swing/JComponent/DoublePaint/TestDoublePaint.java 
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>     - Is it possible to run the test with jtreg or 
>>>>>>>>>>>>>>>> JUnit is necessary for the test invocation?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     I run the test and got the compilation error: 
>>>>>>>>>>>>>> TestDoublePaint.java:34: error: package junit.framework 
>>>>>>>>>>>>>> does not exist.
>>>>>>>>>>>>>>     It seems it is because the '@run main 
>>>>>>>>>>>>>> TestDoublePaint' jtreg task does not put the junit jar to 
>>>>>>>>>>>>>> the test jdk class path.
>>>>>>>>>>>>>>     The '@run junit TestDoublePaint' task passes the 
>>>>>>>>>>>>>> test. (I use the JTReg 4.1 b05 from 
>>>>>>>>>>>>>> http://download.java.net/openjdk/jtreg/)
>>>>>>>>>>>>>>     It is also interesting is it necessary to have the 
>>>>>>>>>>>>>> main method for the junit task?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>    Thanks,
>>>>>>>>>>>>>>    Alexandr.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>     -  line: 68 Thread.sleep(2000); // 2 seconds should 
>>>>>>>>>>>>>>>> be plenty enough to catch 2 repaints
>>>>>>>>>>>>>>>>       Is it possible to use the toolkit.realSync() 
>>>>>>>>>>>>>>>> method here?
>>>>>>>>>>>>>>>>    - Swing classes should be created and used on the EDT.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   Thanks,
>>>>>>>>>>>>>>>>   Alexandr.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>> Konstantin
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From michael.hixson at gmail.com  Fri Mar  8 11:36:19 2013
From: michael.hixson at gmail.com (Michael Hixson)
Date: Fri, 08 Mar 2013 11:36:19 -0000
Subject: CFR - updated 8001667: Comparator combinators and extension
	methods
In-Reply-To: <51398BE6.8050009@oracle.com>
References: <51364B80.6030801@oracle.com>
	
	<5137AE8D.5050203@oracle.com>
	
	<51398BE6.8050009@oracle.com>
Message-ID: 

That would get me the functionality I want.  It's the route Guava
took, with ordering.onResultOf(function).  If you do go this route, I
suggest "appliedTo" as another possibility for the name.

I do see this solution as a big improvement over what's there
currently.  It works great for most of the examples in my codebase.

The rest of this email will be more argumentative!

What are the advantages of this over my proposal?  (comparing(f,c) and
c1.thenComparing(f,c2))

One thing I don't like about this, which is an issue shared by
ordering.onResultOf (and ordering.nullsFirst too), is that it reads
"backwards".  If you look at the code and try to translate it to plain
English, it sounds strange.  "Sort the objects comparing X.  No wait!
Apply this other transformation first, and compare those results
instead."  It's not so bad in your version of my original example, but
it scales badly as the sort becomes more complex.

Here's an example from my codebase where I'm using non-natural and
null-friendly orderings in the same place.  I think if you try to
translate it to use your proposed solution, it will demonstrate the
awkwardness:

---------------------------------------------------
// Current code (variable and type names altered slightly):

final Map pagesByAuthorId = ...

// This is declared outside of the sort below to avoid excessive
object allocations.
final Comparator pageOrder = Ordering
    .from((Comparator) (a, b) ->
        CASE_INSENSITIVE_ORDER.compare(a.getTitle(), b.getTitle()))
    .nullsFirst();

authors.sort((a, b) -> ComparisonChain.start()
    .compare(pagesByAuthorId.get(a.getId()),
             pagesByAuthorId.get(b.getId()),
             pageOrder)
    .compare(a.getLastName(), b.getLastName(), CASE_INSENSITIVE_ORDER)
    .compare(a.getId(), b.getId())
    .result());
---------------------------------------------------

To be clear, I'm not unhappy with that code as it is.  It would be
neat if the JDK let write that as clearly (or more clearly?) without
third-party libraries though.

Here's my take at rewriting that using your proposed solution.  I am
assuming I will still need Guava for nulls because you seemed pretty
skeptical about my suggestion there:

---------------------------------------------------
// With c.apply(f):

authors.sort(
    Ordering.from(CASE_INSENSITIVE_ORDER.apply(Page::getTitle)).nullsFirst()
        .apply(author -> pagesByAuthorId.get(author.getId())
        .thenComparing(CASE_INSENSITIVE_ORDER.apply(Author::getLastName))
        .thenComparing(Author::getId));

// In English:
// sort the authors:
//  - ordering from case insensitive order, applied to page title with
nulls first, applied to the author's page
//  - then comparing case insensitive order applied to the author's last name
//  - then comparing the author's id
---------------------------------------------------

The first part of the sort is really weird.  It's so weird that I
think I'd keep my "pageOrder" variable from the first example, even
though hoisting it outside of the call to sort() is no longer a
performance improvement, just because this reads so poorly.

Contrast that with:

---------------------------------------------------
// With comparing(f,c) and c.thenComparing(f,c) and static nullsFirst():

authors.sort(
     comparing(author -> pagesByAuthorId.get(author.getId())
               nullsFirst().thenComparing(
                   Page::getTitle,
                   CASE_INSENSITIVE_ORDER))
         .thenComparing(Author::getLastName, CASE_INSENSITIVE_ORDER)
         .thenComparing(Author::getId));

// In English:
// sort the authors:
//  - comparing the author's page, with nulls first then comparing
page title in case insensitive order
//  - then comparing the author's last name in case insensitive order
//  - then comparing the author's id
---------------------------------------------------

Isn't that easier to read?

-Michael

On Thu, Mar 7, 2013 at 10:57 PM, Henry Jen  wrote:
> I think it all boiled down to re-use an existing Comparator to compare
> for another type.
>
> What about we added this to Comparator as a default method,
>
>>     default  Comparator apply(Function keyExtractor) {
>>         Objects.requireNonNull(keyExtractor);
>>         return (Comparator & Serializable)
>>             (c1, c2) -> compare(keyExtractor.apply(c1), keyExtractor.apply(c2));
>>     }
>
> Then the code you illustrated would be,
>
> people.sort(CASE_INSENSITIVE_ORDER.apply(Person::getLastName)
>         .thenComparing(nullsLast.thenComparing(CASE_INSENSITIVE_ORDER)
>                 .apply(Person::getEmailAddress)));
>
> byKey and byValue is actually added based on the same thought that when
> something is not a Comparable. With above, it can be replaced with
>
> cmp.apply(Map.Entry::getKey);
>
> This is just inverse thinking of comparing, where the thoughts is mainly
> for Comparable and primitive type. For those, comparing/thenComparing is
> a more convenient and comprehensive expression.
>
> Thoughts?
>
> Cheers,
> Henry
>
>
> On 03/06/2013 03:06 PM, Michael Hixson wrote:
>> On Wed, Mar 6, 2013 at 1:01 PM, Henry Jen  wrote:
>>> On 03/06/2013 02:31 AM, Michael Hixson wrote:
>>>
>>>> 1. Why disable the following code even though it is (theoretically) safe?
>>>>
>>>>   Comparator a = comparing(CharSequence::length);
>>>>   Comparator b = a.thenComparing(CASE_INSENSITIVE_ORDER);
>>>>
>>>> That code would compile if the signatures of the thenComparing methods
>>>> had generics like  instead of .  The example above is
>>>> conjured up and ridiculous, but I think real code will have use for
>>>> it.  Is there any downside to narrowing the return type this way?
>>>>
>>>
>>> I think that make sense, will need to do some experiment to make sure it
>>> won't confuse type system when chaining all together, and I am not sure
>>> how much burden this has on inference engine. I prefer simplicity.
>>>
>>> Theoretically, if all function take Comparator carefully allows super
>>> type, which we have, isn't that enough? Your above example can be,
>>>
>>> Comparator a = comparing>> a.thenComparing(CASE_INSENSITIVE_ORDER);
>>>
>>
>> The idea is that I wanted to use both comparators.  It's important
>> that "a" remains Comparator because I want to sort
>> List objects with it and use it to generate other
>> CharSequence-subclass comparators in addition to "b".
>>
>> Also, min/max will need  or else it will break Guava's
>> Ordering class.  The same thing happened a while back with
>> comparator.reverse() (which was then renamed to reverseOrder).  If the
>> only reason for the rename was to unbreak Guava, then if you use > extends T> you could change it back because the signatures will match.
>>
>> (Maybe the Guava devs have more insight about this signature?  They
>> went that route for most of Ordering's methods.  Some of the same
>> reasoning might apply here.)
>>
>>>
>>>> 2. There's a thenComparing(Function), but no thenComparing(Function,
>>>> Comparator).  This seems like a big omission.  Surely people will want
>>>> secondary orderings on fields by something other than natural
>>>> (null-unfriendly) ordering.  Also, a Comparators.comparing(Function,
>>>> Comparator) method would remove the need for all the Map-centric
>>>> methods that are currently in the Comparators class.  For instance:
>>>> comparing(Map.Entry::getValue, naturalOrder()).
>>>>
>>>
>>> Note that Function form must return a Comparable, which implies an order
>>> already. Combine with Comparator.reverseOrder() method, that would cover
>>> the ground.
>>>
>>> If the Comparable is not a fit, probably write a Comparator in lambda is
>>> needed anyway?
>>>
>>>> 3. There is no support for sorting of nullable values or fields.
>>>> Sorting of nullable values directly perhaps should not be encouraged,
>>>> but sorting values by nullable fields within a chained sort is
>>>> completely reasonable.  Please add some support for this, either as
>>>> chain methods on Comparator, or as factory methods on Comparators.
>>>>
>>>
>>> Not sure what do you propose to be added. NULL is a controversial topic,
>>> only application know what it means. Therefore, avoid try to interpret
>>> null is probably a better approach. Write a Comparator if needed.
>>>
>>
>> Regarding comparing(Function,comparator) and nulls - I'm possibly just
>> repeating old arguments but I'll give it another shot.
>>
>> There are use cases for these all over the code base I ported to Java
>> 8.  I'll repost the example from my first email since I think that may
>> answer your question about nulls:
>>
>>   // Sort a list of people by:
>>   //  1) Last name, ignoring case
>>   //  2) Email address, with no email (null) last, ignoring case
>>   people.sort(
>>       comparing(Person::getLastName, CASE_INSENSITIVE_ORDER)
>>           .thenComparing(
>>               Person::getEmailAddress,
>>               nullsLast().thenComparing(CASE_INSENSITIVE_ORDER)));
>>
>> The Comparators class itself presents four use cases for
>> comparing(Function,Comparator).  I don't think they're especially good
>> cases, but: naturalOrderKeys, naturalOrderValues, byKey, byValue could
>> all be done instead as comparing(Map.Entry::get{Key,Value},c).  It is
>> odd to me that four specialized versions of this are being offered (I
>> can't recall the last time I wanted to sort map entries) but the more
>> primitive operation behind them is not.
>>
>> -Michael
>>
>


From huizhe.wang at oracle.com  Mon Mar 25 21:45:54 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 25 Mar 2013 14:45:54 -0700
Subject: netbeans and openjdk
In-Reply-To: <9A7DF021-1EE6-49B9-81B4-AC2922712313@oracle.com>
References: <63D9462D-2B6B-4BD3-89EA-8B93728DEDC3@oracle.com>
	<5150BDD7.6060804@oracle.com>
	<9A7DF021-1EE6-49B9-81B4-AC2922712313@oracle.com>
Message-ID: <5150C592.5050200@oracle.com>

Hi Lance,

On 3/25/2013 2:28 PM, Lance Andersen wrote:
> Hi Joe,
>
> On Mar 25, 2013, at 5:12 PM, huizhe wang  > wrote:
>
>> Hi Lance,
>>
>> Are you setting it up as a free-form project?  In a free-form 
>> project, the custom build script is separate from those generated by 
>> the IDE.  Although you can map targets from the custom build script 
>> to project actions, you won't see properties such as source in the 
>> script reflected in the IDE. Your ide may be configured so that you 
>> may right-click and compile selected file using IDE generated 
>> scripts, but when you 'build' the whole project, you're using the 
>> target in your customer script.  In this case, your build script must 
>> have defined to compile to source 1.5 that seems to be in the shared.xml.
>
> Yes, I was looking at shared.xml and it has the following
>
> 
>             
>             
>             
>             
>             
>                 
>                  excludes="@{excludes}" sourcepath=""
>                     destdir="@{classesdir}" fork="true" 
> executable="${bootstrap.javac}"
>                     debug="${javac.debug}" 
> debuglevel="${javac.debuglevel}">
>                     
>                     
>                     
>                      
>                     
>                     
>                     
>                 
>
>
> So this seems to be the issue.
>
> So I changed the values above just now from  1.5 and 1.6 to both be 1.7
>
> Which worked much better.
>
>
> This works in a jdk7 repository.
>
> It looks like shared.xml was changed for jdk8  so it does not have the 
> values above.

That makes sense.  I mean we specify source/target levels for the 
standalone, endorsed technologies so that they may be used in older 
JDKs.  But for scripts doing that inside the JDK, that's kind of 
interesting :-)

>
>
> Also, do you know why if this is on osx  it is building in
>
> Copying 3 files to 
> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/classes
> Building jar: 
> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/dist/lib/jdb42.jar

I'm not familiar with the script. But it seems to me there's no support 
for OSX in the script that you're using.  Was windows-x86_64 the default 
value?

>
>
> Thank you for your time Joe

You're very welcome.

Best,
Joe

>
> Best
> Lance
>> -Joe
>>
>> On 3/25/2013 1:25 PM, Lance Andersen wrote:
>>> Hi all,
>>>
>>> I am trying to set up a netbeans project for JDBC within openjdk 
>>> leveraging the existing projects that are already in jdk/make/netbeans
>>>
>>> I have getting the following error and not sure why so wondered if 
>>> anyone has encountered this before:
>>>
>>> ------------------------------------------------------
>>>
>>>
>>> ant -f 
>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/jdbc 
>>> clean build
>>> Deleting directory 
>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/depcache
>>> shared.clean:
>>> clean:
>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:128: 
>>> warning: 'includeantruntime' was not set, defaulting to 
>>> build.sysclasspath=last; set to false for repeatable builds
>>> Compiling 96 source files to 
>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/classes
>>> warning: [options] bootstrap class path not set in conjunction with 
>>> -source 1.5
>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/src/share/classes/javax/sql/rowset/serial/SerialClob.java:148: 
>>> error: try-with-resources is not supported in -source 1.5
>>>         try (Reader charStream = clob.getCharacterStream()) {
>>>   (use -source 7 or higher to enable try-with-resources)
>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/src/share/classes/javax/sql/rowset/spi/SyncFactory.java:370: 
>>> error: try-with-resources is not supported in -source 1.5
>>>                     try (FileInputStream fis = new 
>>> FileInputStream(ROWSET_PROPERTIES)) {
>>>   (use -source 7 or higher to enable try-with-resources)
>>> 2 errors
>>> 1 warning
>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:170: 
>>> The following error occurred while executing this line:
>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:155: 
>>> The following error occurred while executing this line:
>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:128: 
>>> Compile failed; see the compiler error output for details.
>>> BUILD FAILED (total time: 2 seconds)
>>>
>>> ----------------------------------------
>>>
>>> If I open the project properties in netbeans, it shows 1.7 source. 
>>>  This is with netbeans 7.3
>>>
>>> Best
>>> Lance
>>>
>>>
>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>> Oracle Java Engineering
>>> 1 Network Drive
>>> Burlington, MA 01803
>>> Lance.Andersen at oracle.com 
>>>
>>>
>>>
>>>
>>
>
>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com 
> 
>
>
>
>



From Lance.Andersen at oracle.com  Mon Mar 25 21:53:13 2013
From: Lance.Andersen at oracle.com (Lance Andersen)
Date: Mon, 25 Mar 2013 17:53:13 -0400
Subject: netbeans and openjdk
In-Reply-To: <9A7DF021-1EE6-49B9-81B4-AC2922712313@oracle.com>
References: <63D9462D-2B6B-4BD3-89EA-8B93728DEDC3@oracle.com>
	<5150BDD7.6060804@oracle.com>
	<9A7DF021-1EE6-49B9-81B4-AC2922712313@oracle.com>
Message-ID: 


On Mar 25, 2013, at 5:28 PM, Lance Andersen  wrote:

> Hi Joe,
> 
> On Mar 25, 2013, at 5:12 PM, huizhe wang  wrote:
> 
>> Hi Lance,
>> 
>> Are you setting it up as a free-form project?  In a free-form project, the custom build script is separate from those generated by the IDE.  Although you can map targets from the custom build script to project actions, you won't see properties such as source in the script reflected in the IDE. Your ide may be configured so that you may right-click and compile selected file using IDE generated scripts, but when you 'build' the whole project, you're using the target in your customer script.  In this case, your build script must have defined to compile to source 1.5 that seems to be in the shared.xml.
> 
> Yes, I was looking at shared.xml and it has the following
> 
> 
>            
>            
>            
>            
>            
>                
>                                    destdir="@{classesdir}" fork="true" executable="${bootstrap.javac}"
>                    debug="${javac.debug}" debuglevel="${javac.debuglevel}">
>                    
>                    
>                    
>                     
>                    
>                    
>                    
>                
> 
> 
> So this seems to be the issue.
> 
> So I changed the values above just now from  1.5 and 1.6 to both be 1.7
> 
> Which worked much better.
> 
> 
> This works in a jdk7 repository.
> 
> It looks like shared.xml was changed for jdk8  so it does not have the values above.
> 
> 
> Also, do you know why if this is on osx  it is building in
> 
> Copying 3 files to /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/classes
> Building jar: /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/dist/lib/jdb42.jar
> 


This appears due to the following error which you see with verbose on for ant

Unable to find property file: /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/architectures/name-Mac OS X.properties

The actual file name the jdk  make/netbeans/architectures  is name-Macosx.properties

The culprit seems to be the -project-init target in shared.xml


        
        
        
        
        

Now perhaps this is a difference between OSX versions?  I will have to try on my work machine as this is my home system which is Mountain Lion and my work is Snow Leopard 



Best
Lance
> 
> Thank you for your time Joe
> 
> Best
> Lance
>> -Joe
>> 
>> On 3/25/2013 1:25 PM, Lance Andersen wrote:
>>> Hi all,
>>> 
>>> I am trying to set up a netbeans project for JDBC within openjdk leveraging the existing projects that are already in jdk/make/netbeans
>>> 
>>> I have getting the following error and not sure why so wondered if anyone has encountered this before:
>>> 
>>> ------------------------------------------------------
>>> 
>>> 
>>> ant -f /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/jdbc clean build
>>> Deleting directory /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/depcache
>>> shared.clean:
>>> clean:
>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:128: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds
>>> Compiling 96 source files to /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/classes
>>> warning: [options] bootstrap class path not set in conjunction with -source 1.5
>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/src/share/classes/javax/sql/rowset/serial/SerialClob.java:148: error: try-with-resources is not supported in -source 1.5
>>>        try (Reader charStream = clob.getCharacterStream()) {
>>>  (use -source 7 or higher to enable try-with-resources)
>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/src/share/classes/javax/sql/rowset/spi/SyncFactory.java:370: error: try-with-resources is not supported in -source 1.5
>>>                    try (FileInputStream fis = new FileInputStream(ROWSET_PROPERTIES)) {
>>>  (use -source 7 or higher to enable try-with-resources)
>>> 2 errors
>>> 1 warning
>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:170: The following error occurred while executing this line:
>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:155: The following error occurred while executing this line:
>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:128: Compile failed; see the compiler error output for details.
>>> BUILD FAILED (total time: 2 seconds)
>>> 
>>> ----------------------------------------
>>> 
>>> If I open the project properties in netbeans, it shows 1.7 source.  This is with netbeans 7.3
>>> 
>>> Best
>>> Lance
>>> 
>>> 
>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>> Oracle Java Engineering
>>> 1 Network Drive
>>> Burlington, MA 01803
>>> Lance.Andersen at oracle.com
>>> 
>>> 
>>> 
>>> 
>> 
> 
> 
> 
> 
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering 
> 1 Network Drive 
> Burlington, MA 01803
> Lance.Andersen at oracle.com
> 
> 
> 
> 




Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com






From mike.duigou at oracle.com  Mon Mar 25 21:54:52 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 25 Mar 2013 14:54:52 -0700
Subject: netbeans and openjdk
In-Reply-To: <9A7DF021-1EE6-49B9-81B4-AC2922712313@oracle.com>
References: <63D9462D-2B6B-4BD3-89EA-8B93728DEDC3@oracle.com>
	<5150BDD7.6060804@oracle.com>
	<9A7DF021-1EE6-49B9-81B4-AC2922712313@oracle.com>
Message-ID: <04560500-13BB-43C6-9BA3-F080894E54E5@oracle.com>


On Mar 25 2013, at 14:28 , Lance Andersen wrote:
> 
> So I changed the values above just now from  1.5 and 1.6 to both be 1.7
> 
> Which worked much better.
> 
> 
> This works in a jdk7 repository.
> 
> It looks like shared.xml was changed for jdk8  so it does not have the values above.

I made this change in the jdk8 repo. I never thought to backport it to jdk1.7. If you make a patch or webrev I will be happy to review it.

> 
> 
> Also, do you know why if this is on osx  it is building in
> 
> Copying 3 files to /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/classes
> Building jar: /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/dist/lib/jdb42.jar

The problem is that there is no macos platform or architecture recognition in the common/architectures folder. I tried creating these files in the jdk8 repo but ran into a problem with Ant offering inconsistent environment (depending on whether the boot jdk was Apple's 6 or Oracle's 7). I haven't tried to resolve these problems in jdk8.

Mike


> 
> Thank you for your time Joe
> 
> Best
> Lance
>> -Joe
>> 
>> On 3/25/2013 1:25 PM, Lance Andersen wrote:
>>> Hi all,
>>> 
>>> I am trying to set up a netbeans project for JDBC within openjdk leveraging the existing projects that are already in jdk/make/netbeans
>>> 
>>> I have getting the following error and not sure why so wondered if anyone has encountered this before:
>>> 
>>> ------------------------------------------------------
>>> 
>>> 
>>> ant -f /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/jdbc clean build
>>> Deleting directory /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/depcache
>>> shared.clean:
>>> clean:
>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:128: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds
>>> Compiling 96 source files to /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/classes
>>> warning: [options] bootstrap class path not set in conjunction with -source 1.5
>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/src/share/classes/javax/sql/rowset/serial/SerialClob.java:148: error: try-with-resources is not supported in -source 1.5
>>>        try (Reader charStream = clob.getCharacterStream()) {
>>>  (use -source 7 or higher to enable try-with-resources)
>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/src/share/classes/javax/sql/rowset/spi/SyncFactory.java:370: error: try-with-resources is not supported in -source 1.5
>>>                    try (FileInputStream fis = new FileInputStream(ROWSET_PROPERTIES)) {
>>>  (use -source 7 or higher to enable try-with-resources)
>>> 2 errors
>>> 1 warning
>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:170: The following error occurred while executing this line:
>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:155: The following error occurred while executing this line:
>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:128: Compile failed; see the compiler error output for details.
>>> BUILD FAILED (total time: 2 seconds)
>>> 
>>> ----------------------------------------
>>> 
>>> If I open the project properties in netbeans, it shows 1.7 source.  This is with netbeans 7.3
>>> 
>>> Best
>>> Lance
>>> 
>>> 
>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>> Oracle Java Engineering
>>> 1 Network Drive
>>> Burlington, MA 01803
>>> Lance.Andersen at oracle.com
>>> 
>>> 
>>> 
>>> 
>> 
> 
> 
> 
> 
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering 
> 1 Network Drive 
> Burlington, MA 01803
> Lance.Andersen at oracle.com
> 
> 
> 
> 



From lance.andersen at oracle.com  Mon Mar 25 22:04:46 2013
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 25 Mar 2013 18:04:46 -0400
Subject: netbeans and openjdk
In-Reply-To: <04560500-13BB-43C6-9BA3-F080894E54E5@oracle.com>
References: <63D9462D-2B6B-4BD3-89EA-8B93728DEDC3@oracle.com>
	<5150BDD7.6060804@oracle.com>
	<9A7DF021-1EE6-49B9-81B4-AC2922712313@oracle.com>
	<04560500-13BB-43C6-9BA3-F080894E54E5@oracle.com>
Message-ID: <9A4255D1-A05A-4116-9EC3-25EED03BDDA2@oracle.com>


On Mar 25, 2013, at 5:54 PM, Mike Duigou  wrote:

> 
> On Mar 25 2013, at 14:28 , Lance Andersen wrote:
>> 
>> So I changed the values above just now from  1.5 and 1.6 to both be 1.7
>> 
>> Which worked much better.
>> 
>> 
>> This works in a jdk7 repository.
>> 
>> It looks like shared.xml was changed for jdk8  so it does not have the values above.
> 
> I made this change in the jdk8 repo. I never thought to backport it to jdk1.7. If you make a patch or webrev I will be happy to review it.

Thank you Mike.  I will look to make this change and send it for a review
> 
>> 
>> 
>> Also, do you know why if this is on osx  it is building in
>> 
>> Copying 3 files to /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/classes
>> Building jar: /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/dist/lib/jdb42.jar
> 
> The problem is that there is no macos platform or architecture recognition in the common/architectures folder. I tried creating these files in the jdk8 repo but ran into a problem with Ant offering inconsistent environment (depending on whether the boot jdk was Apple's 6 or Oracle's 7). I haven't tried to resolve these problems in jdk8.

Thanks for the explanation.  I might try to take a look at this after i make the above change

best
lance
> 
> Mike
> 
> 
>> 
>> Thank you for your time Joe
>> 
>> Best
>> Lance
>>> -Joe
>>> 
>>> On 3/25/2013 1:25 PM, Lance Andersen wrote:
>>>> Hi all,
>>>> 
>>>> I am trying to set up a netbeans project for JDBC within openjdk leveraging the existing projects that are already in jdk/make/netbeans
>>>> 
>>>> I have getting the following error and not sure why so wondered if anyone has encountered this before:
>>>> 
>>>> ------------------------------------------------------
>>>> 
>>>> 
>>>> ant -f /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/jdbc clean build
>>>> Deleting directory /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/depcache
>>>> shared.clean:
>>>> clean:
>>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:128: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds
>>>> Compiling 96 source files to /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/classes
>>>> warning: [options] bootstrap class path not set in conjunction with -source 1.5
>>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/src/share/classes/javax/sql/rowset/serial/SerialClob.java:148: error: try-with-resources is not supported in -source 1.5
>>>>       try (Reader charStream = clob.getCharacterStream()) {
>>>> (use -source 7 or higher to enable try-with-resources)
>>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/src/share/classes/javax/sql/rowset/spi/SyncFactory.java:370: error: try-with-resources is not supported in -source 1.5
>>>>                   try (FileInputStream fis = new FileInputStream(ROWSET_PROPERTIES)) {
>>>> (use -source 7 or higher to enable try-with-resources)
>>>> 2 errors
>>>> 1 warning
>>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:170: The following error occurred while executing this line:
>>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:155: The following error occurred while executing this line:
>>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:128: Compile failed; see the compiler error output for details.
>>>> BUILD FAILED (total time: 2 seconds)
>>>> 
>>>> ----------------------------------------
>>>> 
>>>> If I open the project properties in netbeans, it shows 1.7 source.  This is with netbeans 7.3
>>>> 
>>>> Best
>>>> Lance
>>>> 
>>>> 
>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>> Oracle Java Engineering
>>>> 1 Network Drive
>>>> Burlington, MA 01803
>>>> Lance.Andersen at oracle.com
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>> 
>> 
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering 
>> 1 Network Drive 
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com
>> 
>> 
>> 
>> 
> 




Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com






From david.holmes at oracle.com  Tue Mar 26 00:01:12 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 26 Mar 2013 10:01:12 +1000
Subject: Review 8007703: Remove com.sun.servicetag API
In-Reply-To: <5150AF79.9010206@oracle.com>
References: <511D73CA.90503@oracle.com> <511E0597.2080902@oracle.com>
	<5150AF79.9010206@oracle.com>
Message-ID: <5150E548.3040502@oracle.com>

Hi Mandy,

On 26/03/2013 6:11 AM, Mandy Chung wrote:
> On 2/15/13 1:53 AM, David Holmes wrote:
>> Hi Mandy,
>>
>> On 15/02/2013 9:31 AM, Mandy Chung wrote:
>>> Remove com.sun.servicetag that we no longer support.  This includes
>>> updates the makefiles and so include build-infra to review this
>>> change.
>>
>> This will require a tweak to profile-rtjar-includes.txt once it gets
>> pushed next week. It won't cause any build problems though so it is
>> okay for us to do a follow up CR to make the adjustment.
>>
>
> David,
>
> I have modified profile-includes.txt and profile-rtjar-includes.txt:
>     http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8007703/webrev.01/
>
> Other files are the same as in webrev.00.

This all looks good to me.

Thanks,
David


> Mandy
>
>> David
>>
>>> It's solely JDK implementation-specific that was added to
>>> support JDK product registration and service tag as legacy
>>> Sun-software requirement in 2007.
>>>
>>> Webrev at:
>>>     http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8007703/webrev.00/
>>>
>>> Thanks
>>> Mandy
>


From mandy.chung at oracle.com  Tue Mar 26 00:22:00 2013
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Tue, 26 Mar 2013 00:22:00 +0000
Subject: hg: jdk8/tl/jdk: 8007703: Remove com.sun.servicetag API
Message-ID: <20130326002227.A2616483BD@hg.openjdk.java.net>

Changeset: 5e383a73386a
Author:    mchung
Date:      2013-03-25 17:19 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e383a73386a

8007703: Remove com.sun.servicetag API
Reviewed-by: dholmes, alanb, erikj

! make/com/sun/Makefile
! make/common/Release.gmk
! makefiles/CopyFiles.gmk
! makefiles/CopyIntoClasses.gmk
! makefiles/CreateJars.gmk
! makefiles/GensrcProperties.gmk
! makefiles/profile-includes.txt
! makefiles/profile-rtjar-includes.txt
! test/Makefile



From mandy.chung at oracle.com  Tue Mar 26 01:17:13 2013
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Tue, 26 Mar 2013 01:17:13 +0000
Subject: hg: jdk8/tl/jdk: 8010787: changeset for 8007703 is missing the
	deleted files
Message-ID: <20130326011748.B254C483C1@hg.openjdk.java.net>

Changeset: 335d2156222e
Author:    mchung
Date:      2013-03-25 18:14 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/335d2156222e

8010787: changeset for 8007703 is missing the deleted files
Reviewed-by: dholmes, alanb, erikj

- make/com/sun/servicetag/Makefile
- src/share/classes/com/sun/servicetag/BrowserSupport.java
- src/share/classes/com/sun/servicetag/Installer.java
- src/share/classes/com/sun/servicetag/LinuxSystemEnvironment.java
- src/share/classes/com/sun/servicetag/RegistrationData.java
- src/share/classes/com/sun/servicetag/RegistrationDocument.java
- src/share/classes/com/sun/servicetag/Registry.java
- src/share/classes/com/sun/servicetag/ServiceTag.java
- src/share/classes/com/sun/servicetag/SolarisServiceTag.java
- src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java
- src/share/classes/com/sun/servicetag/SunConnection.java
- src/share/classes/com/sun/servicetag/SystemEnvironment.java
- src/share/classes/com/sun/servicetag/UnauthorizedAccessException.java
- src/share/classes/com/sun/servicetag/Util.java
- src/share/classes/com/sun/servicetag/WindowsSystemEnvironment.java
- src/share/classes/com/sun/servicetag/package.html
- src/share/classes/com/sun/servicetag/resources/Putback-Notes.txt
- src/share/classes/com/sun/servicetag/resources/javase_5_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_6_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_7_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_servicetag.properties
- src/share/classes/com/sun/servicetag/resources/jdk_header.png
- src/share/classes/com/sun/servicetag/resources/product_registration.xsd
- src/share/classes/com/sun/servicetag/resources/register.html
- src/share/classes/com/sun/servicetag/resources/register_ja.html
- src/share/classes/com/sun/servicetag/resources/register_zh_CN.html
- test/com/sun/servicetag/DeleteServiceTag.java
- test/com/sun/servicetag/DuplicateNotFound.java
- test/com/sun/servicetag/FindServiceTags.java
- test/com/sun/servicetag/InstanceUrnCheck.java
- test/com/sun/servicetag/InvalidRegistrationData.java
- test/com/sun/servicetag/InvalidServiceTag.java
- test/com/sun/servicetag/JavaServiceTagTest.java
- test/com/sun/servicetag/JavaServiceTagTest1.java
- test/com/sun/servicetag/NewRegistrationData.java
- test/com/sun/servicetag/SvcTagClient.java
- test/com/sun/servicetag/SystemRegistryTest.java
- test/com/sun/servicetag/TestLoadFromXML.java
- test/com/sun/servicetag/UpdateServiceTagTest.java
- test/com/sun/servicetag/Util.java
- test/com/sun/servicetag/ValidRegistrationData.java
- test/com/sun/servicetag/environ.properties
- test/com/sun/servicetag/missing-environ-field.xml
- test/com/sun/servicetag/newer-registry-version.xml
- test/com/sun/servicetag/registration.xml
- test/com/sun/servicetag/servicetag1.properties
- test/com/sun/servicetag/servicetag2.properties
- test/com/sun/servicetag/servicetag3.properties
- test/com/sun/servicetag/servicetag4.properties
- test/com/sun/servicetag/servicetag5.properties



From michael.fang at oracle.com  Tue Mar 26 02:10:35 2013
From: michael.fang at oracle.com (michael.fang at oracle.com)
Date: Tue, 26 Mar 2013 02:10:35 +0000
Subject: hg: jdk8/tl/corba: 2 new changesets
Message-ID: <20130326021037.A6553483C4@hg.openjdk.java.net>

Changeset: c3ec80715805
Author:    mfang
Date:      2013-03-25 16:53 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/c3ec80715805

8010521: jdk8 l10n resource file translation update 2
Reviewed-by: naoto, yhuang

! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_de.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_es.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_fr.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_it.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ja.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ko.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_pt_BR.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_sv.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_CN.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_TW.properties
! src/share/classes/com/sun/tools/corba/se/idl/idl_ja.prp
! src/share/classes/com/sun/tools/corba/se/idl/idl_zh_CN.prp
! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_ja.prp
! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_zh_CN.prp

Changeset: 910af9c3f338
Author:    mfang
Date:      2013-03-25 18:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/910af9c3f338

Merge




From michael.fang at oracle.com  Tue Mar 26 02:14:22 2013
From: michael.fang at oracle.com (michael.fang at oracle.com)
Date: Tue, 26 Mar 2013 02:14:22 +0000
Subject: hg: jdk8/tl/langtools: 2 new changesets
Message-ID: <20130326021430.20979483C5@hg.openjdk.java.net>

Changeset: fdf30b225e1c
Author:    mfang
Date:      2013-03-25 16:55 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fdf30b225e1c

8010521: jdk8 l10n resource file translation update 2
Reviewed-by: naoto, yhuang

! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_ja.properties
! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_zh_CN.properties
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_ja.properties
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_zh_CN.properties
! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties
! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties
! src/share/classes/com/sun/tools/javac/resources/javac_ja.properties
! src/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties
! src/share/classes/com/sun/tools/javadoc/resources/javadoc_ja.properties
! src/share/classes/com/sun/tools/javadoc/resources/javadoc_zh_CN.properties
! src/share/classes/com/sun/tools/javah/resources/l10n_ja.properties
! src/share/classes/com/sun/tools/javah/resources/l10n_zh_CN.properties

Changeset: 65e1ca8dcdc7
Author:    mfang
Date:      2013-03-25 18:08 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/65e1ca8dcdc7

Merge




From daniel.fuchs at oracle.com  Tue Mar 26 09:04:18 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 26 Mar 2013 10:04:18 +0100
Subject: JDK-8010495: Update JAXP NetBeans project - add support for
	generating javadoc
In-Reply-To: <515080BA.3090000@oracle.com>
References: <515038DA.3010802@oracle.com> <51507946.6050400@oracle.com>
	<51507CBC.1070904@oracle.com> <515080BA.3090000@oracle.com>
Message-ID: <51516492.6090401@oracle.com>

Hi Joe,

On 3/25/13 5:52 PM, huizhe wang wrote:
>
> On 3/25/2013 9:35 AM, Daniel Fuchs wrote:
>> On 3/25/13 5:20 PM, huizhe wang wrote:
>>> Hi Daniel,
>>>
>>> Thanks for doing this.
>>>
>>> JAXP doesn't have these packages: "java/", "org/ietf/jgss/", and
>>> "org/omg/".  Since this is the jaxp repo, it would be fine if only
>>> 'javax/' and 'org/' are included, or 'com/' be excluded.
>>
>> OK - I just copied the pattern shared by all
>> jdk/make/netbeans projects - but I guess I can safely restrict
>> the list to what is actually present in JAXP.
>>
>> That would make it:
>>
>>  203             >                      includes="${includes}" excludes="${excludes}">
>>  204                 
>>  205
>>  206                     
>>  207
>>  208
>>  209                     
>>  210                     
>>  211                 
>
> I'm not familiar with this usage. Does the 'includes' attribute take
> precedence over the package names in  tags?  Will they be ignored
> since 'includes' includes all packages.

In other free form projects defined for JDK, 'includes' and 'excludes'
are global properties defined in the project's properties file.
They control which subset of the sources are considered part of the
project - and are used by the compile target, the javadoc target,
and also to select which files will be seen in NetBeans, etc...

As far as I understand the  selector in packageset in the javadoc
target defines the subset of the subset of the sources for
which javadoc should be generated. So it's a way to scope the
sources defined by includes/excludes down to the set of public
packages for which api documentation is desired.

I think we should keep it like that in JAXP - even though the javadoc
target is currently the only target that would be affected by the
definition of includes/excludes in jaxp/build.properties.

-- daniel

>
> -Joe
>
>>
>>
>> -- daniel
>>
>>>
>>> Regards,
>>> Joe
>>>
>>> On 3/25/2013 4:45 AM, Daniel Fuchs wrote:
>>>> Hi guys,
>>>>
>>>> I'd like to propose a small change to jaxp/build.xml and
>>>> jaxp/nbproject/project.xml - in order to allow editing
>>>> JAXP sources in NetBeans, as well as generating the JAXP
>>>> javadoc for previewing purposes.
>>>>
>>>> I actually stole the javadoc target from
>>>> jdk/make/netbeans/common/shared.xml
>>>>
>>>> The changes are small & targeted at developers.
>>>> There should be no impact on the build process.
>>>>
>>>> Here is the webrev:
>>>>
>>>> http://cr.openjdk.java.net/~dfuchs/JDK-8010495/jdk8/webrev.00/
>>>>
>>>> best regards,
>>>>
>>>> -- daniel
>>>
>>
>



From bourges.laurent at gmail.com  Tue Mar 26 11:00:26 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Tue, 26 Mar 2013 12:00:26 +0100
Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
In-Reply-To: <51508139.9000507@oracle.com>
References: 
	
	<51506136.4020909@oracle.com> <51508139.9000507@oracle.com>
Message-ID: 

Dear all,

First I joined recently the openJDK contributors, and I plan to fix java2D
pisces code in my spare time.

I have a full time job on Aspro2: http://www.jmmc.fr/aspro; it is an
application to prepare astronomical observations at VLTI / CHARA and is
very used in our community (200 users): it provides scientific computations
(observability, model images using complex numbers ...) and zoomable plots
thanks to jFreeChart.

Aspro2 is known to be very efficient (computation parallelization) and I am
often doing profiling using netbeans profiler or visualVM.

To fix huge memory usages by java2d.pisces, I started implementing an
efficient ArrayCache (int[] and float[]) (in thread local to concurrency
problems):
- arrays in sizes between 10 and 10000 (more small arrays used than big
ones)
- resizing support (Arrays.copyOf) without wasting arrays
- reentrance i.e. many arrays are used at the same time (java2D Pisces
stroke / dash creates many segments to render)
- GC / Heap friendly ie support cache eviction and avoid consuming too much
memory

I know object pooling is known to be not efficient with recent VM (GC is
better) but I think it is counter productive to create so many int[] arrays
in java2d.pisces and let the GC remove such wasted memory.

Does someone have implemented such (open source) array cache (core-libs) ?
Opinions are welcome (but avoid "trolls").

Moreover, sun.java2d.pisces.Helpers.widenArray() performs a lot of array
resizing / copy (Arrays.copyOf) that I want to avoid mostly:
    // These use a hardcoded factor of 2 for increasing sizes. Perhaps this
    // should be provided as an argument.
    static float[] widenArray(float[] in, final int cursize, final int
numToAdd) {
        if (in.length >= cursize + numToAdd) {
            return in;
        }
        return Arrays.copyOf(in, 2 * (cursize + numToAdd));
    }

    static int[] widenArray(int[] in, final int cursize, final int
numToAdd) {
        if (in.length >= cursize + numToAdd) {
            return in;
        }
        return Arrays.copyOf(in, 2 * (cursize + numToAdd));
    }

Thanks to Peter Levart, I use its microbench tool (
https://github.com/plevart/micro-bench/tree/v2) to benchmark ArrayCache
operations... and J2DBench to test java2d performances

What is the fastest way to clear an array (part) ie fill by 0:
- public static void fill(int[] a, int fromIndex, int toIndex, int val)
- public static native void arraycopy(Object src,  int  srcPos, Object
dest, int destPos, int length);
- unsafe.setMemory(array, Unsafe.ARRAY_INT_BASE_OFFSET, 512 * SIZEOF_INT,
(byte) 0)

Apparently, Arrays.fill is always faster (size in 10 ... 10 000) !
I suspect hotspot to optimize its code and use native functions, isn't it
???

Benchmarks results:
>> JVM START: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
Testing arrays: int[1]...
#
# ZeroFill: run duration:  5 000 ms, #of logical CPUS: 4
#
# Warm up:
runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK
64-Bit Server VM 25.0-b22]
           1 threads, Tavg =      4,47 ns/op (? =   0,00 ns/op) [     4,47]
runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK
64-Bit Server VM 25.0-b22]
           1 threads, Tavg =      4,40 ns/op (? =   0,00 ns/op) [     4,40]
# Measure:
runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK
64-Bit Server VM 25.0-b22]
           1 threads, Tavg =      4,43 ns/op (? =   0,00 ns/op) [     4,43]
runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK
64-Bit Server VM 25.0-b22]
           2 threads, Tavg =      5,55 ns/op (? =   0,16 ns/op) [
5,40,      5,72]

#
# FillArraySystemCopy: run duration:  5 000 ms, #of logical CPUS: 4
#
# Warm up:
runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM:
1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =      6,47 ns/op (? =   0,00 ns/op) [     6,47]
runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM:
1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =      6,21 ns/op (? =   0,00 ns/op) [     6,21]
# Measure:
runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM:
1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =      6,19 ns/op (? =   0,00 ns/op) [     6,19]
runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM:
1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
           2 threads, Tavg =      7,80 ns/op (? =   0,10 ns/op) [
7,90,      7,71]

#
# FillArrayUnsafe: run duration:  5 000 ms, #of logical CPUS: 4
#
# Warm up:
runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal
[OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =     26,82 ns/op (? =   0,00 ns/op) [    26,82]
runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal
[OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =     23,48 ns/op (? =   0,00 ns/op) [    23,48]
# Measure:
runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal
[OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =     22,42 ns/op (? =   0,00 ns/op) [    22,42]
runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal
[OpenJDK 64-Bit Server VM 25.0-b22]
           2 threads, Tavg =     28,21 ns/op (? =   0,88 ns/op) [
29,11,     27,36]

Testing arrays: int[100]...
#
# ZeroFill: run duration:  5 000 ms, #of logical CPUS: 4
#
# Warm up:
runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK
64-Bit Server VM 25.0-b22]
           1 threads, Tavg =     16,49 ns/op (? =   0,00 ns/op) [    16,49]
runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK
64-Bit Server VM 25.0-b22]
           1 threads, Tavg =     15,97 ns/op (? =   0,00 ns/op) [    15,97]
# Measure:
runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK
64-Bit Server VM 25.0-b22]
           1 threads, Tavg =     16,03 ns/op (? =   0,00 ns/op) [    16,03]
runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK
64-Bit Server VM 25.0-b22]
           2 threads, Tavg =     19,32 ns/op (? =   0,46 ns/op) [
18,87,     19,80]

#
# FillArraySystemCopy: run duration:  5 000 ms, #of logical CPUS: 4
#
# Warm up:
runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM:
1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =     14,51 ns/op (? =   0,00 ns/op) [    14,51]
runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM:
1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =     14,17 ns/op (? =   0,00 ns/op) [    14,17]
# Measure:
runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM:
1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =     14,09 ns/op (? =   0,00 ns/op) [    14,09]
runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM:
1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
           2 threads, Tavg =     31,15 ns/op (? =   4,04 ns/op) [
27,65,     35,67]

#
# FillArrayUnsafe: run duration:  5 000 ms, #of logical CPUS: 4
#
# Warm up:
runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal
[OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =     52,32 ns/op (? =   0,00 ns/op) [    52,32]
runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal
[OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =     52,82 ns/op (? =   0,00 ns/op) [    52,82]
# Measure:
runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal
[OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =     52,19 ns/op (? =   0,00 ns/op) [    52,19]
runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal
[OpenJDK 64-Bit Server VM 25.0-b22]
           2 threads, Tavg =     70,87 ns/op (? =   0,71 ns/op) [
70,17,     71,59]

Testing arrays: int[10000]...
#
# ZeroFill: run duration:  5 000 ms, #of logical CPUS: 4
#
# Warm up:
runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK
64-Bit Server VM 25.0-b22]
           1 threads, Tavg =  1 208,64 ns/op (? =   0,00 ns/op) [ 1 208,64]
runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK
64-Bit Server VM 25.0-b22]
           1 threads, Tavg =  1 238,01 ns/op (? =   0,00 ns/op) [ 1 238,01]
# Measure:
runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK
64-Bit Server VM 25.0-b22]
           1 threads, Tavg =  1 235,81 ns/op (? =   0,00 ns/op) [ 1 235,81]
runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK
64-Bit Server VM 25.0-b22]
           2 threads, Tavg =  1 325,11 ns/op (? =   7,01 ns/op) [
1 332,16,  1 318,14]

#
# FillArraySystemCopy: run duration:  5 000 ms, #of logical CPUS: 4
#
# Warm up:
runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM:
1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =  1 930,93 ns/op (? =   0,00 ns/op) [ 1 930,93]
runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM:
1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =  2 060,80 ns/op (? =   0,00 ns/op) [ 2 060,80]
# Measure:
runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM:
1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =  2 105,21 ns/op (? =   0,00 ns/op) [ 2 105,21]
runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM:
1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
           2 threads, Tavg =  2 160,33 ns/op (? =  13,74 ns/op) [
2 146,68,  2 174,15]

#
# FillArrayUnsafe: run duration:  5 000 ms, #of logical CPUS: 4
#
# Warm up:
runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal
[OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =  3 099,50 ns/op (? =   0,00 ns/op) [ 3 099,50]
runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal
[OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =  3 041,81 ns/op (? =   0,00 ns/op) [ 3 041,81]
# Measure:
runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal
[OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =  3 068,34 ns/op (? =   0,00 ns/op) [ 3 068,34]
runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal
[OpenJDK 64-Bit Server VM 25.0-b22]
           2 threads, Tavg =  3 296,13 ns/op (? =  34,97 ns/op) [
3 331,47,  3 261,53]


PS: java.awt.geom.Path2D has also memory allocation issues:
        void needRoom(boolean needMove, int newCoords) {
            if (needMove && numTypes == 0) {
                throw new IllegalPathStateException("missing initial moveto
"+
                                                    "in path definition");
            }
            int size = pointTypes.length;
            if (numTypes >= size) {
                int grow = size;
                if (grow > EXPAND_MAX) {
                    grow = EXPAND_MAX;
                }
                pointTypes = Arrays.copyOf(pointTypes, size+grow);
            }
            size = floatCoords.length;
            if (numCoords + newCoords > size) {
                int grow = size;
                if (grow > EXPAND_MAX * 2) {
                    grow = EXPAND_MAX * 2;
                }
                if (grow < newCoords) {
                    grow = newCoords;
                }
                floatCoords = Arrays.copyOf(floatCoords, size+grow);
            }
        }

Best regards,
Laurent


From volker.simonis at gmail.com  Tue Mar 26 12:15:11 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 26 Mar 2013 13:15:11 +0100
Subject: arrayLength argument of MethodHandle.asCollector() and failing JCK
	test 'asCollectorIAE01'
Message-ID: 

Hi,

while running JCK test for our PPC port I realized that the test
'asCollectorIAE01' which checks valid and invalid 'arrayLength' arguments
to MethodHandle.asCollector() fails for the current 7u/jdk and jdk8/jdk
sources. Further investigations revealed that the failure is due to the
change "7191102: nightly failures after JSR 292 lazy method handle update
(round 3)" which changed the way how
sun.invoke.util.ValueConversions.varargsArray() works. Apparently, the new
implementation can now handle 'arrayLength' parameters up to 254 while the
old implementation could only handle up to 253 parameters.

However the mentioned JCK test explicitly checks that
MethodHandle.asCollector() throws an exception if called with an
'arrayLength' argument of 254 and fails for current  jdk7u and jdk8 builds
because they can handle such an argument.

The API-documentation of "MethodHandle.asCollector()" is a little vague
because it only states "Throws: IllegalArgumentException - if ...
arrayLength is not a legal array size" but doesn't actually specify which
are "legal array sizes". I therefore think that this is an implementation
detail and the JCK test should not check for values like 254 but only for
the real hard limits imposed by the VM (i.e. 255). I would therefore
propose to exclude the mentioned test from the TCK. Otherwise the API
documentation would have to be changed to explicitly specify the valid
range of 'arrayLength' arguments.

Attached you can find a small test program which can be used to reproduce
the problem. Running the program with a released Java 7 version (which
doesn't contain the change "7191102" yet) will throw an
IllegalArgumentException if MethodHandle.asCollector() is called with an
'arrayLength' argument of 254. On the other hand if the program is beeing
run with a recent JDK8 build (i.e. b82) or a curent build of jdk7u,
MethodHandle.asCollector() will accept 254 as 'arrayLength' parameter and
the generated MethodHandle can indeed be invoked with 254 arguments.

Notice that there already exists a bug which is related to this problem:
"7194534 : MethodHandle.asCollector() throws IAE with "bad parameter count
256" in spite of correct param count" (
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7194534). However it
only objects the fact that for the the old implementation the
IllegalArgumentException wrongly reports 'arrayLength' + 2 instead of
'arrayLength' as the failing argument.

Thank you and best regards,
Volker

From sundararajan.athijegannathan at oracle.com  Tue Mar 26 14:04:34 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Tue, 26 Mar 2013 14:04:34 +0000
Subject: hg: jdk8/tl/nashorn: 4 new changesets
Message-ID: <20130326140438.14F29483DB@hg.openjdk.java.net>

Changeset: ae4ef3102d9c
Author:    lagergren
Date:      2013-03-25 12:01 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ae4ef3102d9c

8017010: index evaluation to a temporary location for index operator much change temporaries to slots, but never scoped vars
Reviewed-by: hannesw, sundar

! src/jdk/nashorn/internal/codegen/Attr.java
! src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodeMachine.java
! src/jdk/nashorn/internal/runtime/regexp/joni/encoding/AsciiTables.java
+ test/script/basic/JDK-8017010.js
+ test/script/basic/JDK-8017010.js.EXPECTED
! test/script/basic/NASHORN-258.js
! test/script/basic/NASHORN-258.js.EXPECTED

Changeset: 15dac7439921
Author:    sundar
Date:      2013-03-25 18:20 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/15dac7439921

8010709: org on the top level doesn't resolve
Reviewed-by: lagergren, hannesw

! src/jdk/nashorn/internal/objects/Global.java
+ test/script/basic/JDK-8010709.js

Changeset: 43e40c08e7f8
Author:    lagergren
Date:      2013-03-26 08:42 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/43e40c08e7f8

8010706: -Dnashorn.args system property to create command lines to wrapped nashorn.jar:s
Reviewed-by: hannesw, sundar

! docs/DEVELOPER_README
! src/jdk/nashorn/internal/runtime/options/Options.java

Changeset: ed60078f0a80
Author:    sundar
Date:      2013-03-26 18:26 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ed60078f0a80

8010720: Linkage problem with java.lang.String.length()
Reviewed-by: hannesw, lagergren

! src/jdk/nashorn/internal/objects/NativeString.java
! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java
+ test/script/basic/JDK-8010720.js



From huizhe.wang at oracle.com  Tue Mar 26 17:42:52 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 26 Mar 2013 10:42:52 -0700
Subject: JDK-8010495: Update JAXP NetBeans project - add support for
	generating javadoc
In-Reply-To: <51516492.6090401@oracle.com>
References: <515038DA.3010802@oracle.com> <51507946.6050400@oracle.com>
	<51507CBC.1070904@oracle.com> <515080BA.3090000@oracle.com>
	<51516492.6090401@oracle.com>
Message-ID: <5151DE1C.9000905@oracle.com>


On 3/26/2013 2:04 AM, Daniel Fuchs wrote:
> Hi Joe,
>
> On 3/25/13 5:52 PM, huizhe wang wrote:
>>
>> On 3/25/2013 9:35 AM, Daniel Fuchs wrote:
>>> On 3/25/13 5:20 PM, huizhe wang wrote:
>>>> Hi Daniel,
>>>>
>>>> Thanks for doing this.
>>>>
>>>> JAXP doesn't have these packages: "java/", "org/ietf/jgss/", and
>>>> "org/omg/".  Since this is the jaxp repo, it would be fine if only
>>>> 'javax/' and 'org/' are included, or 'com/' be excluded.
>>>
>>> OK - I just copied the pattern shared by all
>>> jdk/make/netbeans projects - but I guess I can safely restrict
>>> the list to what is actually present in JAXP.
>>>
>>> That would make it:
>>>
>>>  203             >>                      includes="${includes}" excludes="${excludes}">
>>>  204                 
>>>  205
>>>  206                     
>>>  207
>>>  208
>>>  209                     
>>>  210                     
>>>  211                 
>>
>> I'm not familiar with this usage. Does the 'includes' attribute take
>> precedence over the package names in  tags?  Will they be ignored
>> since 'includes' includes all packages.
>
> In other free form projects defined for JDK, 'includes' and 'excludes'
> are global properties defined in the project's properties file.
> They control which subset of the sources are considered part of the
> project - and are used by the compile target, the javadoc target,
> and also to select which files will be seen in NetBeans, etc...

Yeh, there may be dependencies among different JDK projects.  We don't 
have that for now.  But I'm ok.

>
> As far as I understand the  selector in packageset in the javadoc
> target defines the subset of the subset of the sources for
> which javadoc should be generated. So it's a way to scope the
> sources defined by includes/excludes down to the set of public
> packages for which api documentation is desired.
>
> I think we should keep it like that in JAXP - even though the javadoc
> target is currently the only target that would be affected by the
> definition of includes/excludes in jaxp/build.properties.

I see.  gives impression that the packages selected within the 
selector only take effect when includes/excludes is not defined, which 
was why I was asking.

Thanks,
Joe

>
> -- daniel
>
>>
>> -Joe
>>
>>>
>>>
>>> -- daniel
>>>
>>>>
>>>> Regards,
>>>> Joe
>>>>
>>>> On 3/25/2013 4:45 AM, Daniel Fuchs wrote:
>>>>> Hi guys,
>>>>>
>>>>> I'd like to propose a small change to jaxp/build.xml and
>>>>> jaxp/nbproject/project.xml - in order to allow editing
>>>>> JAXP sources in NetBeans, as well as generating the JAXP
>>>>> javadoc for previewing purposes.
>>>>>
>>>>> I actually stole the javadoc target from
>>>>> jdk/make/netbeans/common/shared.xml
>>>>>
>>>>> The changes are small & targeted at developers.
>>>>> There should be no impact on the build process.
>>>>>
>>>>> Here is the webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~dfuchs/JDK-8010495/jdk8/webrev.00/
>>>>>
>>>>> best regards,
>>>>>
>>>>> -- daniel
>>>>
>>>
>>
>



From dan.xu at oracle.com  Tue Mar 26 19:29:29 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Tue, 26 Mar 2013 12:29:29 -0700
Subject: Review JDK-8010837 - TEST_BUG:
	java/io/FileInputStream/LargeFileAvailable.java fails intermittently
Message-ID: <5151F719.6030503@oracle.com>

Hi All,

In the old JVM function, os::available, it could return negative values 
because lseek() allows the file offset to be set beyond the end of a 
file. In the previous change of removing jvm functions, I wasn't aware 
of that and regardnegative values as invalid and return 0, which causes 
this test failed if it handles negative values. This fixaddressedthis 
problem and added a new testcase to ensure the correctbehaviour when 
available() encounters negative values.

Webrev: http://cr.openjdk.java.net/~dxu/8010837/webrev/

Thanks,

-Dan


From martinrb at google.com  Tue Mar 26 20:41:30 2013
From: martinrb at google.com (martinrb at google.com)
Date: Tue, 26 Mar 2013 20:41:30 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130326204203.53C25483EF@hg.openjdk.java.net>

Changeset: 3b56ef8e1ce1
Author:    martin
Date:      2013-03-26 13:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b56ef8e1ce1

8007905: To add a system property to create zip file without using ZIP64 end table when entry count > 64k
Summary: Provide a system property to inhibit ZIP64 mode for >64k entries
Reviewed-by: alanb, sherman

! src/share/classes/java/util/zip/ZipOutputStream.java
+ test/java/util/zip/EntryCount64k.java

Changeset: 266b43683a2c
Author:    martin
Date:      2013-03-26 13:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/266b43683a2c

8010316: Improve handling of char sequences containing surrogates
Summary: Fix and optimize codePointAt, codePointBefore and similar methods
Reviewed-by: sherman, okutsu, ulfzibis, kizune

! src/share/classes/java/lang/AbstractStringBuilder.java
! src/share/classes/java/lang/Character.java
! test/java/lang/StringBuilder/Supplementary.java



From martinrb at google.com  Tue Mar 26 20:44:55 2013
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 26 Mar 2013 13:44:55 -0700
Subject: zip64 compatibility problems
In-Reply-To: <514B219E.8080200@oracle.com>
References: 
	<50F6010D.5000806@oracle.com>
	
	
	
	<5100C3D2.6040604@oracle.com>
	
	
	<5113D311.7060006@oracle.com>
	
	<51161BD6.3040608@gmail.com>
	
	<51188FE8.40604@oracle.com> <514B219E.8080200@oracle.com>
Message-ID: 

Submitted.


On Thu, Mar 21, 2013 at 8:05 AM, Xueming Shen wrote:

> Martin, 8007905 has been approved.
>
>
> On 2/10/13 10:30 PM, Xueming Shen wrote:
>
>> 8007905.
>>
>> But you will have to hold the push. I will send it through the CCC.
>>
>> -Sherman
>>
>> On 2/10/2013 7:59 PM, Martin Buchholz wrote:
>>
>>> On Sat, Feb 9, 2013 at 1:50 AM, Peter Levart
>>>  wrote:
>>>
>>>  Also, this does not disable ZIP64 - it only disables it when it is not
>>>> needed (most other zip implementations can still read the output)
>>>> "inhibit"
>>>> seems better than "disable".
>>>>
>>>>
>>>> disfavor ?
>>>>
>>>>
>>>>  I went for "inhibit".
>>>
>>> There's now a shiny new test case .
>>> Same Bat Place:
>>> http://cr.openjdk.java.net/~**martin/webrevs/openjdk8/**
>>> useZip64For64kEntries/
>>> I am now happy with this change and would like to submit.
>>> As always, I need a bug id.
>>>
>>
>


From martinrb at google.com  Tue Mar 26 20:45:47 2013
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 26 Mar 2013 13:45:47 -0700
Subject: Please review: surrogate fiddle
In-Reply-To: <514A90A3.1010900@oracle.com>
References: 
	
	
	<5147D0F8.3090101@oracle.com>
	
	<51480152.5010102@oracle.com>
	
	<514A90A3.1010900@oracle.com>
Message-ID: 

On Wed, Mar 20, 2013 at 9:46 PM, Masayoshi Okutsu <
masayoshi.okutsu at oracle.com> wrote:

>  This fix is fine with me.
>

Submitted.


From mandy.chung at oracle.com  Tue Mar 26 21:37:59 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 26 Mar 2013 14:37:59 -0700
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due
	to HashMap leads to Integer allocations (boxing)
In-Reply-To: <51507BE0.6000502@gmail.com>
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com> <514B2E8D.8060701@gmail.com>
	<514B92A7.1000305@oracle.com>
	
	<514C2C94.60700@gmail.com>
	
	<514C4E09.3020008@gmail.com> <514C5C8D.1090406@gmail.com>
	<514C859D.1050705@gmail.com> <51503925.1020403@gmail.com>
	<51507BE0.6000502@gmail.com>
Message-ID: <51521537.8070905@oracle.com>

Hi Peter,

> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.08/index.html
I'm glad that you observe similar performance improvement without the 
need of method handles.  I reviewed this version and realize that the 
map from j.u.l.Level object to LevelEnum can be removed entirely.

sun.util.logging.PlatformLogger is an internal API that should only be 
used by JDK.  The static final int fields representing the level value 
can be changed to be static final LevelEnum type instead.  I checked the 
JDK code that uses PlatformLogger and no code will be impacted by the 
change of the type of these static fields.  So it removes the need to 
map from an integer value to LevelEnum.  Mapping from a j.u.l.Level to 
LevelEnum is trivial - the name of the LevelEnum is the same as 
j.u.l.Level (e.g. LevelEnum.FINEST and Level.FINEST), you can call 
LoggingSupport.getLevelName(javaLevel) to find its name and 
LevelEnum.valueOf(levelName) returns the LevelEnum instance.  However, 
this would require more changes - basically the methods taking "int 
level" as a parameter would be modified to take LevelEnum and getLevel() 
would return LevelEnum too.  I think it's worth doing this cleanup to 
get rid of the unnecessary conversion from int -> enum -> j.u.l.Level 
and vice versa.  I also recommend to rename LevelEnum to Level which is 
an inner class of PlatformLogger.  What do you think of this alternative 
to get rid of the map?

Some other comments of your patch:
- it renames the class JavaLogger to JavaLoggerProxy and the variable 
from logger to loggerProxy. I'm fine with that.
- L162: JavaLoggerProxy.init() to force load of the class which leads to 
separating the initialization of LevelEnum.javaLevel in a new JavaLevel 
class.  The JavaLevel utility methods are not needed if we change the 
static final fields to LevelEnum.

Have you tried:
    Class.forName("sun.util.logging.PlatformLogger.JavaLoggerProxy", 
false, PlatformLogger.getClassLoader());

would this give you the same performance improvement?  If so, you can 
keep the static initialization in the JavaLoggerProxy class.

Thanks for expanding the PlatformLoggerTest to cover additional test 
cases.  It's good that you compare the value of the PlatformLogger 
static final fields with j.u.l.Level.intValue().  You now can use the 
API to compare the LevelEnum with Level rather than reflection.  Perhaps 
you can add the getName() and intValue() methods in LevelEnum class 
(just a thought).

Mandy


On 3/25/13 9:31 AM, Peter Levart wrote:
> Well, Laurent, Mandy,
>
> It turns out that the dispatch speed-up (or lack of slow-down to be 
> precise) is possible without MethodHandles too. Maybe some VM guru 
> could shed some light on this, but the following is currently the 
> fastest variant:
>
> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.08/index.html
>
> What I did is a simple "if" deciding between two call-sites, making 
> sure that each is only dispatching to single class. This only works, 
> if both classes (LoggerProxy and JavaLoggerProxy) are loaded in 
> advance, before 1st invocation on any of them is made (might be that 
> using MethodHandles forced initialization of both classes beforehand 
> and hence the speed-up). If I don't load JavaLoggerProxy before 
> warming-up with LoggerProxy, then when j.u.logging is enabled, speed 
> drops for a factor of almost 4 and never catches up even after very 
> long time.
> This pre-loading also helps for a normal single call site dispatch 
> that dispatches to two distinct classes, but the speed 1st drops when 
> the class changes, and only catches-up after several billions of 
> iterations (30s tight loop on i7).
> Now, because JavaLoggerProxy is initialized early, I had to move the 
> initialization of j.u.logging.Level objects and mappings to a separate 
> class "JavaLevel".
>
> Here are the benchmark results for this last iteration...
>



From joe.darcy at oracle.com  Tue Mar 26 22:43:07 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 26 Mar 2013 15:43:07 -0700
Subject: JDK 8 RFR for JDK-7185456 : (ann) Optimize Annotation handling in
	java/sun.reflect.* code for small number of annotationsC
Message-ID: <5152247B.9080902@oracle.com>

Hello,

Please review this refactoring of how annotations objects are created:

     JDK-7185456 : (ann) Optimize Annotation handling in 
java/sun.reflect.* code for small number of annotationsC
     http://cr.openjdk.java.net/~darcy/7185456.0/

In brief, an annotation object is backed by a hash map with one entry 
per method defined on the annotation type. Currently the default HashMap 
constructor which uses a default capacity of 16 is used. Since most 
annotation type define many fewer methods, some space is wasted. The 
patch (inline below) "right sizes" the HashMap to match the number of 
methods in the annotation type.

Thanks,

-Joe

--- old/src/share/classes/sun/reflect/annotation/AnnotationType.java 
2013-03-26 15:37:22.000000000 -0700
+++ new/src/share/classes/sun/reflect/annotation/AnnotationType.java 
2013-03-26 15:37:22.000000000 -0700
@@ -45,19 +45,18 @@
       * types.  This matches the return value that must be used for a
       * dynamic proxy, allowing for a simple isInstance test.
       */
-    private final Map> memberTypes = new 
HashMap>();
+    private final Map> memberTypes;

      /**
       * Member name -> default value mapping.
       */
-    private final Map memberDefaults =
-        new HashMap();
+    private final Map memberDefaults;

      /**
       * Member name -> Method object mapping. This (and its assoicated
       * accessor) are used only to generate 
AnnotationTypeMismatchExceptions.
       */
-    private final Map members = new HashMap();
+    private final Map members;

      /**
       * The retention policy for this annotation type.
@@ -105,6 +104,9 @@
                  }
              });

+        memberTypes = new HashMap>(methods.length+1, 1.0f);
+        memberDefaults = new HashMap(0);
+        members = new HashMap(methods.length+1, 1.0f);

          for (Method method :  methods) {
              if (method.getParameterTypes().length != 0)


From Mike.Duigou at oracle.com  Tue Mar 26 23:37:13 2013
From: Mike.Duigou at oracle.com (Mike Duigou)
Date: Tue, 26 Mar 2013 16:37:13 -0700
Subject: JDK 8 RFR for JDK-7185456 : (ann) Optimize Annotation handling in
	java/sun.reflect.* code for small number of annotationsC
In-Reply-To: <5152247B.9080902@oracle.com>
References: <5152247B.9080902@oracle.com>
Message-ID: 

This looks fine to me. Nice little optimization (which is no doubt repeated thousands of times for significant wins).

Mike

On Mar 26 2013, at 15:43 , Joe Darcy wrote:

> Hello,
> 
> Please review this refactoring of how annotations objects are created:
> 
>    JDK-7185456 : (ann) Optimize Annotation handling in java/sun.reflect.* code for small number of annotationsC
>    http://cr.openjdk.java.net/~darcy/7185456.0/
> 
> In brief, an annotation object is backed by a hash map with one entry per method defined on the annotation type. Currently the default HashMap constructor which uses a default capacity of 16 is used. Since most annotation type define many fewer methods, some space is wasted. The patch (inline below) "right sizes" the HashMap to match the number of methods in the annotation type.
> 
> Thanks,
> 
> -Joe
> 
> --- old/src/share/classes/sun/reflect/annotation/AnnotationType.java 2013-03-26 15:37:22.000000000 -0700
> +++ new/src/share/classes/sun/reflect/annotation/AnnotationType.java 2013-03-26 15:37:22.000000000 -0700
> @@ -45,19 +45,18 @@
>      * types.  This matches the return value that must be used for a
>      * dynamic proxy, allowing for a simple isInstance test.
>      */
> -    private final Map> memberTypes = new HashMap>();
> +    private final Map> memberTypes;
> 
>     /**
>      * Member name -> default value mapping.
>      */
> -    private final Map memberDefaults =
> -        new HashMap();
> +    private final Map memberDefaults;
> 
>     /**
>      * Member name -> Method object mapping. This (and its assoicated
>      * accessor) are used only to generate AnnotationTypeMismatchExceptions.
>      */
> -    private final Map members = new HashMap();
> +    private final Map members;
> 
>     /**
>      * The retention policy for this annotation type.
> @@ -105,6 +104,9 @@
>                 }
>             });
> 
> +        memberTypes = new HashMap>(methods.length+1, 1.0f);
> +        memberDefaults = new HashMap(0);
> +        members = new HashMap(methods.length+1, 1.0f);
> 
>         for (Method method :  methods) {
>             if (method.getParameterTypes().length != 0)



From joe.darcy at oracle.com  Wed Mar 27 00:17:33 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Wed, 27 Mar 2013 00:17:33 +0000
Subject: hg: jdk8/tl/langtools: 7041251: Use j.u.Objects utility methods in
	langtools
Message-ID: <20130327001738.A090C48400@hg.openjdk.java.net>

Changeset: 330b35b27e68
Author:    darcy
Date:      2013-03-26 17:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/330b35b27e68

7041251: Use j.u.Objects utility methods in langtools
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/util/Pair.java
! src/share/classes/javax/annotation/processing/AbstractProcessor.java



From mike.duigou at oracle.com  Wed Mar 27 00:25:59 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 26 Mar 2013 17:25:59 -0700
Subject: RFR JDK-7143928 : (coll) Optimize for Empty ArrayList and HashMap
Message-ID: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com>

Hello all;

This is a review for optimization work that came out of internal analysis of Oracle's Java applications. It's based upon analysis that shows that in large applications as much as 10% of maps and lists are initialized but never receive any entries. A smaller number spend a large proportion of their lifetime empty. We've found similar results across other workloads as well. This patch is not a substitute for pre-sizing your collections and maps--doing so will *always* have better results.

This patch extends HashMap and ArrayList to provide special handling for newly created instances that avoids creating the backing array until needed. There is a very small additional cost for detecting when to inflate the map or list that is measurable in interpreted tests but disappears in JITed code. 

http://cr.openjdk.java.net/~mduigou/JDK-7143928/0/webrev/

We expect that should this code prove successful in Java 8 it will be backported to Java 7 updates.

The unit test may appear to be somewhat unrelated. It was created after resolving a bug in an early version of this patch to detect the issue encountered (LinkedHashMap.init() was not being called in readObject() when the map was empty).

Mike

From martinrb at google.com  Wed Mar 27 01:13:33 2013
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 26 Mar 2013 18:13:33 -0700
Subject: RFR-8008118
In-Reply-To: 
References: <70b1d9e4-bee6-4355-8694-a7c7771861bf@default>
	
Message-ID: 

8008118
does not appear to be public - could we fix that?

Here is my alternative set of perfectionist changes:

# Cleanup declaration of "environ"
http://cr.openjdk.java.net/~martin/webrevs/openjdk8/environ

# Fix PATH handling
http://cr.openjdk.java.net/~martin/webrevs/openjdk8/pathv/

that could be rolled into one.

I adopted Christos' suggestion of using
continue;

This version only does two allocations.

Martin


On Mon, Mar 25, 2013 at 2:30 PM, Martin Buchholz wrote:

> Since we're all on this perfectionist quest for quality here, I noticed
> that we could replace allocation for path components with a single
> allocation using NUL as a separator.  I think I'll go code that up.
>
> Also note to all: if java VMs are created and destroyed without the
> process terminating, there is a small leak here (and in many other places
> in the JDK).  There would be a huge amount of work if we ever wanted to get
> that right (especially if we supported concurrently active JVMs).
>
>
> On Fri, Mar 22, 2013 at 7:38 AM, John Zavgren wrote:
>
>> Greetings:
>>
>> I made modifications as per Martin's suggestions:
>> 1.) free pathv on "abort".
>> 2.) allocate memory for storing the "cwd" string, and then copy it into
>> the memory location (to make sure that the contents of the pathv[] array
>> don't refer to memory that's from the stack of the procedure that created
>> it.)
>>
>> Thanks!
>> John
>>
>>
>> http://cr.openjdk.java.net/~jzavgren/8008118/webrev.06/
>>
>> ----- Original Message -----
>> From: martinrb at google.com
>> To: christos at zoulas.com
>> Cc: john.zavgren at oracle.com, core-libs-dev at openjdk.java.net
>> Sent: Friday, March 22, 2013 10:19:24 AM GMT -05:00 US/Canada Eastern
>> Subject: Re: RFR-8008118
>>
>>
>>
>>
>> On Thu, Mar 21, 2013 at 12:11 PM, Christos Zoulas wrote:
>>
>>> On Mar 21, 11:36am, john.zavgren at oracle.com (John Zavgren) wrote:
>>> -- Subject: Re: RFR-8008118
>>>
>>> | All:
>>> |
>>> | How does this look?
>>> | 1.) I reverted the for statement formatting change.
>>>
>>> Not exactly. Now it is indented incorrectly.
>>>
>>>
>> Agreed.  Really revert.
>>
>>
>>> | 2.) I removed the goto statement and "inlined" some code instead.
>>>
>>> I prefer to write simpler code that works with both signed and unsigned
>>> indexes:
>>>
>>> +                while (i > 0)
>>> +                    if (pathv[--i] != cwd)
>>> +                        free(pathv[i]);
>>> +
>>>
>>>
>> Christos' suggestion looks pretty good.
>>
>> As Mark noted, need to add missing free of pathv itself.
>>
>>
>>> | 3.) I checked to make sure that we're not freeing memory that we
>>> didn't act=
>>> | ually allocate. (Path vector elements that are empty.)
>>>
>>> You are still using the "./" string literal constant in the code so
>>> you'll
>>> end up freeing it (the compiler will prolly merge the two instances and
>>> you'll get lucky but it is semantically incorrect).
>>>
>>
>> Agreed,
>>
>> pathv[i] = cwd;
>>
>
>


From joe.darcy at oracle.com  Wed Mar 27 01:15:34 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Wed, 27 Mar 2013 01:15:34 +0000
Subject: hg: jdk8/tl/langtools: 7059170: Assume availablility of
	URLClassLoader.close
Message-ID: <20130327011539.80B7848402@hg.openjdk.java.net>

Changeset: 33b6a52f0037
Author:    darcy
Date:      2013-03-26 18:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/33b6a52f0037

7059170: Assume availablility of URLClassLoader.close
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java
- src/share/classes/com/sun/tools/javac/util/CloseableURLClassLoader.java



From mandy.chung at oracle.com  Wed Mar 27 01:29:25 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 26 Mar 2013 18:29:25 -0700
Subject: Review JDK-8010837 - TEST_BUG:
	java/io/FileInputStream/LargeFileAvailable.java fails intermittently
In-Reply-To: <5151F719.6030503@oracle.com>
References: <5151F719.6030503@oracle.com>
Message-ID: <51524B75.3070901@oracle.com>

Hi Dan,

On 3/26/2013 12:29 PM, Dan Xu wrote:
> Hi All,
>
> In the old JVM function, os::available, it could return negative 
> values because lseek() allows the file offset to be set beyond the end 
> of a file. In the previous change of removing jvm functions, I wasn't 
> aware of that and regard negative values as invalid and return 0, 
> which causes this test failed if it handles negative values. This fix 
> addressed this problem and added a new testcase to ensure the correct 
> behaviour when available() encounters negative values.
>
> Webrev: http://cr.openjdk.java.net/~dxu/8010837/webrev/
>

This change looks okay to me.  The spec of FileInputStream.available() 
doesn't say the returned value is non-negative and your fix restores the 
previous behavior and so this is fine.

I suggest to update the synposis of 8010837 to reflect that it's a bug 
in the implementation rather than a test bug.

Mandy



From christos at zoulas.com  Wed Mar 27 01:58:19 2013
From: christos at zoulas.com (Christos Zoulas)
Date: Tue, 26 Mar 2013 21:58:19 -0400
Subject: RFR-8008118
In-Reply-To: 
	from Martin Buchholz (Mar 26,  6:13pm)
Message-ID: <20130327015819.D24BE97129@rebar.astron.com>

On Mar 26,  6:13pm, martinrb at google.com (Martin Buchholz) wrote:
-- Subject: Re: RFR-8008118

| Here is my alternative set of perfectionist changes:

:-)

| # Fix PATH handling
| http://cr.openjdk.java.net/~martin/webrevs/openjdk8/pathv/

LGTM, only question is why error from one allocation throws and from the
other does not? I would move the throw after the:

	 if (splitpath == NULL || pathv == NULL) {

This way we don't need to pass env to xstrdup(). Now you are going to make
me grep on how many xstrdup()'s are in the tree :-)

Correct and simple otherwise.

christos


From martinrb at google.com  Wed Mar 27 02:01:13 2013
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 26 Mar 2013 19:01:13 -0700
Subject: RFR: Optimize StringBuilder.append(null)
Message-ID: 

Oops: I forgot to include core-libs-dev

Forwarded conversation
Subject: RFR: Optimize StringBuilder.append(null)
------------------------

From: *Martin Buchholz* 
Date: Tue, Mar 26, 2013 at 1:54 PM
To: Xueming Shen , Masayoshi Okutsu <
masayoshi.okutsu at oracle.com>, Ulf Zibis , Mike Duigou <
mike.duigou at oracle.com>


Hi! It's me again, fiddlling with StringBuilder.
One of our users noticed that a lot of CPU time was being spent in
StringBuilder.append(null).
We can apply the previously proven optimization that improves it by a
factor of 2 on microbenchmarks.

http://cr.openjdk.java.net/~martin/webrevs/openjdk8/StringBuilder.appendNull/

----------
From: *Mike Duigou* 
Date: Tue, Mar 26, 2013 at 1:58 PM
To: Martin Buchholz 
Cc: Xueming Shen , Masayoshi Okutsu <
masayoshi.okutsu at oracle.com>, Ulf Zibis 


This looks fine to me. Do you need a bug number?

Mike

----------
From: *Martin Buchholz* 
Date: Tue, Mar 26, 2013 at 2:02 PM
To: Mike Duigou 
Cc: Xueming Shen , Masayoshi Okutsu <
masayoshi.okutsu at oracle.com>, Ulf Zibis 





On Tue, Mar 26, 2013 at 1:58 PM, Mike Duigou  wrote:

> This looks fine to me. Do you need a bug number?
>
>
Yes, I do (thanks!)

----------
From: *Mike Duigou* 
Date: Tue, Mar 26, 2013 at 2:12 PM
To: Martin Buchholz 
Cc: Xueming Shen , Masayoshi Okutsu <
masayoshi.okutsu at oracle.com>, Ulf Zibis , Jim Gish <
jim.gish at oracle.com>


I have created:

JDK-8010849: (str) Optimize StringBuilder.append(null)

(yes we know that requiring an Oracle engineer create the bug is a problem.
SOON!)

Mike

----------
From: *Mike Duigou* 
Date: Tue, Mar 26, 2013 at 6:57 PM
To: Martin Buchholz 


Hi Martin;

I hadn't originally noticed but can you make sure to send a RFR through
core-libs-dev for this issue?

Mike


From martinrb at google.com  Wed Mar 27 03:44:21 2013
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 26 Mar 2013 20:44:21 -0700
Subject: RFR-8008118
In-Reply-To: <20130327015819.D24BE97129@rebar.astron.com>
References: 
	<20130327015819.D24BE97129@rebar.astron.com>
Message-ID: 

Of course, I made a (harmless) mistake  in xstrdup.  There is no need to
throw since NEW does that already.

+static char*
+xstrdup(JNIEnv *env, const char *s)
+{
+    size_t size = strlen(s) + 1;
+    char *p = NEW(char, size);
+    if (p != NULL)
+        memcpy(p, s, size);
+    return p;
+}
+




On Tue, Mar 26, 2013 at 6:58 PM, Christos Zoulas wrote:

> On Mar 26,  6:13pm, martinrb at google.com (Martin Buchholz) wrote:LGTM,
> only question is why error from one allocation throws and from the
> other does not? I would move the throw after the:
>
>          if (splitpath == NULL || pathv == NULL) {
>
>
The rule is: failed allocation throws, caller needs to check for and
propagate NULL.


> This way we don't need to pass env to xstrdup(). Now you are going to make
> me grep on how many xstrdup()'s are in the tree :-)
>


From martinrb at google.com  Wed Mar 27 04:29:27 2013
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 26 Mar 2013 21:29:27 -0700
Subject: RFR-8008118
In-Reply-To: 
References: 
	<20130327015819.D24BE97129@rebar.astron.com>
	
Message-ID: 

While on the perfectionist path, I couldn't take the fact that initIDs
hasn't initted any IDs in years, so I've renamed it to plain init.


From martinrb at google.com  Wed Mar 27 05:18:26 2013
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 26 Mar 2013 22:18:26 -0700
Subject: RFR JDK-7143928 : (coll) Optimize for Empty ArrayList and HashMap
In-Reply-To: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com>
References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com>
Message-ID: 

This adds an extra field to every ArrayList - a tax paid by every carefully
constructed ArrayList so that sloppy instances can get away with their
sloppiness, which is pretty distasteful.  If I was going to "spend" an
extra field of ArrayList, it would be to implement a circular array like
ArrayDeque and have O(1) deletion of element 0.

An alternative is to make elementData null when there are no elements.  We
can then reuse the size field for initialCapacity.  Yes, it's true that you
then have to introduce more null checks into the code, but hotspot will
likely do that anyways in the jitted code, and elide them if you provide
them, so cost of the null checks may be zero or even negative!

Much more difficult would be the alternative of automatically snipping the
tail (as with trimToSize) of any inactive ArrayList occasionally, e.g.
after a gc cycle.


From brian.goetz at oracle.com  Wed Mar 27 05:53:08 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 26 Mar 2013 22:53:08 -0700
Subject: RFR JDK-7143928 : (coll) Optimize for Empty ArrayList and HashMap
In-Reply-To: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com>
References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com>
Message-ID: 

What percentage of the empty lists are default-sized?  I suspect it is large, in which case we could apply this trick only for the default-sized lists, and eliminate the extra field.  

On Mar 26, 2013, at 5:25 PM, Mike Duigou wrote:

> Hello all;
> 
> This is a review for optimization work that came out of internal analysis of Oracle's Java applications. It's based upon analysis that shows that in large applications as much as 10% of maps and lists are initialized but never receive any entries. A smaller number spend a large proportion of their lifetime empty. We've found similar results across other workloads as well. This patch is not a substitute for pre-sizing your collections and maps--doing so will *always* have better results.
> 
> This patch extends HashMap and ArrayList to provide special handling for newly created instances that avoids creating the backing array until needed. There is a very small additional cost for detecting when to inflate the map or list that is measurable in interpreted tests but disappears in JITed code. 
> 
> http://cr.openjdk.java.net/~mduigou/JDK-7143928/0/webrev/
> 
> We expect that should this code prove successful in Java 8 it will be backported to Java 7 updates.
> 
> The unit test may appear to be somewhat unrelated. It was created after resolving a bug in an early version of this patch to detect the issue encountered (LinkedHashMap.init() was not being called in readObject() when the map was empty).
> 
> Mike



From forax at univ-mlv.fr  Wed Mar 27 06:26:50 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 27 Mar 2013 07:26:50 +0100
Subject: RFR JDK-7143928 : (coll) Optimize for Empty ArrayList and HashMap
In-Reply-To: 
References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com>
	
Message-ID: <5152912A.7060807@univ-mlv.fr>

On 03/27/2013 06:53 AM, Brian Goetz wrote:
> What percentage of the empty lists are default-sized?  I suspect it is large, in which case we could apply this trick only for the default-sized lists, and eliminate the extra field.

yes, very good idea indeed.

R?mi

>   
>
> On Mar 26, 2013, at 5:25 PM, Mike Duigou wrote:
>
>> Hello all;
>>
>> This is a review for optimization work that came out of internal analysis of Oracle's Java applications. It's based upon analysis that shows that in large applications as much as 10% of maps and lists are initialized but never receive any entries. A smaller number spend a large proportion of their lifetime empty. We've found similar results across other workloads as well. This patch is not a substitute for pre-sizing your collections and maps--doing so will *always* have better results.
>>
>> This patch extends HashMap and ArrayList to provide special handling for newly created instances that avoids creating the backing array until needed. There is a very small additional cost for detecting when to inflate the map or list that is measurable in interpreted tests but disappears in JITed code.
>>
>> http://cr.openjdk.java.net/~mduigou/JDK-7143928/0/webrev/
>>
>> We expect that should this code prove successful in Java 8 it will be backported to Java 7 updates.
>>
>> The unit test may appear to be somewhat unrelated. It was created after resolving a bug in an early version of this patch to detect the issue encountered (LinkedHashMap.init() was not being called in readObject() when the map was empty).
>>
>> Mike



From golovnin at gmx.net  Wed Mar 27 07:00:35 2013
From: golovnin at gmx.net (Andrej Golovnin)
Date: Wed, 27 Mar 2013 08:00:35 +0100
Subject: JDK 8 RFR for JDK-7185456 : (ann) Optimize Annotation handling in
	java/sun.reflect.* code for small number of annotationsC
In-Reply-To: <5152247B.9080902@oracle.com>
References: <5152247B.9080902@oracle.com>
Message-ID: <2CBE4868-5F33-4A5E-A782-84A1985EF94D@gmx.net>

Hello Joe,

when you already going to change the AnnotationType class,
could you also please remove duplicate line (lines 115 and 121
are identical) in the for-loop in the constructor:

https://dl.dropbox.com/u/148428677/jdk8/AnnotationType/webrev.01/index.html

Thanks,
Andrej

On 26.03.2013, at 23:43, Joe Darcy  wrote:

> Hello,
> 
> Please review this refactoring of how annotations objects are created:
> 
>    JDK-7185456 : (ann) Optimize Annotation handling in java/sun.reflect.* code for small number of annotationsC
>    http://cr.openjdk.java.net/~darcy/7185456.0/
> 
> In brief, an annotation object is backed by a hash map with one entry per method defined on the annotation type. Currently the default HashMap constructor which uses a default capacity of 16 is used. Since most annotation type define many fewer methods, some space is wasted. The patch (inline below) "right sizes" the HashMap to match the number of methods in the annotation type.
> 
> Thanks,
> 
> -Joe
> 
> --- old/src/share/classes/sun/reflect/annotation/AnnotationType.java 2013-03-26 15:37:22.000000000 -0700
> +++ new/src/share/classes/sun/reflect/annotation/AnnotationType.java 2013-03-26 15:37:22.000000000 -0700
> @@ -45,19 +45,18 @@
>      * types.  This matches the return value that must be used for a
>      * dynamic proxy, allowing for a simple isInstance test.
>      */
> -    private final Map> memberTypes = new HashMap>();
> +    private final Map> memberTypes;
> 
>     /**
>      * Member name -> default value mapping.
>      */
> -    private final Map memberDefaults =
> -        new HashMap();
> +    private final Map memberDefaults;
> 
>     /**
>      * Member name -> Method object mapping. This (and its assoicated
>      * accessor) are used only to generate AnnotationTypeMismatchExceptions.
>      */
> -    private final Map members = new HashMap();
> +    private final Map members;
> 
>     /**
>      * The retention policy for this annotation type.
> @@ -105,6 +104,9 @@
>                 }
>             });
> 
> +        memberTypes = new HashMap>(methods.length+1, 1.0f);
> +        memberDefaults = new HashMap(0);
> +        members = new HashMap(methods.length+1, 1.0f);
> 
>         for (Method method :  methods) {
>             if (method.getParameterTypes().length != 0)



From dingxmin at linux.vnet.ibm.com  Wed Mar 27 07:48:23 2013
From: dingxmin at linux.vnet.ibm.com (Frank Ding)
Date: Wed, 27 Mar 2013 15:48:23 +0800
Subject: DigitList bug in recent patch
Message-ID: <5152A447.207@linux.vnet.ibm.com>

Hi guys,
   We noticed there is a recent change (patch @ 
http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/bc1f16f5566f ) that changed 
the behavior of the following program.

import java.math.RoundingMode;
public class TestNumberFormat {

     public static void main(String[] args) {

         java.text.NumberFormat numberFormat = 
java.text.NumberFormat.getInstance(
                 java.util.Locale.US);
         double v = 78.00005;
         numberFormat.setMaximumFractionDigits(4);
         numberFormat.setRoundingMode(RoundingMode.HALF_EVEN);
         numberFormat.setMinimumFractionDigits(0);
         numberFormat.setGroupingUsed(false);
         String ret = numberFormat.format(v);
         System.out.println(ret);
     }
}

Note the rounding mode HALF_EVEN and the expected output should be "78" 
which can also be verified by running previous jdk (before b73).

Stepping into code and the suspicious code is in 
DigitList.shouldRoundUp().  allDecimalDigits is false so true is 
returned, causing the last digit in fraction part to be 1.
             case HALF_EVEN:
                 // Implement IEEE half-even rounding
                 if (digits[maximumDigits] > '5') {
                     return true;
                 } else if (digits[maximumDigits] == '5' ) {
                     if (maximumDigits == (count - 1)) {
                         // the rounding position is exactly the last 
index :
                         if (alreadyRounded)
                             // If FloatingDecimal rounded up (value was 
below tie),
                             // then we should not round up again.
                             return false;

                         if (!allDecimalDigits)
                             // Otherwise if the digits dont represent 
exact value,
                             // value was above tie and FloatingDecimal 
truncated
                             // digits to tie. We must round up.
                             return true;

Since I am not familiar of the numeric conversion, can any one shed your 
light on it?

Best regards,
Frank



From dingxmin at linux.vnet.ibm.com  Wed Mar 27 07:50:32 2013
From: dingxmin at linux.vnet.ibm.com (Frank Ding)
Date: Wed, 27 Mar 2013 15:50:32 +0800
Subject: DigitList bug in recent patch
In-Reply-To: <5152A447.207@linux.vnet.ibm.com>
References: <5152A447.207@linux.vnet.ibm.com>
Message-ID: <5152A4C8.7020100@linux.vnet.ibm.com>

Current JDK gives the output of "78.0001".

Best regards,
Frank

On 3/27/2013 3:48 PM, Frank Ding wrote:
> Hi guys,
>   We noticed there is a recent change (patch @ 
> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/bc1f16f5566f ) that 
> changed the behavior of the following program.
>
> import java.math.RoundingMode;
> public class TestNumberFormat {
>
>     public static void main(String[] args) {
>
>         java.text.NumberFormat numberFormat = 
> java.text.NumberFormat.getInstance(
>                 java.util.Locale.US);
>         double v = 78.00005;
>         numberFormat.setMaximumFractionDigits(4);
>         numberFormat.setRoundingMode(RoundingMode.HALF_EVEN);
>         numberFormat.setMinimumFractionDigits(0);
>         numberFormat.setGroupingUsed(false);
>         String ret = numberFormat.format(v);
>         System.out.println(ret);
>     }
> }
>
> Note the rounding mode HALF_EVEN and the expected output should be 
> "78" which can also be verified by running previous jdk (before b73).
>
> Stepping into code and the suspicious code is in 
> DigitList.shouldRoundUp().  allDecimalDigits is false so true is 
> returned, causing the last digit in fraction part to be 1.
>             case HALF_EVEN:
>                 // Implement IEEE half-even rounding
>                 if (digits[maximumDigits] > '5') {
>                     return true;
>                 } else if (digits[maximumDigits] == '5' ) {
>                     if (maximumDigits == (count - 1)) {
>                         // the rounding position is exactly the last 
> index :
>                         if (alreadyRounded)
>                             // If FloatingDecimal rounded up (value 
> was below tie),
>                             // then we should not round up again.
>                             return false;
>
>                         if (!allDecimalDigits)
>                             // Otherwise if the digits dont represent 
> exact value,
>                             // value was above tie and FloatingDecimal 
> truncated
>                             // digits to tie. We must round up.
>                             return true;
>
> Since I am not familiar of the numeric conversion, can any one shed 
> your light on it?
>
> Best regards,
> Frank



From peter.levart at gmail.com  Wed Mar 27 08:01:31 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 27 Mar 2013 09:01:31 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due
	to HashMap leads to Integer allocations (boxing)
In-Reply-To: <51521537.8070905@oracle.com>
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com> <514B2E8D.8060701@gmail.com>
	<514B92A7.1000305@oracle.com>
	
	<514C2C94.60700@gmail.com>
	
	<514C4E09.3020008@gmail.com> <514C5C8D.1090406@gmail.com>
	<514C859D.1050705@gmail.com> <51503925.1020403@gmail.com>
	<51507BE0.6000502@gmail.com> <51521537.8070905@oracle.com>
Message-ID: <5152A75B.7020408@gmail.com>

On 03/26/2013 10:37 PM, Mandy Chung wrote:
> Hi Peter,
>
>> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.08/index.html
> I'm glad that you observe similar performance improvement without the 
> need of method handles.  I reviewed this version and realize that the 
> map from j.u.l.Level object to LevelEnum can be removed entirely.
>
> sun.util.logging.PlatformLogger is an internal API that should only be 
> used by JDK.  The static final int fields representing the level value 
> can be changed to be static final LevelEnum type instead.  I checked 
> the JDK code that uses PlatformLogger and no code will be impacted by 
> the change of the type of these static fields.  So it removes the need 
> to map from an integer value to LevelEnum.  Mapping from a j.u.l.Level 
> to LevelEnum is trivial - the name of the LevelEnum is the same as 
> j.u.l.Level (e.g. LevelEnum.FINEST and Level.FINEST), you can call 
> LoggingSupport.getLevelName(javaLevel) to find its name and 
> LevelEnum.valueOf(levelName) returns the LevelEnum instance. However, 
> this would require more changes - basically the methods taking "int 
> level" as a parameter would be modified to take LevelEnum and 
> getLevel() would return LevelEnum too.  I think it's worth doing this 
> cleanup to get rid of the unnecessary conversion from int -> enum -> 
> j.u.l.Level and vice versa.  I also recommend to rename LevelEnum to 
> Level which is an inner class of PlatformLogger.  What do you think of 
> this alternative to get rid of the map?

This is exactly what I was thinking too, but didn't know who uses the 
API... So if the whole JDK builds with API changes, we are fine? No 
outside usages?

>
> Some other comments of your patch:
> - it renames the class JavaLogger to JavaLoggerProxy and the variable 
> from logger to loggerProxy. I'm fine with that.
> - L162: JavaLoggerProxy.init() to force load of the class which leads 
> to separating the initialization of LevelEnum.javaLevel in a new 
> JavaLevel class.  The JavaLevel utility methods are not needed if we 
> change the static final fields to LevelEnum.
>
> Have you tried:
> Class.forName("sun.util.logging.PlatformLogger.JavaLoggerProxy", 
> false, PlatformLogger.getClassLoader());
>
> would this give you the same performance improvement?  If so, you can 
> keep the static initialization in the JavaLoggerProxy class.

Another way is: JavaLoggerProxy.class.getName(); I think it should. If 
JIT only depends on loaded classes (and not whether they have already 
been initialized or not). Will try...

>
> Thanks for expanding the PlatformLoggerTest to cover additional test 
> cases.  It's good that you compare the value of the PlatformLogger 
> static final fields with j.u.l.Level.intValue(). You now can use the 
> API to compare the LevelEnum with Level rather than reflection.  
> Perhaps you can add the getName() and intValue() methods in LevelEnum 
> class (just a thought).

Many more simplifications are possible if we change the API. Stay tuned.

Regards, Peter

>
> Mandy
>
>
> On 3/25/13 9:31 AM, Peter Levart wrote:
>> Well, Laurent, Mandy,
>>
>> It turns out that the dispatch speed-up (or lack of slow-down to be 
>> precise) is possible without MethodHandles too. Maybe some VM guru 
>> could shed some light on this, but the following is currently the 
>> fastest variant:
>>
>> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.08/index.html
>>
>> What I did is a simple "if" deciding between two call-sites, making 
>> sure that each is only dispatching to single class. This only works, 
>> if both classes (LoggerProxy and JavaLoggerProxy) are loaded in 
>> advance, before 1st invocation on any of them is made (might be that 
>> using MethodHandles forced initialization of both classes beforehand 
>> and hence the speed-up). If I don't load JavaLoggerProxy before 
>> warming-up with LoggerProxy, then when j.u.logging is enabled, speed 
>> drops for a factor of almost 4 and never catches up even after very 
>> long time.
>> This pre-loading also helps for a normal single call site dispatch 
>> that dispatches to two distinct classes, but the speed 1st drops when 
>> the class changes, and only catches-up after several billions of 
>> iterations (30s tight loop on i7).
>> Now, because JavaLoggerProxy is initialized early, I had to move the 
>> initialization of j.u.logging.Level objects and mappings to a 
>> separate class "JavaLevel".
>>
>> Here are the benchmark results for this last iteration...
>>
>



From joel.franck at oracle.com  Wed Mar 27 08:41:39 2013
From: joel.franck at oracle.com (=?ISO-8859-1?Q?Joel_Borggr=E9n-Franck?=)
Date: Wed, 27 Mar 2013 09:41:39 +0100
Subject: JDK 8 RFR for JDK-7185456 : (ann) Optimize Annotation handling
	in java/sun.reflect.* code for small number of annotationsC
In-Reply-To: <5152247B.9080902@oracle.com>
References: <5152247B.9080902@oracle.com>
Message-ID: <5152B0C3.8050702@oracle.com>

Hi Joe,

Looks good to me.

I would include Andrej's suggestion of removing one of the members.put(...).

cheers
/Joel

On 03/26/2013 11:43 PM, Joe Darcy wrote:
> Hello,
>
> Please review this refactoring of how annotations objects are created:
>
>      JDK-7185456 : (ann) Optimize Annotation handling in java/sun.reflect.*
> code for small number of annotationsC
>      http://cr.openjdk.java.net/~darcy/7185456.0/
>
> In brief, an annotation object is backed by a hash map with one entry per
> method defined on the annotation type. Currently the default HashMap
> constructor which uses a default capacity of 16 is used. Since most
> annotation type define many fewer methods, some space is wasted. The patch
> (inline below) "right sizes" the HashMap to match the number of methods in
> the annotation type.
>
> Thanks,
>
> -Joe
>
> --- old/src/share/classes/sun/reflect/annotation/AnnotationType.java
> 2013-03-26 15:37:22.000000000 -0700
> +++ new/src/share/classes/sun/reflect/annotation/AnnotationType.java
> 2013-03-26 15:37:22.000000000 -0700
> @@ -45,19 +45,18 @@
>        * types.  This matches the return value that must be used for a
>        * dynamic proxy, allowing for a simple isInstance test.
>        */
> -    private final Map> memberTypes = new
> HashMap>();
> +    private final Map> memberTypes;
>
>       /**
>        * Member name -> default value mapping.
>        */
> -    private final Map memberDefaults =
> -        new HashMap();
> +    private final Map memberDefaults;
>
>       /**
>        * Member name -> Method object mapping. This (and its assoicated
>        * accessor) are used only to generate AnnotationTypeMismatchExceptions.
>        */
> -    private final Map members = new HashMap();
> +    private final Map members;
>
>       /**
>        * The retention policy for this annotation type.
> @@ -105,6 +104,9 @@
>                   }
>               });
>
> +        memberTypes = new HashMap>(methods.length+1, 1.0f);
> +        memberDefaults = new HashMap(0);
> +        members = new HashMap(methods.length+1, 1.0f);
>
>           for (Method method :  methods) {
>               if (method.getParameterTypes().length != 0)


From bourges.laurent at gmail.com  Wed Mar 27 09:32:03 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Wed, 27 Mar 2013 10:32:03 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due to
	HashMap leads to Integer allocations (boxing)
In-Reply-To: <5152A75B.7020408@gmail.com>
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com> <514B2E8D.8060701@gmail.com>
	<514B92A7.1000305@oracle.com>
	
	<514C2C94.60700@gmail.com>
	
	<514C4E09.3020008@gmail.com> <514C5C8D.1090406@gmail.com>
	<514C859D.1050705@gmail.com> <51503925.1020403@gmail.com>
	<51507BE0.6000502@gmail.com> <51521537.8070905@oracle.com>
	<5152A75B.7020408@gmail.com>
Message-ID: 

Hi Mandy, Peter,

thanks for the review.

I wanted the patch to be small and only in PlatformLogger class without API
change to be easily backported to jdk7u.
Do you think this bug is JDK8 only ?

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010309

I submitted another patch concerning missing
PlatformLogger.isLoggable(level) in the JDK (java.net, java.awt mainly) but
it is not widely used as I thought first.

see http://mail.openjdk.java.net/pipermail/awt-dev/2013-March/004459.html

Maybe in the future, other projects or JDK parts will use it if it is no
more a performance bottleneck.

Cheers,
Laurent


From peter.levart at gmail.com  Wed Mar 27 10:19:51 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 27 Mar 2013 11:19:51 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due
	to HashMap leads to Integer allocations (boxing)
In-Reply-To: 
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com> <514B2E8D.8060701@gmail.com>
	<514B92A7.1000305@oracle.com>
	
	<514C2C94.60700@gmail.com>
	
	<514C4E09.3020008@gmail.com> <514C5C8D.1090406@gmail.com>
	<514C859D.1050705@gmail.com> <51503925.1020403@gmail.com>
	<51507BE0.6000502@gmail.com> <51521537.8070905@oracle.com>
	<5152A75B.7020408@gmail.com>
	
Message-ID: <5152C7C7.9060003@gmail.com>

On 03/27/2013 10:32 AM, Laurent Bourg?s wrote:
> Hi Mandy, Peter,
>
> thanks for the review.
>
> I wanted the patch to be small and only in PlatformLogger class 
> without API change to be easily backported to jdk7u.
> Do you think this bug is JDK8 only ?

I think this API level change is source-level-compatible, so only a JDK 
rebuild is required. Will try it anyway and check whether this is true. 
If it is then the backport is not a problem.

Regards, Peter

>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010309
>
> I submitted another patch concerning missing 
> PlatformLogger.isLoggable(level) in the JDK (java.net 
> , java.awt mainly) but it is not widely used as I 
> thought first.
>
> see http://mail.openjdk.java.net/pipermail/awt-dev/2013-March/004459.html
>
> Maybe in the future, other projects or JDK parts will use it if it is 
> no more a performance bottleneck.
>
> Cheers,
> Laurent
>



From heiko.wagner at apis.de  Wed Mar 27 10:25:52 2013
From: heiko.wagner at apis.de (Heiko Wagner)
Date: Wed, 27 Mar 2013 11:25:52 +0100
Subject: JDK1.7u17 Windows 8 compatibility issue: platform LAF does not work
Message-ID: <8BADF1E4FAE44BA7917F981B10F30DED@HEIKOXP>

I am just facing a compatibility issue with Java 7u17 and Windows 8. When I
am in "desktop mode" and want to set the platform LAF everything works in
case the default Windows theme is set (the one that looks similar to Win7).
When Windows 8 is set to a high contrast theme (black background +
whil/yellow foreground), setting of the platform LAF no loger works. Here is
the stack trace:

java.lang.NullPointerException
 at com.sun.java.swing.plaf.windows.XPStyle$Skin.getWidth(Unknown Source)
 at com.sun.java.swing.plaf.windows.XPStyle$Skin.getWidth(Unknown Source)
 at
com.sun.java.swing.plaf.windows.WindowsPopupMenuUI.getGutterWidth(Unknown
Source)
 at
com.sun.java.swing.plaf.windows.WindowsLookAndFeel.initVistaComponentDefault
s(Unknown Source)
 at
com.sun.java.swing.plaf.windows.WindowsLookAndFeel.initComponentDefaults(Unk
nown Source)
 at javax.swing.plaf.basic.BasicLookAndFeel.getDefaults(Unknown Source)
 at javax.swing.UIManager.setLookAndFeel(Unknown Source)
 at javax.swing.UIManager.setLookAndFeel(Unknown Source)

Is this problem already known and scheduled for a later update version?

Regards,
Heiko





From peter.levart at gmail.com  Wed Mar 27 12:31:58 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 27 Mar 2013 13:31:58 +0100
Subject: JDK 8 RFR for JDK-7185456 : (ann) Optimize Annotation handling
	in java/sun.reflect.* code for small number of annotationsC
In-Reply-To: <5152247B.9080902@oracle.com>
References: <5152247B.9080902@oracle.com>
Message-ID: <5152E6BE.4070109@gmail.com>

On 03/26/2013 11:43 PM, Joe Darcy wrote:
> Hello,
>
> Please review this refactoring of how annotations objects are created:
>
>     JDK-7185456 : (ann) Optimize Annotation handling in 
> java/sun.reflect.* code for small number of annotationsC
>     http://cr.openjdk.java.net/~darcy/7185456.0/
>
> In brief, an annotation object is backed by a hash map with one entry 
> per method defined on the annotation type. Currently the default 
> HashMap constructor which uses a default capacity of 16 is used. Since 
> most annotation type define many fewer methods, some space is wasted. 
> The patch (inline below) "right sizes" the HashMap to match the number 
> of methods in the annotation type.

This optimization is good, although these are HashMaps that hold default 
values, methods and types of members - not member values of actual 
annotation objects (only one instance of each such map exists per 
annotation interface). The Map holding values is created in 
AnnotationParser (line 230) (it's actually LinkedHashMap, presumably to 
maintain order for toString method). This is already pre-sized correctly 
as it's constructor takes defaults which are later overridden in a 
parsing loop which can re-size the map as it fits. This re-sizing could 
be eliminated though. I also don't know whether having LinkedHashMap 
instead of plain HashMap is necessary, since it is initialized with 
defaults from plain HashMap (which is hashCode % capacity ordered) and 
only some of defaults are overridden in parsing loop in general. For 
example, having this annotation:

@interface Ann {
     String one();
     String two() default "2";
}

and usage:

@Ann(one = "1")

...toString will print: @Ann(two = "2", one = "1")

So replacing LinkedHashMap with plain HashMap in parser would be another 
optimization opportunity.

This is just speculation: It might be possible to replace it with 
IdentityHashMap which is even more compact. Since keys are always 
obtained from Method.getName() and are therefore pre-interned, so 
interning them before putting them into the map in parser would present 
no-overhead. Lookup (in AnnotationInvocationHandler) is always taking 
the Method.getName so this is also taken care of already.

Regards, Peter

>
> Thanks,
>
> -Joe
>
> --- old/src/share/classes/sun/reflect/annotation/AnnotationType.java 
> 2013-03-26 15:37:22.000000000 -0700
> +++ new/src/share/classes/sun/reflect/annotation/AnnotationType.java 
> 2013-03-26 15:37:22.000000000 -0700
> @@ -45,19 +45,18 @@
>       * types.  This matches the return value that must be used for a
>       * dynamic proxy, allowing for a simple isInstance test.
>       */
> -    private final Map> memberTypes = new 
> HashMap>();
> +    private final Map> memberTypes;
>
>      /**
>       * Member name -> default value mapping.
>       */
> -    private final Map memberDefaults =
> -        new HashMap();
> +    private final Map memberDefaults;
>
>      /**
>       * Member name -> Method object mapping. This (and its assoicated
>       * accessor) are used only to generate 
> AnnotationTypeMismatchExceptions.
>       */
> -    private final Map members = new HashMap Method>();
> +    private final Map members;
>
>      /**
>       * The retention policy for this annotation type.
> @@ -105,6 +104,9 @@
>                  }
>              });
>
> +        memberTypes = new HashMap>(methods.length+1, 
> 1.0f);
> +        memberDefaults = new HashMap(0);
> +        members = new HashMap(methods.length+1, 1.0f);
>
>          for (Method method :  methods) {
>              if (method.getParameterTypes().length != 0)



From joel.franck at oracle.com  Wed Mar 27 13:00:58 2013
From: joel.franck at oracle.com (=?ISO-8859-1?Q?Joel_Borggr=E9n-Franck?=)
Date: Wed, 27 Mar 2013 14:00:58 +0100
Subject: JDK 8 RFR for JDK-7185456 : (ann) Optimize Annotation handling
	in java/sun.reflect.* code for small number of annotationsC
In-Reply-To: <5152E6BE.4070109@gmail.com>
References: <5152247B.9080902@oracle.com> <5152E6BE.4070109@gmail.com>
Message-ID: <5152ED8A.80403@oracle.com>

Hi Peter,

On 03/27/2013 01:31 PM, Peter Levart wrote:

> I also don't know
> whether having LinkedHashMap instead of plain HashMap is necessary, since it
> is initialized with defaults from plain HashMap (which is hashCode %
> capacity ordered) and only some of defaults are overridden in parsing loop
> in general. For example, having this annotation:
>
> @interface Ann {
>      String one();
>      String two() default "2";
> }
>
> and usage:
>
> @Ann(one = "1")
>
> ...toString will print: @Ann(two = "2", one = "1")
>

While there perhaps is no natural ordering between the sets of default 
elements and non-default elements you probably want an order following 
source as closely as possible among the non-default elements.

cheers
/Joel


From peter.levart at gmail.com  Wed Mar 27 14:00:05 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 27 Mar 2013 15:00:05 +0100
Subject: JDK 8 RFR for JDK-7185456 : (ann) Optimize Annotation handling
	in java/sun.reflect.* code for small number of annotationsC
In-Reply-To: <5152ED8A.80403@oracle.com>
References: <5152247B.9080902@oracle.com> <5152E6BE.4070109@gmail.com>
	<5152ED8A.80403@oracle.com>
Message-ID: <5152FB65.2030106@gmail.com>

On 03/27/2013 02:00 PM, Joel Borggr?n-Franck wrote:
> Hi Peter,
>
> On 03/27/2013 01:31 PM, Peter Levart wrote:
>
>> I also don't know
>> whether having LinkedHashMap instead of plain HashMap is necessary, 
>> since it
>> is initialized with defaults from plain HashMap (which is hashCode %
>> capacity ordered) and only some of defaults are overridden in parsing 
>> loop
>> in general. For example, having this annotation:
>>
>> @interface Ann {
>>      String one();
>>      String two() default "2";
>> }
>>
>> and usage:
>>
>> @Ann(one = "1")
>>
>> ...toString will print: @Ann(two = "2", one = "1")
>>
>
> While there perhaps is no natural ordering between the sets of default 
> elements and non-default elements you probably want an order following 
> source as closely as possible among the non-default elements.

What is the order of elements in java class file (the bytes that the 
parser interprets)? Is it taken from the declaration of annotation (the 
order of methods in annotation interface) or from the use-site of the 
annotation? Is this specified?

Regards, Peter

>
> cheers
> /Joel



From joel.franck at oracle.com  Wed Mar 27 14:18:03 2013
From: joel.franck at oracle.com (=?ISO-8859-1?Q?Joel_Borggr=E9n-Franck?=)
Date: Wed, 27 Mar 2013 15:18:03 +0100
Subject: JDK 8 RFR for JDK-7185456 : (ann) Optimize Annotation handling
	in java/sun.reflect.* code for small number of annotationsC
In-Reply-To: <5152FB65.2030106@gmail.com>
References: <5152247B.9080902@oracle.com> <5152E6BE.4070109@gmail.com>
	<5152ED8A.80403@oracle.com> <5152FB65.2030106@gmail.com>
Message-ID: <5152FF9B.2050602@oracle.com>


On 03/27/2013 03:00 PM, Peter Levart wrote:
> On 03/27/2013 02:00 PM, Joel Borggr?n-Franck wrote:
>> Hi Peter,
>>
>> On 03/27/2013 01:31 PM, Peter Levart wrote:
>>
>>> I also don't know
>>> whether having LinkedHashMap instead of plain HashMap is necessary, since it
>>> is initialized with defaults from plain HashMap (which is hashCode %
>>> capacity ordered) and only some of defaults are overridden in parsing loop
>>> in general. For example, having this annotation:
>>>
>>> @interface Ann {
>>>      String one();
>>>      String two() default "2";
>>> }
>>>
>>> and usage:
>>>
>>> @Ann(one = "1")
>>>
>>> ...toString will print: @Ann(two = "2", one = "1")
>>>
>>
>> While there perhaps is no natural ordering between the sets of default
>> elements and non-default elements you probably want an order following
>> source as closely as possible among the non-default elements.
>
> What is the order of elements in java class file (the bytes that the parser
> interprets)? Is it taken from the declaration of annotation (the order of
> methods in annotation interface) or from the use-site of the annotation? Is
> this specified?
>

In general javac tries to keep source order on "things" when emitting to a 
class file. I believe this is often specified as natural order, but don't 
trust me on this. In this specific case I would guess element use order from 
the annotatio instance.

In the following small example I note that 'b' comes before 'a' in the const 
pool but the RuntimeInvisibleAnnotations 'a' is before 'b'. I don't think 
this is a coincidence.

anno-order$ cat T.java
@T(a="XYZ", b="DEF")
public @interface T {
     String b();
     String a();
}

anno-order$ javap -v T.class
Classfile /localhome/src/test/anno-order/T.class
   Last modified Mar 27, 2013; size 239 bytes
   MD5 checksum e1c7d8d76842d219c9853463af37830a
   Compiled from "T.java"
public interface T extends java.lang.annotation.Annotation
   SourceFile: "T.java"
   RuntimeInvisibleAnnotations:
     0: #10(#6=s#11,#4=s#12)
   minor version: 0
   major version: 52
   flags: ACC_PUBLIC, ACC_INTERFACE, ACC_ABSTRACT, ACC_ANNOTATION
Constant pool:
    #1 = Class              #13            //  T
    #2 = Class              #14            //  java/lang/Object
    #3 = Class              #15            //  java/lang/annotation/Annotation
    #4 = Utf8               b
    #5 = Utf8               ()Ljava/lang/String;
    #6 = Utf8               a
    #7 = Utf8               SourceFile
    #8 = Utf8               T.java
    #9 = Utf8               RuntimeInvisibleAnnotations
   #10 = Utf8               LT;
   #11 = Utf8               XYZ
   #12 = Utf8               DEF
   #13 = Utf8               T
   #14 = Utf8               java/lang/Object
   #15 = Utf8               java/lang/annotation/Annotation

For more examples of order discussions see the recent discussion on 
enhanced-metadata-spec-discuss at openjdk.java.net on annotation ordering in 
reflection and javax.lang.model.

cheers
/Joel


From stefan.karlsson at oracle.com  Wed Mar 27 14:23:38 2013
From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com)
Date: Wed, 27 Mar 2013 14:23:38 +0000
Subject: hg: jdk8/tl/jdk: 8009427: Re-enable tests that were disable to ease
	complicated push
Message-ID: <20130327142359.A5C2F48416@hg.openjdk.java.net>

Changeset: caafe6dca35d
Author:    ehelin
Date:      2013-03-21 20:35 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/caafe6dca35d

8009427: Re-enable tests that were disable to ease complicated push
Reviewed-by: sla, mchung, dcubed
Contributed-by: Erik Helin 

! test/ProblemList.txt



From brian.burkhalter at oracle.com  Wed Mar 27 14:29:52 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 27 Mar 2013 07:29:52 -0700
Subject: DigitList bug in recent patch
In-Reply-To: <5152A4C8.7020100@linux.vnet.ibm.com>
References: <5152A447.207@linux.vnet.ibm.com>
	<5152A4C8.7020100@linux.vnet.ibm.com>
Message-ID: <99B7F50E-7DB3-4BA5-8E08-69B8D931AC61@oracle.com>

Interesting. This week I was just running some regression tests against the updated patch for 7032154 (not yet posted) and the only failures I found were in the HALF_* cases in TieRoundingTest.

I'll check out what you reported while looking into it.

Thanks,

Brian

On Mar 27, 2013, at 12:50 AM, Frank Ding wrote:

> Current JDK gives the output of "78.0001".
> 
> Best regards,
> Frank
> 
> On 3/27/2013 3:48 PM, Frank Ding wrote:
>> Hi guys,
>>  We noticed there is a recent change (patch @ http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/bc1f16f5566f ) that changed the behavior of the following program.
>> 
>> import java.math.RoundingMode;
>> public class TestNumberFormat {
>> 
>>    public static void main(String[] args) {
>> 
>>        java.text.NumberFormat numberFormat = java.text.NumberFormat.getInstance(
>>                java.util.Locale.US);
>>        double v = 78.00005;
>>        numberFormat.setMaximumFractionDigits(4);
>>        numberFormat.setRoundingMode(RoundingMode.HALF_EVEN);
>>        numberFormat.setMinimumFractionDigits(0);
>>        numberFormat.setGroupingUsed(false);
>>        String ret = numberFormat.format(v);
>>        System.out.println(ret);
>>    }
>> }
>> 
>> Note the rounding mode HALF_EVEN and the expected output should be "78" which can also be verified by running previous jdk (before b73).
>> 
>> Stepping into code and the suspicious code is in DigitList.shouldRoundUp().  allDecimalDigits is false so true is returned, causing the last digit in fraction part to be 1.
>>            case HALF_EVEN:
>>                // Implement IEEE half-even rounding
>>                if (digits[maximumDigits] > '5') {
>>                    return true;
>>                } else if (digits[maximumDigits] == '5' ) {
>>                    if (maximumDigits == (count - 1)) {
>>                        // the rounding position is exactly the last index :
>>                        if (alreadyRounded)
>>                            // If FloatingDecimal rounded up (value was below tie),
>>                            // then we should not round up again.
>>                            return false;
>> 
>>                        if (!allDecimalDigits)
>>                            // Otherwise if the digits dont represent exact value,
>>                            // value was above tie and FloatingDecimal truncated
>>                            // digits to tie. We must round up.
>>                            return true;
>> 
>> Since I am not familiar of the numeric conversion, can any one shed your light on it?
>> 
>> Best regards,
>> Frank
> 



From christos at zoulas.com  Wed Mar 27 14:41:19 2013
From: christos at zoulas.com (Christos Zoulas)
Date: Wed, 27 Mar 2013 10:41:19 -0400
Subject: DefaultProxySelector socks override
Message-ID: <20130327144119.413AC97129@rebar.astron.com>


This trivial patch add "socksNonProxyHosts" to the default proxy,
so that we can select which socket traffic will be directed to
the proxy and which not. There is currently no way to do this. In
my scenario, I have applications that would benefit in terms of
performance to connect directly to our internal network hosts, and
at the same time need to connect to the outside via our socks proxy.
Having all of them go through the socks proxy would require me to
buy a very expensive proxy, and suffer the latency anyway. I would 
also like to note that the "socksNonProxyHosts" variable is in:

jdk/src/share/native/java/lang/System.c:        PUTPROP(props, "socksNonProxyHosts", sprops->exceptionList);

for MacOS/X but nowhere else. Finally (not in this patch), it would
be nice to provide socks.nonProxyHosts etc. to be symmetric with the
other http, https, and ftp variables. But this is purely cosmetic. And
here's the patch...

Enjoy,

christos

--- jdk/src/share/classes/sun/net/spi/DefaultProxySelector.java.orig	Wed Mar 27 10:26:36 2013 -0400
+++ jdk/src/share/classes/sun/net/spi/DefaultProxySelector.java	Wed Mar 27 10:28:15 2013 -0400
@@ -124,6 +124,7 @@
         final String defaultVal;
         static NonProxyInfo ftpNonProxyInfo = new NonProxyInfo("ftp.nonProxyHosts", null, null, defStringVal);
         static NonProxyInfo httpNonProxyInfo = new NonProxyInfo("http.nonProxyHosts", null, null, defStringVal);
+        static NonProxyInfo socksNonProxyInfo = new NonProxyInfo("socksNonProxyHosts", null, null, defStringVal);
 
         NonProxyInfo(String p, String s, RegexpPool pool, String d) {
             property = p;
@@ -186,7 +187,9 @@
             pinfo = NonProxyInfo.httpNonProxyInfo;
         } else if ("ftp".equalsIgnoreCase(protocol)) {
             pinfo = NonProxyInfo.ftpNonProxyInfo;
-        }
+        } else if ("socket".equalsIgnoreCase(protocol)) {
+            pinfo = NonProxyInfo.socksNonProxyInfo;
+        }
 
         /**
          * Let's check the System properties for that protocol


From mike.duigou at oracle.com  Wed Mar 27 15:02:55 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 27 Mar 2013 08:02:55 -0700
Subject: RFR JDK-7143928 : (coll) Optimize for Empty ArrayList and HashMap
In-Reply-To: 
References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com>
	
Message-ID: <30E35219-D90D-4D71-94FD-45A90F04EE59@oracle.com>

This seems like a good idea. I will follow up with the performance people to see if their findings include the requested initial size.

Mike

On Mar 26 2013, at 22:53 , Brian Goetz wrote:

> What percentage of the empty lists are default-sized?  I suspect it is large, in which case we could apply this trick only for the default-sized lists, and eliminate the extra field.  
> 
> On Mar 26, 2013, at 5:25 PM, Mike Duigou wrote:
> 
>> Hello all;
>> 
>> This is a review for optimization work that came out of internal analysis of Oracle's Java applications. It's based upon analysis that shows that in large applications as much as 10% of maps and lists are initialized but never receive any entries. A smaller number spend a large proportion of their lifetime empty. We've found similar results across other workloads as well. This patch is not a substitute for pre-sizing your collections and maps--doing so will *always* have better results.
>> 
>> This patch extends HashMap and ArrayList to provide special handling for newly created instances that avoids creating the backing array until needed. There is a very small additional cost for detecting when to inflate the map or list that is measurable in interpreted tests but disappears in JITed code. 
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-7143928/0/webrev/
>> 
>> We expect that should this code prove successful in Java 8 it will be backported to Java 7 updates.
>> 
>> The unit test may appear to be somewhat unrelated. It was created after resolving a bug in an early version of this patch to detect the issue encountered (LinkedHashMap.init() was not being called in readObject() when the map was empty).
>> 
>> Mike
> 



From mandy.chung at oracle.com  Wed Mar 27 15:33:51 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 27 Mar 2013 08:33:51 -0700
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due
	to HashMap leads to Integer allocations (boxing)
In-Reply-To: <5152C7C7.9060003@gmail.com>
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com> <514B2E8D.8060701@gmail.com>
	<514B92A7.1000305@oracle.com>
	
	<514C2C94.60700@gmail.com>
	
	<514C4E09.3020008@gmail.com> <514C5C8D.1090406@gmail.com>
	<514C859D.1050705@gmail.com> <51503925.1020403@gmail.com>
	<51507BE0.6000502@gmail.com> <51521537.8070905@oracle.com>
	<5152A75B.7020408@gmail.com>
	
	<5152C7C7.9060003@gmail.com>
Message-ID: <5153115F.20902@oracle.com>

On 3/27/2013 3:19 AM, Peter Levart wrote:
> On 03/27/2013 10:32 AM, Laurent Bourg?s wrote:
>> Hi Mandy, Peter,
>>
>> thanks for the review.
>>
>> I wanted the patch to be small and only in PlatformLogger class 
>> without API change to be easily backported to jdk7u.
>> Do you think this bug is JDK8 only ?
>
> I think this API level change is source-level-compatible, so only a 
> JDK rebuild is required. Will try it anyway and check whether this is 
> true. If it is then the backport is not a problem.
>

I think changing the field type is small and can be easily 
backported.    I have no issue to backport this change to jdk7u. The 
rename of the JavaLogger class and logger field has modified many lines 
of code and it's low risk but it isn't absolutely necessary.  Perhaps 
you can consider dropping the renaming to keep the fix smaller.

>
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010309
>>
>> I submitted another patch concerning missing 
>> PlatformLogger.isLoggable(level) in the JDK (java.net 
>> , java.awt mainly) but it is not widely used as I 
>> thought first.
>>
>> see http://mail.openjdk.java.net/pipermail/awt-dev/2013-March/004459.html
>>
>> Maybe in the future, other projects or JDK parts will use it if it is 
>> no more a performance bottleneck.

Yes we want other parts of JDK to use it.  There is a RFE to convert the 
remaining JDK component to use PlatformLogger:
   http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7054233

Mandy

>>
>> Cheers,
>> Laurent
>>
>



From fweimer at redhat.com  Wed Mar 27 15:48:53 2013
From: fweimer at redhat.com (Florian Weimer)
Date: Wed, 27 Mar 2013 16:48:53 +0100
Subject: RFR JDK-8003245
In-Reply-To: <4d13ecf0-ed5d-4afd-8c03-6f3b6e5a6929@default>
References: <4d13ecf0-ed5d-4afd-8c03-6f3b6e5a6929@default>
Message-ID: <515314E5.5000608@redhat.com>

On 03/20/2013 04:27 PM, John Zavgren wrote:
> Please consider the following changes that eliminate the use of uninitialized memory.

> http://cr.openjdk.java.net/~jzavgren/8003245/webrev.01/

Is the uninitialized memory accessed on the error paths?

-- 
Florian Weimer / Red Hat Product Security Team


From chris.hegarty at oracle.com  Wed Mar 27 15:54:20 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 27 Mar 2013 15:54:20 +0000
Subject: DefaultProxySelector socks override
In-Reply-To: <20130327144119.413AC97129@rebar.astron.com>
References: <20130327144119.413AC97129@rebar.astron.com>
Message-ID: <5153162C.1010401@oracle.com>

[cc'ing net-dev, we can then probably drop core-libs-dev and continue 
the discussion over on net-dev]

Christos,

SOCKS is really old and not as widely deployed as other proxies. That 
said, I don't have any specific problem with your proposal. SOCKS is 
really in maintenance mode in the JDK, but I do see this as a reasonable 
request/proposal.

Since socksNonProxyHosts is only set on Mac I can only presume that it 
is a remanent of the mac port. I would prefer to make the cosmetic 
changes as part of this patch. I cannot see that we need to keep 
socksNonProxyHosts, as it does nothing in the JDK anyway.

Can you do this?

-Chris.

On 03/27/2013 02:41 PM, christos at zoulas.com wrote:
> This trivial patch add "socksNonProxyHosts" to the default proxy,
> so that we can select which socket traffic will be directed to
> the proxy and which not. There is currently no way to do this. In
> my scenario, I have applications that would benefit in terms of
> performance to connect directly to our internal network hosts, and
> at the same time need to connect to the outside via our socks proxy.
> Having all of them go through the socks proxy would require me to
> buy a very expensive proxy, and suffer the latency anyway. I would
> also like to note that the "socksNonProxyHosts" variable is in:
>
> jdk/src/share/native/java/lang/System.c:        PUTPROP(props, "socksNonProxyHosts", sprops->exceptionList);
>
> for MacOS/X but nowhere else. Finally (not in this patch), it would
> be nice to provide socks.nonProxyHosts etc. to be symmetric with the
> other http, https, and ftp variables. But this is purely cosmetic. And
> here's the patch...
>
> Enjoy,
>
> christos
>
> --- jdk/src/share/classes/sun/net/spi/DefaultProxySelector.java.orig	Wed Mar 27 10:26:36 2013 -0400
> +++ jdk/src/share/classes/sun/net/spi/DefaultProxySelector.java	Wed Mar 27 10:28:15 2013 -0400
> @@ -124,6 +124,7 @@
>           final String defaultVal;
>           static NonProxyInfo ftpNonProxyInfo = new NonProxyInfo("ftp.nonProxyHosts", null, null, defStringVal);
>           static NonProxyInfo httpNonProxyInfo = new NonProxyInfo("http.nonProxyHosts", null, null, defStringVal);
> +        static NonProxyInfo socksNonProxyInfo = new NonProxyInfo("socksNonProxyHosts", null, null, defStringVal);
>
>           NonProxyInfo(String p, String s, RegexpPool pool, String d) {
>               property = p;
> @@ -186,7 +187,9 @@
>               pinfo = NonProxyInfo.httpNonProxyInfo;
>           } else if ("ftp".equalsIgnoreCase(protocol)) {
>               pinfo = NonProxyInfo.ftpNonProxyInfo;
> -        }
> +        } else if ("socket".equalsIgnoreCase(protocol)) {
> +            pinfo = NonProxyInfo.socksNonProxyInfo;
> +        }
>
>           /**
>            * Let's check the System properties for that protocol
>


From mark.sheppard at oracle.com  Wed Mar 27 16:01:47 2013
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Wed, 27 Mar 2013 16:01:47 +0000
Subject: RFR: JDK-8007799 Base64.getEncoder(0, byte[]) returns encoder that
	unexpectedly inserts line separator when using some of the encoding
	methods
Message-ID: <515317EB.8020207@oracle.com>

Hi,
    please oblige and review the webrev below as a fix for the issue 
raised in JDK-8007799

http://cr.openjdk.java.net/~msheppar/8007799/webrev.00/

Description:
"Specification for the method
java.util.Base64.getEncoder(int lineLength, byte[] lineSeparator)

says:
Parameters:
     lineLength - the length of each output line (rounded down to 
nearest multiple of 4). If lineLength <= 0 the output will not be 
separated in lines

However if a zero line length is specified encoding methods wrap() and 
encode(ByteBuffer src, ByteBuffer dst, int bytesOut) return encoded 
string which starts from the given line separator. "

the patch adds a check for linemax  > 0 whenever a line separator might 
be added, and adds an new test case.

regards
Mark


From jesper.wilhelmsson at oracle.com  Wed Mar 27 16:04:19 2013
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Wed, 27 Mar 2013 17:04:19 +0100
Subject: RFR: Project files for Solaris Studio / NetBeans
In-Reply-To: <51507B60.6030809@oracle.com>
References: <51507B60.6030809@oracle.com>
Message-ID: <51531883.7070903@oracle.com>

Hi,

A new webrev is now available. The issues reported from the first review should 
be fixed and the project now contains configurations for both Linux_64 and Mac_64.

To select configuration there is a dropdown menu next to the build button.

http://cr.openjdk.java.net/~jwilhelm/7074926/webrev.2/

Thanks,
/Jesper


Jesper Wilhelmsson skrev 25/3/13 5:29 PM:
> Hi,
>
> Sorry for cross posting, but I think this could be useful for several areas.
>
> I would like to add Solaris Studio / NetBeans project files for the entire
> OpenJDK project. To clarify: One project that contains the entire OpenJDK.
>
>
> With the new build infrastructure in JDK 8 building the entire OpenJDK is fairly
> fast and even though I personally mostly work in the HotSpot tree, I tend to
> always clone and build the entire JDK forest. I find this to have several benefits.
>
> Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/
>
> The configuration in this project is currently Mac only. Linux and Solaris
> configurations are also planned.
>
> The webrev is made from the jdk8/build repository which is where I think a
> change like this should go in. Let me know if you think something else.
>
>
>
> To use this project (once pushed):
>
> 1. Clone your favorite repository
>     hg clone http://hg.openjdk.java.net/hsx/hotspot-gc
>
> 2. Get the whole forest
>     cd hotspot-gc
>     sh get_source.sh
>
> 3. Configure
>     sh configure
>
> 4. Open Solaris studio / NetBeans and load the project.
>     The project in located in the common directory.
>
>
> Thanks,
> /Jesper


From dan.xu at oracle.com  Wed Mar 27 16:02:17 2013
From: dan.xu at oracle.com (dan.xu at oracle.com)
Date: Wed, 27 Mar 2013 16:02:17 +0000
Subject: hg: jdk8/tl/jdk: 8010837: FileInputStream.available() throw
	IOException when encountering negative available values
Message-ID: <20130327160234.87FFE4841B@hg.openjdk.java.net>

Changeset: 49602f599c08
Author:    dxu
Date:      2013-03-27 09:00 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/49602f599c08

8010837: FileInputStream.available() throw IOException when encountering negative available values
Summary: Remove the check in the native code to allow negative values
Reviewed-by: mchung

! src/solaris/native/java/io/io_util_md.c
+ test/java/io/FileInputStream/NegativeAvailable.java



From martinrb at google.com  Wed Mar 27 16:17:45 2013
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 27 Mar 2013 09:17:45 -0700
Subject: RFR JDK-7143928 : (coll) Optimize for Empty ArrayList and HashMap
In-Reply-To: <30E35219-D90D-4D71-94FD-45A90F04EE59@oracle.com>
References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com>
	
	<30E35219-D90D-4D71-94FD-45A90F04EE59@oracle.com>
Message-ID: 

But you can support any requested initial size if stored in the size field
when list is empty.


On Wed, Mar 27, 2013 at 8:02 AM, Mike Duigou  wrote:

> This seems like a good idea. I will follow up with the performance people
> to see if their findings include the requested initial size.
>
> Mike
>
> On Mar 26 2013, at 22:53 , Brian Goetz wrote:
>
> > What percentage of the empty lists are default-sized?  I suspect it is
> large, in which case we could apply this trick only for the default-sized
> lists, and eliminate the extra field.
> >
> > On Mar 26, 2013, at 5:25 PM, Mike Duigou wrote:
> >
> >> Hello all;
> >>
> >> This is a review for optimization work that came out of internal
> analysis of Oracle's Java applications. It's based upon analysis that shows
> that in large applications as much as 10% of maps and lists are initialized
> but never receive any entries. A smaller number spend a large proportion of
> their lifetime empty. We've found similar results across other workloads as
> well. This patch is not a substitute for pre-sizing your collections and
> maps--doing so will *always* have better results.
> >>
> >> This patch extends HashMap and ArrayList to provide special handling
> for newly created instances that avoids creating the backing array until
> needed. There is a very small additional cost for detecting when to inflate
> the map or list that is measurable in interpreted tests but disappears in
> JITed code.
> >>
> >> http://cr.openjdk.java.net/~mduigou/JDK-7143928/0/webrev/
> >>
> >> We expect that should this code prove successful in Java 8 it will be
> backported to Java 7 updates.
> >>
> >> The unit test may appear to be somewhat unrelated. It was created after
> resolving a bug in an early version of this patch to detect the issue
> encountered (LinkedHashMap.init() was not being called in readObject() when
> the map was empty).
> >>
> >> Mike
> >
>
>


From olivier.lagneau at oracle.com  Wed Mar 27 16:09:44 2013
From: olivier.lagneau at oracle.com (Olivier Lagneau)
Date: Wed, 27 Mar 2013 17:09:44 +0100
Subject: DigitList bug in recent patch
In-Reply-To: <5152A447.207@linux.vnet.ibm.com>
References: <5152A447.207@linux.vnet.ibm.com>
Message-ID: <515319C8.4050501@oracle.com>

Hi Frank,

We discovered some time ago a long-standing bug in the DigitList.java 
class (see bug 7131459 ).
we have fixed it and this is now in the latest JDK8 builds

The fact is that decimal value 78.00005 cannot be represented exactly in 
a binary representation.
The closest binary representation to 78.00005 is 
78.0000500000000016598278307355940341949462890625
As you can read this "above" the tie value "78.00005".

So the closest binary representation of 78.00005 that can be recorded in 
a computer
is a bit greater than the "tie" value provided in the program text 
("78.00005"),
and for this reason, as stated below in new DiigitList code :
"    // value was above tie and FloatingDecimal truncated
     // digits to tie. We must round up.
"
We must round up the result to provide an exact and fair HALF-EVEN 
rounding of *what is recorded* in the computer,
since this value is "above" the tie.

Thus the correct result to return here is 78.0001 because 
maximumFractionDigits is set to 4,
and exact rounding changes the '0' digit in 4th fractional position to a 
'1'.

If you choose for example v=78.10005, which closest binary 
representation is 78.1000499999999959754859446547925472259521484375,
the returned result would be 78.1 since the binary representation is 
"below" the tie.

The previous behavior of JDK (DigitList) was wrong because it did *no* 
took correctly into account
what value is recorded in memory, and the new behavior is the correct one.

Hope that helps,
Olivier.

Frank Ding said  on date 3/27/2013 8:48 AM:
> Hi guys,
>   We noticed there is a recent change (patch @ 
> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/bc1f16f5566f ) that 
> changed the behavior of the following program.
>
> import java.math.RoundingMode;
> public class TestNumberFormat {
>
>     public static void main(String[] args) {
>
>         java.text.NumberFormat numberFormat = 
> java.text.NumberFormat.getInstance(
>                 java.util.Locale.US);
>         double v = 78.00005;
>         numberFormat.setMaximumFractionDigits(4);
>         numberFormat.setRoundingMode(RoundingMode.HALF_EVEN);
>         numberFormat.setMinimumFractionDigits(0);
>         numberFormat.setGroupingUsed(false);
>         String ret = numberFormat.format(v);
>         System.out.println(ret);
>     }
> }
>
> Note the rounding mode HALF_EVEN and the expected output should be 
> "78" which can also be verified by running previous jdk (before b73).
>
> Stepping into code and the suspicious code is in 
> DigitList.shouldRoundUp().  allDecimalDigits is false so true is 
> returned, causing the last digit in fraction part to be 1.
>             case HALF_EVEN:
>                 // Implement IEEE half-even rounding
>                 if (digits[maximumDigits] > '5') {
>                     return true;
>                 } else if (digits[maximumDigits] == '5' ) {
>                     if (maximumDigits == (count - 1)) {
>                         // the rounding position is exactly the last 
> index :
>                         if (alreadyRounded)
>                             // If FloatingDecimal rounded up (value 
> was below tie),
>                             // then we should not round up again.
>                             return false;
>
>                         if (!allDecimalDigits)
>                             // Otherwise if the digits dont represent 
> exact value,
>                             // value was above tie and FloatingDecimal 
> truncated
>                             // digits to tie. We must round up.
>                             return true;
>
> Since I am not familiar of the numeric conversion, can any one shed 
> your light on it?
>
> Best regards,
> Frank
>



From mike.duigou at oracle.com  Wed Mar 27 16:27:57 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 27 Mar 2013 09:27:57 -0700
Subject: RFR JDK-8010267 & JDK-8010268 : Makefile maintenance for test
	targets
In-Reply-To: 
References: 
Message-ID: <081944A1-4DBD-4E24-8C7C-355AFD37196B@oracle.com>

I still need a review for both of these changes.

Mike

On Mar 18 2013, at 22:48 , Mike Duigou wrote:

> A two small changes to review:
> 
> If approved I will commit to TL (or someone else can commit to build for me)
> 
> Mike
> 
> JDK-8010267 : Add test-clean for cleaning of testoutput directory from output directory. 
> 
> diff --git a/common/makefiles/Main.gmk b/common/makefiles/Main.gmk
> --- a/common/makefiles/Main.gmk
> +++ b/common/makefiles/Main.gmk
> @@ -191,7 +191,7 @@ source-tips: $(OUTPUT_ROOT)/source_tips
> 
> 
> # Remove everything, except the output from configure.
> -clean: clean-langtools clean-corba clean-jaxp clean-jaxws clean-hotspot clean-jdk clean-images clean-overlay-images clean-bootcycle-build clean-docs
> +clean: clean-langtools clean-corba clean-jaxp clean-jaxws clean-hotspot clean-jdk clean-images clean-overlay-images clean-bootcycle-build clean-docs clean-test
>        @($(CD) $(OUTPUT_ROOT) && $(RM) -r tmp source_tips build.log* build-trace*.log*)
>        @$(ECHO) Cleaned all build artifacts.
> 
> @@ -230,6 +230,8 @@ clean-bootcycle-build:
> clean-docs:
>        $(call CleanComponent,docs)
>        $(call CleanComponent,docstemp)
> +clean-test:
> +       $(call CleanComponent,testoutput)
> 
> .PHONY: langtools corba jaxp jaxws hotspot jdk images overlay-images install
> .PHONY: langtools-only corba-only jaxp-only jaxws-only hotspot-only jdk-only images-only overlay-images-only install-only
> 
> 
> JDK-8010268 : Remove dependence upon clean target from jdk/test/Makefile prep target
> 
> None of the current users seem to depend upon the clean behaviour of "prep"
> 
> diff --git a/test/Makefile b/test/Makefile
> --- a/test/Makefile
> +++ b/test/Makefile
> @@ -336,7 +336,7 @@ all: jdk_default
>        @$(ECHO) "Testing completed successfully"
> 
> # Prep for output
> -prep: clean
> +prep:
>        @$(MKDIR) -p $(ABS_TEST_OUTPUT_DIR)
>        @$(MKDIR) -p `$(DIRNAME) $(ARCHIVE_BUNDLE)`
> 
> 



From mike.duigou at oracle.com  Wed Mar 27 16:28:50 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 27 Mar 2013 09:28:50 -0700
Subject: RFR JDK-7143928 : (coll) Optimize for Empty ArrayList and HashMap
In-Reply-To: 
References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com>
	
	<30E35219-D90D-4D71-94FD-45A90F04EE59@oracle.com>
	
Message-ID: 

I started looking at crafty reuse of size but found too many direct references to size to attempt getting this right in the current iteration. Reusing size is definitely still available to someone who wants to dive in and prepare an implementation.

Mike

On Mar 27 2013, at 09:17 , Martin Buchholz wrote:

> But you can support any requested initial size if stored in the size field when list is empty.
> 
> 
> On Wed, Mar 27, 2013 at 8:02 AM, Mike Duigou  wrote:
> This seems like a good idea. I will follow up with the performance people to see if their findings include the requested initial size.
> 
> Mike
> 
> On Mar 26 2013, at 22:53 , Brian Goetz wrote:
> 
> > What percentage of the empty lists are default-sized?  I suspect it is large, in which case we could apply this trick only for the default-sized lists, and eliminate the extra field.
> >
> > On Mar 26, 2013, at 5:25 PM, Mike Duigou wrote:
> >
> >> Hello all;
> >>
> >> This is a review for optimization work that came out of internal analysis of Oracle's Java applications. It's based upon analysis that shows that in large applications as much as 10% of maps and lists are initialized but never receive any entries. A smaller number spend a large proportion of their lifetime empty. We've found similar results across other workloads as well. This patch is not a substitute for pre-sizing your collections and maps--doing so will *always* have better results.
> >>
> >> This patch extends HashMap and ArrayList to provide special handling for newly created instances that avoids creating the backing array until needed. There is a very small additional cost for detecting when to inflate the map or list that is measurable in interpreted tests but disappears in JITed code.
> >>
> >> http://cr.openjdk.java.net/~mduigou/JDK-7143928/0/webrev/
> >>
> >> We expect that should this code prove successful in Java 8 it will be backported to Java 7 updates.
> >>
> >> The unit test may appear to be somewhat unrelated. It was created after resolving a bug in an early version of this patch to detect the issue encountered (LinkedHashMap.init() was not being called in readObject() when the map was empty).
> >>
> >> Mike
> >
> 
> 



From john.zavgren at oracle.com  Wed Mar 27 16:30:13 2013
From: john.zavgren at oracle.com (John Zavgren)
Date: Wed, 27 Mar 2013 09:30:13 -0700 (PDT)
Subject: RFR JDK-8003245
Message-ID: <24356968-438c-495a-859a-bab0af138c23@default>

Florian:

Yes, the uninitialized memory will be accessed in some cases, for example:
@@ -1733,10 +1747,12 @@
     CK_X9_42_DH1_DERIVE_PARAMS ckParam;
     jfieldID fieldID;
     jlong jKdf;
     jobject jOtherInfo, jPublicData;
 
+    memset(&ckParam, 0, sizeof(CK_X9_42_DH1_DERIVE_PARAMS));<--- added initialization
+
     /* get kdf */
     jX942Dh1DeriveParamsClass = (*env)->FindClass(env, CLASS_X9_42_DH1_DERIVE_PARAMS);
     if (jX942Dh1DeriveParamsClass == NULL) { return ckParam; }
     fieldID = (*env)->GetFieldID(env, jX942Dh1DeriveParamsClass, "kdf", "J");
     if (fieldID == NULL) { return ckParam; }

----- Original Message -----
From: fweimer at redhat.com
To: john.zavgren at oracle.com
Cc: core-libs-dev at openjdk.java.net
Sent: Wednesday, March 27, 2013 11:48:57 AM GMT -05:00 US/Canada Eastern
Subject: Re: RFR JDK-8003245

On 03/20/2013 04:27 PM, John Zavgren wrote:
> Please consider the following changes that eliminate the use of uninitialized memory.

> http://cr.openjdk.java.net/~jzavgren/8003245/webrev.01/

Is the uninitialized memory accessed on the error paths?

-- 
Florian Weimer / Red Hat Product Security Team


From olivier.lagneau at oracle.com  Wed Mar 27 16:32:23 2013
From: olivier.lagneau at oracle.com (Olivier Lagneau)
Date: Wed, 27 Mar 2013 17:32:23 +0100
Subject: DigitList bug in recent patch
In-Reply-To: <515319C8.4050501@oracle.com>
References: <5152A447.207@linux.vnet.ibm.com> <515319C8.4050501@oracle.com>
Message-ID: <51531F17.7030108@oracle.com>

Hi Franck,

Below is a variation of your program that shows the closest bynary 
representation of the v value you provide:

--------------------------
import java.math.RoundingMode;
import java.math.BigDecimal;

public class FrankDing {

     public static void main(String[] args) {

         java.text.NumberFormat numberFormat = 
java.text.NumberFormat.getInstance(
                 java.util.Locale.US);
         double v = 78.00005;

         // Prints-out first the "approximated" double floating-point value
         System.out.println("FloatingDecimal output : " + v);
         // Then the exact binary representation using as much memory as 
needed
         System.out.println("BigDecimal      output : " + new 
BigDecimal(v).toString());

         numberFormat.setMaximumFractionDigits(4);
         numberFormat.setRoundingMode(RoundingMode.HALF_EVEN);
         numberFormat.setMinimumFractionDigits(0);
         numberFormat.setGroupingUsed(false);
         String ret = numberFormat.format(v);
         System.out.println(ret);
     }
}
--------------------------

Best Regards,
Olivier.

Olivier Lagneau said  on date 3/27/2013 5:09 PM:
> Hi Frank,
>
> We discovered some time ago a long-standing bug in the DigitList.java 
> class (see bug 7131459 ).
> we have fixed it and this is now in the latest JDK8 builds
>
> The fact is that decimal value 78.00005 cannot be represented exactly 
> in a binary representation.
> The closest binary representation to 78.00005 is 
> 78.0000500000000016598278307355940341949462890625
> As you can read this "above" the tie value "78.00005".
>
> So the closest binary representation of 78.00005 that can be recorded 
> in a computer
> is a bit greater than the "tie" value provided in the program text 
> ("78.00005"),
> and for this reason, as stated below in new DiigitList code :
> "    // value was above tie and FloatingDecimal truncated
>     // digits to tie. We must round up.
> "
> We must round up the result to provide an exact and fair HALF-EVEN 
> rounding of *what is recorded* in the computer,
> since this value is "above" the tie.
>
> Thus the correct result to return here is 78.0001 because 
> maximumFractionDigits is set to 4,
> and exact rounding changes the '0' digit in 4th fractional position to 
> a '1'.
>
> If you choose for example v=78.10005, which closest binary 
> representation is 78.1000499999999959754859446547925472259521484375,
> the returned result would be 78.1 since the binary representation is 
> "below" the tie.
>
> The previous behavior of JDK (DigitList) was wrong because it did *no* 
> took correctly into account
> what value is recorded in memory, and the new behavior is the correct one.
>
> Hope that helps,
> Olivier.
>
> Frank Ding said  on date 3/27/2013 8:48 AM:
>> Hi guys,
>>   We noticed there is a recent change (patch @ 
>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/bc1f16f5566f ) that 
>> changed the behavior of the following program.
>>
>> import java.math.RoundingMode;
>> public class TestNumberFormat {
>>
>>     public static void main(String[] args) {
>>
>>         java.text.NumberFormat numberFormat = 
>> java.text.NumberFormat.getInstance(
>>                 java.util.Locale.US);
>>         double v = 78.00005;
>>         numberFormat.setMaximumFractionDigits(4);
>>         numberFormat.setRoundingMode(RoundingMode.HALF_EVEN);
>>         numberFormat.setMinimumFractionDigits(0);
>>         numberFormat.setGroupingUsed(false);
>>         String ret = numberFormat.format(v);
>>         System.out.println(ret);
>>     }
>> }
>>
>> Note the rounding mode HALF_EVEN and the expected output should be 
>> "78" which can also be verified by running previous jdk (before b73).
>>
>> Stepping into code and the suspicious code is in 
>> DigitList.shouldRoundUp().  allDecimalDigits is false so true is 
>> returned, causing the last digit in fraction part to be 1.
>>             case HALF_EVEN:
>>                 // Implement IEEE half-even rounding
>>                 if (digits[maximumDigits] > '5') {
>>                     return true;
>>                 } else if (digits[maximumDigits] == '5' ) {
>>                     if (maximumDigits == (count - 1)) {
>>                         // the rounding position is exactly the last 
>> index :
>>                         if (alreadyRounded)
>>                             // If FloatingDecimal rounded up (value 
>> was below tie),
>>                             // then we should not round up again.
>>                             return false;
>>
>>                         if (!allDecimalDigits)
>>                             // Otherwise if the digits dont represent 
>> exact value,
>>                             // value was above tie and 
>> FloatingDecimal truncated
>>                             // digits to tie. We must round up.
>>                             return true;
>>
>> Since I am not familiar of the numeric conversion, can any one shed 
>> your light on it?
>>
>> Best regards,
>> Frank
>>
>



From joe.darcy at oracle.com  Wed Mar 27 16:39:32 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 27 Mar 2013 09:39:32 -0700
Subject: JDK 8 RFR for JDK-7185456 : (ann) Optimize Annotation handling
	in java/sun.reflect.* code for small number of annotationsC
In-Reply-To: <5152B0C3.8050702@oracle.com>
References: <5152247B.9080902@oracle.com> <5152B0C3.8050702@oracle.com>
Message-ID: <515320C4.9000609@oracle.com>

Hello Joel,

On 03/27/2013 01:41 AM, Joel Borggr?n-Franck wrote:
> Hi Joe,
>
> Looks good to me.
>
> I would include Andrej's suggestion of removing one of the 
> members.put(...).

Pushed with the suggestion; thanks for the reviews,

-Joe

>
> cheers
> /Joel
>
> On 03/26/2013 11:43 PM, Joe Darcy wrote:
>> Hello,
>>
>> Please review this refactoring of how annotations objects are created:
>>
>>      JDK-7185456 : (ann) Optimize Annotation handling in 
>> java/sun.reflect.*
>> code for small number of annotationsC
>>      http://cr.openjdk.java.net/~darcy/7185456.0/
>>
>> In brief, an annotation object is backed by a hash map with one entry 
>> per
>> method defined on the annotation type. Currently the default HashMap
>> constructor which uses a default capacity of 16 is used. Since most
>> annotation type define many fewer methods, some space is wasted. The 
>> patch
>> (inline below) "right sizes" the HashMap to match the number of 
>> methods in
>> the annotation type.
>>
>> Thanks,
>>
>> -Joe
>>
>> --- old/src/share/classes/sun/reflect/annotation/AnnotationType.java
>> 2013-03-26 15:37:22.000000000 -0700
>> +++ new/src/share/classes/sun/reflect/annotation/AnnotationType.java
>> 2013-03-26 15:37:22.000000000 -0700
>> @@ -45,19 +45,18 @@
>>        * types.  This matches the return value that must be used for a
>>        * dynamic proxy, allowing for a simple isInstance test.
>>        */
>> -    private final Map> memberTypes = new
>> HashMap>();
>> +    private final Map> memberTypes;
>>
>>       /**
>>        * Member name -> default value mapping.
>>        */
>> -    private final Map memberDefaults =
>> -        new HashMap();
>> +    private final Map memberDefaults;
>>
>>       /**
>>        * Member name -> Method object mapping. This (and its assoicated
>>        * accessor) are used only to generate 
>> AnnotationTypeMismatchExceptions.
>>        */
>> -    private final Map members = new HashMap> Method>();
>> +    private final Map members;
>>
>>       /**
>>        * The retention policy for this annotation type.
>> @@ -105,6 +104,9 @@
>>                   }
>>               });
>>
>> +        memberTypes = new HashMap>(methods.length+1, 
>> 1.0f);
>> +        memberDefaults = new HashMap(0);
>> +        members = new HashMap(methods.length+1, 1.0f);
>>
>>           for (Method method :  methods) {
>>               if (method.getParameterTypes().length != 0)



From joe.darcy at oracle.com  Wed Mar 27 16:39:26 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Wed, 27 Mar 2013 16:39:26 +0000
Subject: hg: jdk8/tl/jdk: 7185456: (ann) Optimize Annotation handling in
	java/sun.reflect.* code for small number of annotations
Message-ID: <20130327163947.9634348424@hg.openjdk.java.net>

Changeset: ae03282ba501
Author:    darcy
Date:      2013-03-27 09:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ae03282ba501

7185456: (ann) Optimize Annotation handling in java/sun.reflect.* code for small number of annotations
Reviewed-by: mduigou, jfranck

! src/share/classes/sun/reflect/annotation/AnnotationType.java



From peter.levart at gmail.com  Wed Mar 27 16:44:51 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 27 Mar 2013 17:44:51 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due
	to HashMap leads to Integer allocations (boxing)
In-Reply-To: <51521537.8070905@oracle.com>
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com> <514B2E8D.8060701@gmail.com>
	<514B92A7.1000305@oracle.com>
	
	<514C2C94.60700@gmail.com>
	
	<514C4E09.3020008@gmail.com> <514C5C8D.1090406@gmail.com>
	<514C859D.1050705@gmail.com> <51503925.1020403@gmail.com>
	<51507BE0.6000502@gmail.com> <51521537.8070905@oracle.com>
Message-ID: <51532203.1090902@gmail.com>

Hi Mandy, Laurent,

It turns out that the API change (change of type for level parameter int 
-> enum Level) is entirely source-compatible. The tip of JDK8 (tl repo) 
builds without a problem. So no-one is currently using 
PlatformLogger.getLevel() method and assigning it to a variable or such...

Here's the webrev for this change:

http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.enumapi.01/index.html

Besides doing the replacement of type and renaming and removing of the 
unneeded stuff, I also did some re-arrangements:

- introduced a common abstract superclass for both types of LoggerProxys 
(DefaultLoggerProxy, JavaLoggerProxy), since JavaLoggerProxy does not 
need the fields of DefaultLoggerProxy and now both concrete subclasses 
can be declared final (makes JIT even more happy). Also the abstract 
LoggerProxy could host some common logic (see below about formatting)...
- DefaultLoggerProxy's levelValue/effectiveLevel were given names just 
the opposite of their meaning. I aligned them with terminology used in 
j.u.l.Logger and renamed levelValue to plain level.
- introduced private method 
DefaultLoggerProxy.deriveEffectiveLevel(level) that currently just 
returns defaultLevel (INFO) when given null. I think with a little more 
effort, it could be possible to emulate the behaviour of j.u.l.Logger 
which inherits from 1st parent logger that has non-null level assigned. 
Of course with all the caching and invalidation...
- instead of static final DefaultLoggerProxy.defaultStream I created a 
private static method outputStream() that returns System.err. To 
accomodate for the situation when System.err is changed dynamically.
- fixed the JavaLoggerProxy.isEnabled() method. Original code was:

  532         boolean isEnabled() {
  533             Object level = LoggingSupport.getLevel(javaLogger);
  534             return level == null || level.equals(levelObjects.get(OFF)) == false;
  535         }


If 'level' is null then it can be that 1st parent that has a non-nul 
level is "OFF". I think that in such situation all the children that 
don't override the level should be disabled too. The following does 
exactly that:

  597         boolean isEnabled() {
  598             return LoggingSupport.isLoggable(javaLogger, Level.OFF.javaLevel);
  599         }


That's all for 1st rev. Besides the effective level inheritance, the 
following method in JavaLoggerProxy also caught my eye:

         void doLog(Level level, String msg, Object... params) {
             if (!isLoggable(level)) {
                 return;
             }
             // only pass String objects to the j.u.l.Logger which may
             // be created by untrusted code
             int len = (params != null) ? params.length : 0;
             Object[] sparams = new String[len];
             for (int i = 0; i < len; i++) {
                 sparams [i] = String.valueOf(params[i]);
             }
             LoggingSupport.log(javaLogger, level.javaLevel, msg, sparams);
         }

I think this could be improved if the DefaultLoggerProxy.formatMessage() 
is used instead of turning each parameter into a String. The method 
could be moved up to abstract LoggerProxy and used in both 
implementations so that common formatting is applied regardless of 
back-end used.

The benchmarks still show stable performance:

##############################################################
# Java: 1.8.0-internal-peter_2013_03_04_10_48-b00
#   VM: OpenJDK 64-Bit Server VM 25.0-b19 (mixed mode)
#   OS: Linux 3.7.9-104.fc17.x86_64 (amd64)
# CPUs: 8 (virtual) - Intel i7-2600K
#
#-------------------------------------------------------------
# isLoggableFinest: run duration:  3,000 ms
#
# Warm up:
#           1 threads, Tavg =      1.71 ns/op (? =   0.00 ns/op) [     1.71]
#           1 threads, Tavg =      1.45 ns/op (? =   0.00 ns/op) [     1.45]
# Measure:
             1 threads, Tavg =      1.69 ns/op (? =   0.00 ns/op) [     
1.69]
             2 threads, Tavg =      1.69 ns/op (? =   0.00 ns/op) [     
1.69,      1.69]
             3 threads, Tavg =      1.67 ns/op (? =   0.04 ns/op) [     
1.70,      1.70,      1.62]
             4 threads, Tavg =      1.66 ns/op (? =   0.11 ns/op) [     
1.49,      1.70,      1.79,      1.69]
#
#-------------------------------------------------------------
# java.util.logging enabled
#
#
#-------------------------------------------------------------
# isLoggableFinest: run duration:  3,000 ms
#
# Measure:
             1 threads, Tavg =      1.75 ns/op (? =   0.00 ns/op) [     
1.75]
             2 threads, Tavg =      1.78 ns/op (? =   0.01 ns/op) [     
1.79,      1.77]
             3 threads, Tavg =      1.68 ns/op (? =   0.02 ns/op) [     
1.68,      1.66,      1.69]
             4 threads, Tavg =      1.66 ns/op (? =   0.00 ns/op) [     
1.65,      1.65,      1.66,      1.66]
             1 threads, Tavg =      1.68 ns/op (? =   0.00 ns/op) [     
1.68]
             2 threads, Tavg =      1.68 ns/op (? =   0.02 ns/op) [     
1.70,      1.66]
             3 threads, Tavg =      1.67 ns/op (? =   0.02 ns/op) [     
1.69,      1.65,      1.66]
             4 threads, Tavg =      1.68 ns/op (? =   0.03 ns/op) [     
1.65,      1.65,      1.66,      1.73]
             1 threads, Tavg =      1.65 ns/op (? =   0.00 ns/op) [     
1.65]
             2 threads, Tavg =      1.68 ns/op (? =   0.03 ns/op) [     
1.71,      1.65]
             3 threads, Tavg =      1.66 ns/op (? =   0.00 ns/op) [     
1.66,      1.65,      1.66]
             4 threads, Tavg =      1.74 ns/op (? =   0.12 ns/op) [     
1.95,      1.70,      1.69,      1.65]
#
#-------------------------------------------------------------
# END.
##############################################################

##############################################################
# Java: 1.8.0-ea-b82
#   VM: Java HotSpot(TM) 64-Bit Server VM 25.0-b23 (mixed mode)
#   OS: SunOS 5.10 (sparcv9)
# CPUs: 64 (virtual) - UltraSPARC-T2
#
#-------------------------------------------------------------
# isLoggableFinest: run duration:  3,000 ms
#
# Warm up:
#           1 threads, Tavg =     40.63 ns/op (? =   0.00 ns/op) [    40.63]
#           1 threads, Tavg =     38.69 ns/op (? =   0.00 ns/op) [    38.69]
# Measure:
             1 threads, Tavg =     38.64 ns/op (? =   0.00 ns/op) [    
38.64]
             2 threads, Tavg =     38.70 ns/op (? =   0.04 ns/op) [    
38.74,     38.66]
             3 threads, Tavg =     38.89 ns/op (? =   0.06 ns/op) [    
38.97,     38.85,     38.84]
             4 threads, Tavg =     38.94 ns/op (? =   0.18 ns/op) [    
39.18,     38.76,     38.78,     39.04]
#
#-------------------------------------------------------------
# java.util.logging enabled
#
#
#-------------------------------------------------------------
# isLoggableFinest: run duration:  3,000 ms
#
# Measure:
             1 threads, Tavg =    101.37 ns/op (? =   0.00 ns/op) [   
101.37]
             2 threads, Tavg =     99.67 ns/op (? =   0.01 ns/op) [    
99.67,     99.68]
             3 threads, Tavg =     48.27 ns/op (? =   0.06 ns/op) [    
48.31,     48.31,     48.19]
             4 threads, Tavg =     48.28 ns/op (? =   0.14 ns/op) [    
48.11,     48.24,     48.28,     48.50]
             1 threads, Tavg =     48.14 ns/op (? =   0.00 ns/op) [    
48.14]
             2 threads, Tavg =     48.21 ns/op (? =   0.01 ns/op) [    
48.21,     48.22]
             3 threads, Tavg =     48.26 ns/op (? =   0.18 ns/op) [    
48.52,     48.11,     48.16]
             4 threads, Tavg =     48.30 ns/op (? =   0.10 ns/op) [    
48.33,     48.44,     48.15,     48.27]
             1 threads, Tavg =     48.21 ns/op (? =   0.00 ns/op) [    
48.21]
             2 threads, Tavg =     48.18 ns/op (? =   0.09 ns/op) [    
48.27,     48.09]
             3 threads, Tavg =     48.44 ns/op (? =   0.09 ns/op) [    
48.54,     48.44,     48.33]
             4 threads, Tavg =     49.29 ns/op (? =   0.16 ns/op) [    
49.36,     49.02,     49.33,     49.46]
#
#-------------------------------------------------------------
# END.
##############################################################


Regards, Peter


On 03/26/2013 10:37 PM, Mandy Chung wrote:
> Hi Peter,
>
>> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.08/index.html
> I'm glad that you observe similar performance improvement without the 
> need of method handles.  I reviewed this version and realize that the 
> map from j.u.l.Level object to LevelEnum can be removed entirely.
>
> sun.util.logging.PlatformLogger is an internal API that should only be 
> used by JDK.  The static final int fields representing the level value 
> can be changed to be static final LevelEnum type instead.  I checked 
> the JDK code that uses PlatformLogger and no code will be impacted by 
> the change of the type of these static fields.  So it removes the need 
> to map from an integer value to LevelEnum.  Mapping from a j.u.l.Level 
> to LevelEnum is trivial - the name of the LevelEnum is the same as 
> j.u.l.Level (e.g. LevelEnum.FINEST and Level.FINEST), you can call 
> LoggingSupport.getLevelName(javaLevel) to find its name and 
> LevelEnum.valueOf(levelName) returns the LevelEnum instance. However, 
> this would require more changes - basically the methods taking "int 
> level" as a parameter would be modified to take LevelEnum and 
> getLevel() would return LevelEnum too.  I think it's worth doing this 
> cleanup to get rid of the unnecessary conversion from int -> enum -> 
> j.u.l.Level and vice versa.  I also recommend to rename LevelEnum to 
> Level which is an inner class of PlatformLogger.  What do you think of 
> this alternative to get rid of the map?
>
> Some other comments of your patch:
> - it renames the class JavaLogger to JavaLoggerProxy and the variable 
> from logger to loggerProxy. I'm fine with that.
> - L162: JavaLoggerProxy.init() to force load of the class which leads 
> to separating the initialization of LevelEnum.javaLevel in a new 
> JavaLevel class.  The JavaLevel utility methods are not needed if we 
> change the static final fields to LevelEnum.
>
> Have you tried:
> Class.forName("sun.util.logging.PlatformLogger.JavaLoggerProxy", 
> false, PlatformLogger.getClassLoader());
>
> would this give you the same performance improvement?  If so, you can 
> keep the static initialization in the JavaLoggerProxy class.
>
> Thanks for expanding the PlatformLoggerTest to cover additional test 
> cases.  It's good that you compare the value of the PlatformLogger 
> static final fields with j.u.l.Level.intValue(). You now can use the 
> API to compare the LevelEnum with Level rather than reflection.  
> Perhaps you can add the getName() and intValue() methods in LevelEnum 
> class (just a thought).
>
> Mandy
>
>
> On 3/25/13 9:31 AM, Peter Levart wrote:
>> Well, Laurent, Mandy,
>>
>> It turns out that the dispatch speed-up (or lack of slow-down to be 
>> precise) is possible without MethodHandles too. Maybe some VM guru 
>> could shed some light on this, but the following is currently the 
>> fastest variant:
>>
>> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.08/index.html
>>
>> What I did is a simple "if" deciding between two call-sites, making 
>> sure that each is only dispatching to single class. This only works, 
>> if both classes (LoggerProxy and JavaLoggerProxy) are loaded in 
>> advance, before 1st invocation on any of them is made (might be that 
>> using MethodHandles forced initialization of both classes beforehand 
>> and hence the speed-up). If I don't load JavaLoggerProxy before 
>> warming-up with LoggerProxy, then when j.u.logging is enabled, speed 
>> drops for a factor of almost 4 and never catches up even after very 
>> long time.
>> This pre-loading also helps for a normal single call site dispatch 
>> that dispatches to two distinct classes, but the speed 1st drops when 
>> the class changes, and only catches-up after several billions of 
>> iterations (30s tight loop on i7).
>> Now, because JavaLoggerProxy is initialized early, I had to move the 
>> initialization of j.u.logging.Level objects and mappings to a 
>> separate class "JavaLevel".
>>
>> Here are the benchmark results for this last iteration...
>>
>



From christos at zoulas.com  Wed Mar 27 17:22:05 2013
From: christos at zoulas.com (Christos Zoulas)
Date: Wed, 27 Mar 2013 13:22:05 -0400
Subject: DefaultProxySelector socks override
In-Reply-To: <5153162C.1010401@oracle.com> from Chris Hegarty (Mar 27,  3:54pm)
Message-ID: <20130327172205.22C1B97129@rebar.astron.com>

On Mar 27,  3:54pm, chris.hegarty at oracle.com (Chris Hegarty) wrote:
-- Subject: Re: DefaultProxySelector socks override

Hi Chris,

| [cc'ing net-dev, we can then probably drop core-libs-dev and continue 
| the discussion over on net-dev]
| 
| Christos,
| 
| SOCKS is really old and not as widely deployed as other proxies. That 
| said, I don't have any specific problem with your proposal. SOCKS is 
| really in maintenance mode in the JDK, but I do see this as a reasonable 
| request/proposal.

I totally understand; this is a legacy application for us too...

| Since socksNonProxyHosts is only set on Mac I can only presume that it 
| is a remanent of the mac port. I would prefer to make the cosmetic 
| changes as part of this patch. I cannot see that we need to keep 
| socksNonProxyHosts, as it does nothing in the JDK anyway.
| 
| Can you do this?

Sure, I just requested a subscription to net-dev so I might not see the
first few messages. To clarify:

	1. I will add socks.proxyHost and socks.proxyPort for consistency
	   with the other protocols, leaving as is socksProxyHost and
	   socksProxyPort for compatibility.
	2. I will add socks.nonProxyHosts and not socksNonProxyHosts.

Is that what you had in mind?

christos


From chris.hegarty at oracle.com  Wed Mar 27 17:30:16 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 27 Mar 2013 17:30:16 +0000
Subject: DefaultProxySelector socks override
In-Reply-To: <20130327172205.22C1B97129@rebar.astron.com>
References: <20130327172205.22C1B97129@rebar.astron.com>
Message-ID: <51532CA8.1020909@oracle.com>

On 03/27/2013 05:22 PM, christos at zoulas.com wrote:
> ....
> Sure, I just requested a subscription to net-dev so I might not see the
> first few messages. To clarify:
>
> 	1. I will add socks.proxyHost and socks.proxyPort for consistency
> 	   with the other protocols, leaving as is socksProxyHost and
> 	   socksProxyPort for compatibility.
> 	2. I will add socks.nonProxyHosts and not socksNonProxyHosts.
>
> Is that what you had in mind?

Re-checking the code I take back my previous comment. We already have

    socksProxyHost, socksProxyPort, socksProxyVersion

so your original proposal of 'socksNonProxyHosts' is probably best, and 
consistent with existing properties.

-Chris.

>
> christos
>


From mandy.chung at oracle.com  Wed Mar 27 17:35:48 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 27 Mar 2013 10:35:48 -0700
Subject: Review request for 7198429: need checked categorization of
	caller-sensitive methods in the JDK
Message-ID: <51532DF4.9020701@oracle.com>

This is the JDK change for JEP 176: JEP 176: Mechanical Checking of 
Caller-Sensitive Methods [1].  Christian has posted the webrev for the 
hotspot VM change a couple weeks ago [2].

Webrev at:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7198429/webrev.00/

While it touches many files, the fix is simple and straight-forward for 
review.

This fix annotates all methods that call Reflection.getCallerClass() 
method with @sun.reflect.CallerSensitive annotation so that it enables 
the VM to reliably enforce that methods looking up its immediate caller 
class are marked as caller-sensitive. The JVM will set a new 
caller-sensitive bit when resolving a MemberName and 
java.lang.invoke.MethodHandleNatives.isCallerSensitive is upgraded to 
query it directly.
The hand-maintained method list in MethodHandleNatives is removed.

A couple things to mention:
1. I am working on a fix for 8007035 that proposes to deprecate 
SecurityManager.checkMemberAccess method as it requires the caller?s 
frame to be at a stack depth of four, which is fragile and difficult to 
enforce.

2. NashornScriptEngineFactory.getAppClassLoader()

The change is to workaround the issue until 8009783 is resolved.

The current implementation walks the stack to find the classloader of 
the user context that NashornScriptEngine is running on which is 
fragile.  Also other script engine implementations may require similiar 
capability.  8009783 has been filed to revisit the scripting API to pass 
the user "context" to the script engine rather than relying the 
implementation to find it magically.

Thanks
Mandy

[1] http://openjdk.java.net/jeps/176
[2] 
http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008915.html


From iris.clark at oracle.com  Wed Mar 27 17:39:32 2013
From: iris.clark at oracle.com (Iris Clark)
Date: Wed, 27 Mar 2013 10:39:32 -0700 (PDT)
Subject: JDK1.7u17 Windows 8 compatibility issue: platform LAF does not
	work
In-Reply-To: <8BADF1E4FAE44BA7917F981B10F30DED@HEIKOXP>
References: <8BADF1E4FAE44BA7917F981B10F30DED@HEIKOXP>
Message-ID: <8374d379-88fb-4cde-968e-ec146b264b50@default>

Hi, Heiko.

Thanks for your message.  Unfortunately our Swing experts are on another list.

I'm separately forwarding your mail to the swing-dev mailing list.

Best,
iris

-----Original Message-----
From: Heiko Wagner [mailto:heiko.wagner at apis.de] 
Sent: Wednesday, March 27, 2013 3:26 AM
To: core-libs-dev at openjdk.java.net
Subject: JDK1.7u17 Windows 8 compatibility issue: platform LAF does not work

I am just facing a compatibility issue with Java 7u17 and Windows 8. When I am in "desktop mode" and want to set the platform LAF everything works in case the default Windows theme is set (the one that looks similar to Win7).
When Windows 8 is set to a high contrast theme (black background + whil/yellow foreground), setting of the platform LAF no loger works. Here is the stack trace:

java.lang.NullPointerException
 at com.sun.java.swing.plaf.windows.XPStyle$Skin.getWidth(Unknown Source)  at com.sun.java.swing.plaf.windows.XPStyle$Skin.getWidth(Unknown Source)  at com.sun.java.swing.plaf.windows.WindowsPopupMenuUI.getGutterWidth(Unknown
Source)
 at
com.sun.java.swing.plaf.windows.WindowsLookAndFeel.initVistaComponentDefault
s(Unknown Source)
 at
com.sun.java.swing.plaf.windows.WindowsLookAndFeel.initComponentDefaults(Unk
nown Source)
 at javax.swing.plaf.basic.BasicLookAndFeel.getDefaults(Unknown Source)  at javax.swing.UIManager.setLookAndFeel(Unknown Source)  at javax.swing.UIManager.setLookAndFeel(Unknown Source)

Is this problem already known and scheduled for a later update version?

Regards,
Heiko





From christos at zoulas.com  Wed Mar 27 17:49:10 2013
From: christos at zoulas.com (Christos Zoulas)
Date: Wed, 27 Mar 2013 13:49:10 -0400
Subject: DefaultProxySelector socks override
In-Reply-To: <51532CA8.1020909@oracle.com> from Chris Hegarty (Mar 27,  5:30pm)
Message-ID: <20130327174910.85AA097129@rebar.astron.com>

On Mar 27,  5:30pm, chris.hegarty at oracle.com (Chris Hegarty) wrote:
-- Subject: Re: DefaultProxySelector socks override

| On 03/27/2013 05:22 PM, christos at zoulas.com wrote:
| > ....
| > Sure, I just requested a subscription to net-dev so I might not see the
| > first few messages. To clarify:
| >
| > 	1. I will add socks.proxyHost and socks.proxyPort for consistency
| > 	   with the other protocols, leaving as is socksProxyHost and
| > 	   socksProxyPort for compatibility.
| > 	2. I will add socks.nonProxyHosts and not socksNonProxyHosts.
| >
| > Is that what you had in mind?
| 
| Re-checking the code I take back my previous comment. We already have
| 
|     socksProxyHost, socksProxyPort, socksProxyVersion
| 
| so your original proposal of 'socksNonProxyHosts' is probably best, and 
| consistent with existing properties.

I concur. Nothing for me to do :-)

Best,

christos


From karen.kinnear at oracle.com  Wed Mar 27 17:58:32 2013
From: karen.kinnear at oracle.com (karen.kinnear at oracle.com)
Date: Wed, 27 Mar 2013 17:58:32 +0000
Subject: hg: jdk8/tl/jdk: 8010846: Update the corresponding test in
	test/vm/verifier/TestStaticIF.java
Message-ID: <20130327175853.38B7248427@hg.openjdk.java.net>

Changeset: d254a5f9b93f
Author:    acorn
Date:      2013-03-27 13:40 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d254a5f9b93f

8010846: Update the corresponding test in test/vm/verifier/TestStaticIF.java
Summary: Remove test flag -XX:-UseSplitVerifier, not supported classfile 52
Reviewed-by: acorn, hseigel

! test/vm/verifier/TestStaticIF.java



From dl at cs.oswego.edu  Wed Mar 27 19:46:55 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Wed, 27 Mar 2013 15:46:55 -0400
Subject: RFR 8005696: Add CompletableFuture - JEP 155
In-Reply-To: <514D8D32.1020104@cs.oswego.edu>
References: <5142070C.6000709@oracle.com>
	
	<51430D6B.4060601@cs.oswego.edu> <5143258A.9020906@oracle.com>
	<5147206B.4060001@cs.oswego.edu> <51489817.7070809@oracle.com>
	<514D8D32.1020104@cs.oswego.edu>
Message-ID: <51534CAF.9000006@cs.oswego.edu>

On 03/23/13 07:08, Doug Lea wrote:
>
> There was a signature mismatch between the public
>    public static CompletableFuture anyOf(CompletableFuture... cfs)
> and the internal method performing most of the work:
>    private static CompletableFuture anyTree(...)
> ("" and "" are subtly different.)

Thanks to Martin especially for knocking some sense into me
about this. The type signature *was* incompatible, but
changing to  rather the  made this updated
version less useful (it could only return indication, not
result). So it is now updated with a signature-correct
version of anyOf with its original semantics.

Additionally, while being slightly disruptive anyway:
This class was lacking a little convenience method found in
other Future-based frameworks that surely will be requested.
So now added:

     /**
      * Returns a new CompletableFuture that is already completed with
      * the given value.
      *
      * @param value the value
      * @return the completed CompletableFuture
      */
     public static  CompletableFuture completedFuture(U value)


From christian.thalinger at oracle.com  Wed Mar 27 20:13:50 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 27 Mar 2013 13:13:50 -0700
Subject: Review request for 7198429: need checked categorization of
	caller-sensitive methods in the JDK
In-Reply-To: <51532DF4.9020701@oracle.com>
References: <51532DF4.9020701@oracle.com>
Message-ID: <60D0308F-42ED-4C0B-9A9E-BADA73B26F10@oracle.com>


On Mar 27, 2013, at 10:35 AM, Mandy Chung  wrote:

> This is the JDK change for JEP 176: JEP 176: Mechanical Checking of Caller-Sensitive Methods [1].  Christian has posted the webrev for the hotspot VM change a couple weeks ago [2].
> 
> Webrev at:
> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7198429/webrev.00/

src/share/classes/java/lang/ClassLoader.java:

+    static void checkClassLoaderPermission(ClassLoader cl, Class caller) {

I think we should rename that method to:

+    static void checkGetClassLoaderPermission(ClassLoader cl, Class caller) {

src/share/classes/java/lang/invoke/MethodHandleImpl.java:

+        @sun.reflect.CallerSensitive
+            Class actual = sun.reflect.Reflection.getCallerClass();

Why are we not using imports here?

src/share/classes/java/util/logging/Logger.java:

             // 0: Reflection 1: Logger.demandLogger 2: Logger.getLogger 3: caller
             final int SKIP_FRAMES = 3;

Please remove these lines as well.

src/share/native/sun/reflect/Reflection.c:

Could you put back this comment:

+     // Let's do at least some basic handshaking:
+     const int depth = -1;

It makes it clearer why it's -1.

test/sun/reflect/GetCallerClass.sh:

Could you please don't use a shell script to copy the class file?  For example this test:

http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/file/tip/test/compiler/whitebox/DeoptimizeAllTest.java

does the same thing using a little Java program ClassFileInstaller:

http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/file/tip/test/testlibrary/ClassFileInstaller.java

-- Chris

> 
> While it touches many files, the fix is simple and straight-forward for review.
> 
> This fix annotates all methods that call Reflection.getCallerClass() method with @sun.reflect.CallerSensitive annotation so that it enables the VM to reliably enforce that methods looking up its immediate caller class are marked as caller-sensitive. The JVM will set a new caller-sensitive bit when resolving a MemberName and java.lang.invoke.MethodHandleNatives.isCallerSensitive is upgraded to query it directly.
> The hand-maintained method list in MethodHandleNatives is removed.
> 
> A couple things to mention:
> 1. I am working on a fix for 8007035 that proposes to deprecate SecurityManager.checkMemberAccess method as it requires the caller?s frame to be at a stack depth of four, which is fragile and difficult to enforce.
> 
> 2. NashornScriptEngineFactory.getAppClassLoader()
> 
> The change is to workaround the issue until 8009783 is resolved.
> 
> The current implementation walks the stack to find the classloader of the user context that NashornScriptEngine is running on which is fragile.  Also other script engine implementations may require similiar capability.  8009783 has been filed to revisit the scripting API to pass the user "context" to the script engine rather than relying the implementation to find it magically.
> 
> Thanks
> Mandy
> 
> [1] http://openjdk.java.net/jeps/176
> [2] http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008915.html



From xueming.shen at oracle.com  Wed Mar 27 22:20:49 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 27 Mar 2013 15:20:49 -0700
Subject: Codereview Request for 8007379: Base64.getMimeDecoder().decode()
	throws IAE for a non-base64 character after padding
Message-ID: <515370C1.3040104@oracle.com>

Hi,

Please help review the fix for the following two bugs:

(1) 8007379: Base64.getMimeDecoder().decode() throws IAE for a non-base64 character after padding
We fixed the similar issue in 8006530, it appears there is "yet another" corner case
to close here. As described in the bug report, the calculation for output buffer size
for such case is incorrect when decoding in mime mode. The proposed change
should fix the problem.

(2) 8008925: Base64.getMimeDecoder().decode() does not ignore padding chars
The change is to clarify the specification that "the padding character(s) is not
required for decoding. BUT, if the padding character(s) does appear, they must
be correctly encoded."

http://cr.openjdk.java.net/~sherman/8007379_8008925/webrev

Thanks,
-Sherman



From dingxmin at linux.vnet.ibm.com  Thu Mar 28 02:27:54 2013
From: dingxmin at linux.vnet.ibm.com (Frank Ding)
Date: Thu, 28 Mar 2013 10:27:54 +0800
Subject: DigitList bug in recent patch
In-Reply-To: <515319C8.4050501@oracle.com>
References: <5152A447.207@linux.vnet.ibm.com> <515319C8.4050501@oracle.com>
Message-ID: <5153AAAA.6080205@linux.vnet.ibm.com>

Hi Olivier
   Thanks for your detailed clarification which really helps.

Best regards,
Frank

On 3/28/2013 12:09 AM, Olivier Lagneau wrote:
> Hi Frank,
>
> We discovered some time ago a long-standing bug in the DigitList.java 
> class (see bug 7131459 ).
> we have fixed it and this is now in the latest JDK8 builds
>
> The fact is that decimal value 78.00005 cannot be represented exactly 
> in a binary representation.
> The closest binary representation to 78.00005 is 
> 78.0000500000000016598278307355940341949462890625
> As you can read this "above" the tie value "78.00005".
>
> So the closest binary representation of 78.00005 that can be recorded 
> in a computer
> is a bit greater than the "tie" value provided in the program text 
> ("78.00005"),
> and for this reason, as stated below in new DiigitList code :
> "    // value was above tie and FloatingDecimal truncated
>     // digits to tie. We must round up.
> "
> We must round up the result to provide an exact and fair HALF-EVEN 
> rounding of *what is recorded* in the computer,
> since this value is "above" the tie.
>
> Thus the correct result to return here is 78.0001 because 
> maximumFractionDigits is set to 4,
> and exact rounding changes the '0' digit in 4th fractional position to 
> a '1'.
>
> If you choose for example v=78.10005, which closest binary 
> representation is 78.1000499999999959754859446547925472259521484375,
> the returned result would be 78.1 since the binary representation is 
> "below" the tie.
>
> The previous behavior of JDK (DigitList) was wrong because it did *no* 
> took correctly into account
> what value is recorded in memory, and the new behavior is the correct one.
>
> Hope that helps,
> Olivier.
>
> Frank Ding said  on date 3/27/2013 8:48 AM:
>> Hi guys,
>>   We noticed there is a recent change (patch @ 
>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/bc1f16f5566f ) that 
>> changed the behavior of the following program.
>>
>> import java.math.RoundingMode;
>> public class TestNumberFormat {
>>
>>     public static void main(String[] args) {
>>
>>         java.text.NumberFormat numberFormat = 
>> java.text.NumberFormat.getInstance(
>>                 java.util.Locale.US);
>>         double v = 78.00005;
>>         numberFormat.setMaximumFractionDigits(4);
>>         numberFormat.setRoundingMode(RoundingMode.HALF_EVEN);
>>         numberFormat.setMinimumFractionDigits(0);
>>         numberFormat.setGroupingUsed(false);
>>         String ret = numberFormat.format(v);
>>         System.out.println(ret);
>>     }
>> }
>>
>> Note the rounding mode HALF_EVEN and the expected output should be 
>> "78" which can also be verified by running previous jdk (before b73).
>>
>> Stepping into code and the suspicious code is in 
>> DigitList.shouldRoundUp().  allDecimalDigits is false so true is 
>> returned, causing the last digit in fraction part to be 1.
>>             case HALF_EVEN:
>>                 // Implement IEEE half-even rounding
>>                 if (digits[maximumDigits] > '5') {
>>                     return true;
>>                 } else if (digits[maximumDigits] == '5' ) {
>>                     if (maximumDigits == (count - 1)) {
>>                         // the rounding position is exactly the last 
>> index :
>>                         if (alreadyRounded)
>>                             // If FloatingDecimal rounded up (value 
>> was below tie),
>>                             // then we should not round up again.
>>                             return false;
>>
>>                         if (!allDecimalDigits)
>>                             // Otherwise if the digits dont represent 
>> exact value,
>>                             // value was above tie and 
>> FloatingDecimal truncated
>>                             // digits to tie. We must round up.
>>                             return true;
>>
>> Since I am not familiar of the numeric conversion, can any one shed 
>> your light on it?
>>
>> Best regards,
>> Frank
>>
>



From mandy.chung at oracle.com  Thu Mar 28 03:01:16 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 27 Mar 2013 20:01:16 -0700
Subject: Review request for 7198429: need checked categorization of
	caller-sensitive methods in the JDK
In-Reply-To: <60D0308F-42ED-4C0B-9A9E-BADA73B26F10@oracle.com>
References: <51532DF4.9020701@oracle.com>
	<60D0308F-42ED-4C0B-9A9E-BADA73B26F10@oracle.com>
Message-ID: <5153B27C.4070806@oracle.com>

Thanks for the review.  I forgot to mention that Chris contributed the 
initial patch (thanks).

On 3/27/2013 1:13 PM, Christian Thalinger wrote:
> On Mar 27, 2013, at 10:35 AM, Mandy Chung  wrote:
>
>> This is the JDK change for JEP 176: JEP 176: Mechanical Checking of Caller-Sensitive Methods [1].  Christian has posted the webrev for the hotspot VM change a couple weeks ago [2].
>>
>> Webrev at:
>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7198429/webrev.00/
> src/share/classes/java/lang/ClassLoader.java:
>
> +    static void checkClassLoaderPermission(ClassLoader cl, Class caller) {
>
> I think we should rename that method to:
>
> +    static void checkGetClassLoaderPermission(ClassLoader cl, Class caller) {

I think checkClassLoaderPermission and needsClassLoaderPermissionCheck 
are just fine.  I'd like to keep it as it is not to make the method name 
too long.

> src/share/classes/java/lang/invoke/MethodHandleImpl.java:
>
> +        @sun.reflect.CallerSensitive
> +            Class actual = sun.reflect.Reflection.getCallerClass();
>
> Why are we not using imports here?

imports are for convenience and ease of development.  For only one 
reference, I don't see any difference to import or not.

> src/share/classes/java/util/logging/Logger.java:
>
>               // 0: Reflection 1: Logger.demandLogger 2: Logger.getLogger 3: caller
>               final int SKIP_FRAMES = 3;
>
> Please remove these lines as well.

Removed.  Thanks for catching the leftover comment.
> src/share/native/sun/reflect/Reflection.c:
>
> Could you put back this comment:
>
> +     // Let's do at least some basic handshaking:
> +     const int depth = -1;
>
> It makes it clearer why it's -1.

I added this comment:
   32     // with the presence of @CallerSensitive annotation,
   33     // JVM_GetCallerClass asserts depth == -1 as the basic handshaking

> test/sun/reflect/GetCallerClass.sh:
>
> Could you please don't use a shell script to copy the class file?

The shell test doesn't do a copy.  It compiles the source file in a 
separate directory that will be specified in -Xbootclasspath/a option in 
javac and java commands.

jtreg in the code-tool repo has added the bootclasspath support:
     http://hg.openjdk.java.net/code-tools/jtreg/rev/98387c9f36e3

You can specify in the @run tag:
     @run main/bootclasspath opt class

This will be a better way to run a test on the bootclasspath.

> For example this test:
>
> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/file/tip/test/compiler/whitebox/DeoptimizeAllTest.java
>
> does the same thing using a little Java program ClassFileInstaller:
>
> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/file/tip/test/testlibrary/ClassFileInstaller.java

This is a nice workaround to avoid shell tests.  It compiles the source 
file in $TESTCLASSES and copies the one in a different location (dest) 
that will be used in a @run main -Xbootclasspath/a:dest class.

I prefer to use the new jtreg bootclasspath support when it's released 
rather than adding yet another workaround to avoid shell tests.   We 
should replace many, if not all, existing shell tests that currently put 
classes in the bootclasspath with the jtreg bootclasspath support in one 
patch.  I keep the test as it is.

Mandy

> -- Chris
>
>> While it touches many files, the fix is simple and straight-forward for review.
>>
>> This fix annotates all methods that call Reflection.getCallerClass() method with @sun.reflect.CallerSensitive annotation so that it enables the VM to reliably enforce that methods looking up its immediate caller class are marked as caller-sensitive. The JVM will set a new caller-sensitive bit when resolving a MemberName and java.lang.invoke.MethodHandleNatives.isCallerSensitive is upgraded to query it directly.
>> The hand-maintained method list in MethodHandleNatives is removed.
>>
>> A couple things to mention:
>> 1. I am working on a fix for 8007035 that proposes to deprecate SecurityManager.checkMemberAccess method as it requires the caller?s frame to be at a stack depth of four, which is fragile and difficult to enforce.
>>
>> 2. NashornScriptEngineFactory.getAppClassLoader()
>>
>> The change is to workaround the issue until 8009783 is resolved.
>>
>> The current implementation walks the stack to find the classloader of the user context that NashornScriptEngine is running on which is fragile.  Also other script engine implementations may require similiar capability.  8009783 has been filed to revisit the scripting API to pass the user "context" to the script engine rather than relying the implementation to find it magically.
>>
>> Thanks
>> Mandy
>>
>> [1] http://openjdk.java.net/jeps/176
>> [2] http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008915.html



From mandy.chung at oracle.com  Thu Mar 28 03:02:27 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 27 Mar 2013 20:02:27 -0700
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due
	to HashMap leads to Integer allocations (boxing)
In-Reply-To: <51532203.1090902@gmail.com>
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com> <514B2E8D.8060701@gmail.com>
	<514B92A7.1000305@oracle.com>
	
	<514C2C94.60700@gmail.com>
	
	<514C4E09.3020008@gmail.com> <514C5C8D.1090406@gmail.com>
	<514C859D.1050705@gmail.com> <51503925.1020403@gmail.com>
	<51507BE0.6000502@gmail.com> <51521537.8070905@oracle.com>
	<51532203.1090902@gmail.com>
Message-ID: <5153B2C3.4040101@oracle.com>

Hi Peter,

It looks better.   I want to wrap up this patch and push the changeset 
tomorrow.   I have made slight modification and clean up some comments 
and the test.  See my comments inlined below.

Webrev at:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8010309/webrev.00/

Please let me know if you don't agree with these changes or you find any 
performance issue.

I have retained the part in webrev.08 that only defines loggerProxy and 
javaLoggerProxy.  I don't think the new defaultLoggerProxy variable is 
needed.  I prefer to use Class.forName to force load JavaLoggerProxy 
class to make very explicit that we don't want the class be 
initialized.  JavaLoggerProxy. calls LoggingProxy.parseLevel 
unconditionally that will throw an AssertionError if java.util.logging 
is not available. If JavaLoggerProxy class is initialized, j.u.logging 
should be present and I want to catch error if otherwise.  Also 
Class.forName will load its superclass LoggerProxy.

As for the PlatformLogger.Level enums, having the members to be defined 
in ascending order is fragile.  It'd be more reliable to specify the 
value in the constructor so that it can be used as the isLoggable 
comparsion in the same way as in the Level implementation.

I am running the jdk core regression tests on all platforms and should 
have the result by tomorrow.

On 3/27/2013 9:44 AM, Peter Levart wrote:
> Hi Mandy, Laurent,
>
> It turns out that the API change (change of type for level parameter 
> int -> enum Level) is entirely source-compatible. The tip of JDK8 (tl 
> repo) builds without a problem. So no-one is currently using 
> PlatformLogger.getLevel() method and assigning it to a variable or such...
>

Great thanks.  That is what I expect too.

> Here's the webrev for this change:
>
> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.enumapi.01/index.html
>
> Besides doing the replacement of type and renaming and removing of the 
> unneeded stuff, I also did some re-arrangements:
>
> - introduced a common abstract superclass for both types of 
> LoggerProxys (DefaultLoggerProxy, JavaLoggerProxy), since 
> JavaLoggerProxy does not need the fields of DefaultLoggerProxy and now 
> both concrete subclasses can be declared final (makes JIT even more 
> happy). Also the abstract LoggerProxy could host some common logic 
> (see below about formatting)...

That's a good idea.

> - DefaultLoggerProxy's levelValue/effectiveLevel were given names just 
> the opposite of their meaning. I aligned them with terminology used in 
> j.u.l.Logger and renamed levelValue to plain level.

Swapping these 2 variables makes sense.

> - introduced private method 
> DefaultLoggerProxy.deriveEffectiveLevel(level) that currently just 
> returns defaultLevel (INFO) when given null.

Ok.

> I think with a little more effort, it could be possible to emulate the 
> behaviour of j.u.l.Logger which inherits from 1st parent logger that 
> has non-null level assigned. Of course with all the caching and 
> invalidation...

The only way to change the level to a non-default one is via the logging 
configuration and enable logging.  That's why there is no need for 
DefaultLoggerProxy to inherit level from its parent logger.  Also there 
is no parent logger hierarchy maintained in DefaultLoggerProxy.

> - instead of static final DefaultLoggerProxy.defaultStream I created a 
> private static method outputStream() that returns System.err. To 
> accomodate for the situation when System.err is changed dynamically.

Ok.

> - fixed the JavaLoggerProxy.isEnabled() method. Original code was:
>
>   532         boolean isEnabled() {
>   533             Object level = LoggingSupport.getLevel(javaLogger);
>   534             return level == null || level.equals(levelObjects.get(OFF)) == false;
>   535         }
>
> If 'level' is null then it can be that 1st parent that has a non-nul 
> level is "OFF". I think that in such situation all the children that 
> don't override the level should be disabled too. The following does 
> exactly that:
>
>   597         boolean isEnabled() {
>   598             return LoggingSupport.isLoggable(javaLogger, Level.OFF.javaLevel);
>   599         }
>

That is right.  Good catch.

> That's all for 1st rev. Besides the effective level inheritance, the 
> following method in JavaLoggerProxy also caught my eye:
>
>         void doLog(Level level, String msg, Object... params) {
>             if (!isLoggable(level)) {
>                 return;
>             }
>             // only pass String objects to the j.u.l.Logger which may
>             // be created by untrusted code
>             int len = (params != null) ? params.length : 0;
>             Object[] sparams = new String[len];
>             for (int i = 0; i < len; i++) {
>                 sparams [i] = String.valueOf(params[i]);
>             }
>             LoggingSupport.log(javaLogger, level.javaLevel, msg, sparams);
>         }
>
> I think this could be improved if the 
> DefaultLoggerProxy.formatMessage() is used instead of turning each 
> parameter into a String. The method could be moved up to abstract 
> LoggerProxy and used in both implementations so that common formatting 
> is applied regardless of back-end used.
>

Let's do this in a separate clean up as it's better to keep 8010309 
focus on performance improvement (although we have mixed this bag with 
some renaming).

> The benchmarks still show stable performance:
>

Great.  Hope we will wrap up tomorrow.

thanks for the contribution.
Mandy

>
>
> Regards, Peter
>
>
> On 03/26/2013 10:37 PM, Mandy Chung wrote:
>> Hi Peter,
>>
>>> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.08/index.html
>> I'm glad that you observe similar performance improvement without the 
>> need of method handles.  I reviewed this version and realize that the 
>> map from j.u.l.Level object to LevelEnum can be removed entirely.
>>
>> sun.util.logging.PlatformLogger is an internal API that should only 
>> be used by JDK.  The static final int fields representing the level 
>> value can be changed to be static final LevelEnum type instead.  I 
>> checked the JDK code that uses PlatformLogger and no code will be 
>> impacted by the change of the type of these static fields.  So it 
>> removes the need to map from an integer value to LevelEnum.  Mapping 
>> from a j.u.l.Level to LevelEnum is trivial - the name of the 
>> LevelEnum is the same as j.u.l.Level (e.g. LevelEnum.FINEST and 
>> Level.FINEST), you can call LoggingSupport.getLevelName(javaLevel) to 
>> find its name and LevelEnum.valueOf(levelName) returns the LevelEnum 
>> instance.  However, this would require more changes - basically the 
>> methods taking "int level" as a parameter would be modified to take 
>> LevelEnum and getLevel() would return LevelEnum too.  I think it's 
>> worth doing this cleanup to get rid of the unnecessary conversion 
>> from int -> enum -> j.u.l.Level and vice versa.  I also recommend to 
>> rename LevelEnum to Level which is an inner class of PlatformLogger. 
>> What do you think of this alternative to get rid of the map?
>>
>> Some other comments of your patch:
>> - it renames the class JavaLogger to JavaLoggerProxy and the variable 
>> from logger to loggerProxy. I'm fine with that.
>> - L162: JavaLoggerProxy.init() to force load of the class which leads 
>> to separating the initialization of LevelEnum.javaLevel in a new 
>> JavaLevel class.  The JavaLevel utility methods are not needed if we 
>> change the static final fields to LevelEnum.
>>
>> Have you tried:
>> Class.forName("sun.util.logging.PlatformLogger.JavaLoggerProxy", 
>> false, PlatformLogger.getClassLoader());
>>
>> would this give you the same performance improvement?  If so, you can 
>> keep the static initialization in the JavaLoggerProxy class.
>>
>> Thanks for expanding the PlatformLoggerTest to cover additional test 
>> cases.  It's good that you compare the value of the PlatformLogger 
>> static final fields with j.u.l.Level.intValue().  You now can use the 
>> API to compare the LevelEnum with Level rather than reflection.  
>> Perhaps you can add the getName() and intValue() methods in LevelEnum 
>> class (just a thought).
>>
>> Mandy
>>
>>
>> On 3/25/13 9:31 AM, Peter Levart wrote:
>>> Well, Laurent, Mandy,
>>>
>>> It turns out that the dispatch speed-up (or lack of slow-down to be 
>>> precise) is possible without MethodHandles too. Maybe some VM guru 
>>> could shed some light on this, but the following is currently the 
>>> fastest variant:
>>>
>>> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.08/index.html
>>>
>>> What I did is a simple "if" deciding between two call-sites, making 
>>> sure that each is only dispatching to single class. This only works, 
>>> if both classes (LoggerProxy and JavaLoggerProxy) are loaded in 
>>> advance, before 1st invocation on any of them is made (might be that 
>>> using MethodHandles forced initialization of both classes beforehand 
>>> and hence the speed-up). If I don't load JavaLoggerProxy before 
>>> warming-up with LoggerProxy, then when j.u.logging is enabled, speed 
>>> drops for a factor of almost 4 and never catches up even after very 
>>> long time.
>>> This pre-loading also helps for a normal single call site dispatch 
>>> that dispatches to two distinct classes, but the speed 1st drops 
>>> when the class changes, and only catches-up after several billions 
>>> of iterations (30s tight loop on i7).
>>> Now, because JavaLoggerProxy is initialized early, I had to move the 
>>> initialization of j.u.logging.Level objects and mappings to a 
>>> separate class "JavaLevel".
>>>
>>> Here are the benchmark results for this last iteration...
>>>
>>
>



From mandy.chung at oracle.com  Thu Mar 28 03:34:13 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 27 Mar 2013 20:34:13 -0700
Subject: RFR (M): 7198429: need checked categorization of caller-sensitive
	methods in the JDK
In-Reply-To: <514B55CA.6040907@gmail.com>
References: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com>
	<5149825D.1040608@gmail.com> <514B4D3F.7040600@oracle.com>
	<514B55CA.6040907@gmail.com>
Message-ID: <5153BA35.6060808@oracle.com>

Hi Peter,

On 3/21/2013 11:47 AM, Peter Levart wrote:
> ...
>
> I have seen a utility that uses it to establish the context (package 
> and ClassLoader) of where to start searching for resources for GUI 
> components construction. And a utility that wraps 
> Class.forName(String) - specifying Class.forName(name, true, 
> Reflection.getCallerClass(2).getClassLoader()) instead to use the 
> caller's class loader to load the class...
>

This seems to me that this case is more of visibility issue rather than 
caller-sensitivity.

> Usually it is only necessary to get the immediate caller.
>
>>
>>> Is there a reason to not "unofficially" support also classes with 
>>> @CS annotated methods and which are not loaded by bootstrap or 
>>> extension class-loader ?
>>
>> We expect that most of the caller-sensitive cases are in the JDK and 
>> should be rare for non-system libraries to have caller-sensitive 
>> code.  It'd be good to understand the use cases and the requirements 
>> to determine the appropriate support for it.
>
> Ok, but why limit? Is it an optimization?

Just out of scope and there will be much more consideration to expand 
the scope to cover the user caller-sensitive methods (e.g. SE API and 
implementable by different JDK vendors).

The scope of JEP 176 is target for the system code where it has all 
permissions that we expect majority of the caller-sensitive cases are in.

>
> Is it for security? For example: one might think that creating an 
> anonymous class and holding a j.l.Class reference somewhere safe is 
> enough for safety, so the class itself could have public API. Now if 
> an untrusted callback object is passed to the code of such class and 
> it is invoked from within that code, the anonymous class can get 
> "revealed" to the untrusted code which can use it's public API to 
> invoke it. Are there any other implications of allowing non-system 
> code to get the caller?

It'd help if you can have a test case showing this to help the 
discussion.  However, restricting Reflection.getCallerClass be called by 
the system code is no difference than defining a module-private class.  
sun.reflect.* classes are private to the JDK implementation that are not 
supported.  If there were modules, applications would not have been able 
to call it since sun.reflect would not be exported.

I would recommend to file a RFE and describe the use cases that require 
an API to get the caller class or find caller's context so that we can 
address it properly.

With this fix, the only way to call Reflection.getCallerClass must be 
system code (in bootclasspath or extension library).   As a workaround, 
can you put it on the bootclasspath?

Mandy


From forax at univ-mlv.fr  Wed Mar 27 23:36:14 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 28 Mar 2013 00:36:14 +0100
Subject: RFR: Optimize StringBuilder.append(null)
In-Reply-To: 
References: 
Message-ID: <5153826E.6070007@univ-mlv.fr>

On 03/27/2013 03:01 AM, Martin Buchholz wrote:

Hi Martin,
the code looks good,
I've just noticed that you declare the char array value final in appendNull
but it's not something that is usually done in the java.lang codebase.

R?mi

> Oops: I forgot to include core-libs-dev
>
> Forwarded conversation
> Subject: RFR: Optimize StringBuilder.append(null)
> ------------------------
>
> From: *Martin Buchholz* 
> Date: Tue, Mar 26, 2013 at 1:54 PM
> To: Xueming Shen , Masayoshi Okutsu <
> masayoshi.okutsu at oracle.com>, Ulf Zibis , Mike Duigou <
> mike.duigou at oracle.com>
>
>
> Hi! It's me again, fiddlling with StringBuilder.
> One of our users noticed that a lot of CPU time was being spent in
> StringBuilder.append(null).
> We can apply the previously proven optimization that improves it by a
> factor of 2 on microbenchmarks.
>
> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/StringBuilder.appendNull/
>
> ----------
> From: *Mike Duigou* 
> Date: Tue, Mar 26, 2013 at 1:58 PM
> To: Martin Buchholz 
> Cc: Xueming Shen , Masayoshi Okutsu <
> masayoshi.okutsu at oracle.com>, Ulf Zibis 
>
>
> This looks fine to me. Do you need a bug number?
>
> Mike
>
> ----------
> From: *Martin Buchholz* 
> Date: Tue, Mar 26, 2013 at 2:02 PM
> To: Mike Duigou 
> Cc: Xueming Shen , Masayoshi Okutsu <
> masayoshi.okutsu at oracle.com>, Ulf Zibis 
>
>
>
>
>
> On Tue, Mar 26, 2013 at 1:58 PM, Mike Duigou  wrote:
>
>> This looks fine to me. Do you need a bug number?
>>
>>
> Yes, I do (thanks!)
>
> ----------
> From: *Mike Duigou* 
> Date: Tue, Mar 26, 2013 at 2:12 PM
> To: Martin Buchholz 
> Cc: Xueming Shen , Masayoshi Okutsu <
> masayoshi.okutsu at oracle.com>, Ulf Zibis , Jim Gish <
> jim.gish at oracle.com>
>
>
> I have created:
>
> JDK-8010849: (str) Optimize StringBuilder.append(null)
>
> (yes we know that requiring an Oracle engineer create the bug is a problem.
> SOON!)
>
> Mike
>
> ----------
> From: *Mike Duigou* 
> Date: Tue, Mar 26, 2013 at 6:57 PM
> To: Martin Buchholz 
>
>
> Hi Martin;
>
> I hadn't originally noticed but can you make sure to send a RFR through
> core-libs-dev for this issue?
>
> Mike



From martinrb at google.com  Thu Mar 28 06:29:13 2013
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 27 Mar 2013 23:29:13 -0700
Subject: RFR: Optimize StringBuilder.append(null)
In-Reply-To: <5153826E.6070007@univ-mlv.fr>
References: 
	<5153826E.6070007@univ-mlv.fr>
Message-ID: 

On Wed, Mar 27, 2013 at 4:36 PM, Remi Forax  wrote:

> On 03/27/2013 03:01 AM, Martin Buchholz wrote:
>
> Hi Martin,
> the code looks good,
> I've just noticed that you declare the char array value final in appendNull
> but it's not something that is usually done in the java.lang codebase.
>

It's certainly common in java.util.concurrent.  It's safer.  The
declaration saves 50 bytes of bytecode.


From forax at univ-mlv.fr  Thu Mar 28 06:32:22 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 28 Mar 2013 07:32:22 +0100
Subject: RFR: Optimize StringBuilder.append(null)
In-Reply-To: 
References: 
	<5153826E.6070007@univ-mlv.fr>
	
Message-ID: <5153E3F6.30700@univ-mlv.fr>

On 03/28/2013 07:29 AM, Martin Buchholz wrote:
>
>
>
> On Wed, Mar 27, 2013 at 4:36 PM, Remi Forax  > wrote:
>
>     On 03/27/2013 03:01 AM, Martin Buchholz wrote:
>
>     Hi Martin,
>     the code looks good,
>     I've just noticed that you declare the char array value final in
>     appendNull
>     but it's not something that is usually done in the java.lang codebase.
>
>
> It's certainly common in java.util.concurrent.  It's safer.

I was talking about the *local variable* in appendNull() ?
IMO, marking the local variable final makes the code less readable


>  The declaration saves 50 bytes of bytecode.

I don't understand ?

R?mi



From bourges.laurent at gmail.com  Thu Mar 28 06:42:27 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Thu, 28 Mar 2013 07:42:27 +0100
Subject: RFR: Optimize StringBuilder.append(null)
In-Reply-To: 
References: 
	<5153826E.6070007@univ-mlv.fr>
	
Message-ID: 

Maybe the local var count could be renamed _count or c to avoid name
conflict with the member count and make the code more readable / obvious.

PS: I like final vars.

Cheers
Laurent
Le 28 mars 2013 07:31, "Martin Buchholz"  a ?crit :
>
> On Wed, Mar 27, 2013 at 4:36 PM, Remi Forax  wrote:
>
> > On 03/27/2013 03:01 AM, Martin Buchholz wrote:
> >
> > Hi Martin,
> > the code looks good,
> > I've just noticed that you declare the char array value final in
appendNull
> > but it's not something that is usually done in the java.lang codebase.
> >
>
> It's certainly common in java.util.concurrent.  It's safer.  The
> declaration saves 50 bytes of bytecode.


From joe.darcy at oracle.com  Thu Mar 28 07:03:02 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 28 Mar 2013 00:03:02 -0700
Subject: JDK 8 code review request for JDK-8004979
	java.lang.reflect.Modifier.toString should include "default"
Message-ID: <5153EB26.7010605@oracle.com>

Hello,

Please review these changes to add support for the "default" modifier to 
the output of Method.to[Generic]String:

     8004979 java.lang.reflect.Modifier.toString should include "default"
     http://cr.openjdk.java.net/~darcy/8004979.0/

Patch also included below.

Thanks,

-Joe

diff -r d254a5f9b93f src/share/classes/java/lang/reflect/Constructor.java
--- a/src/share/classes/java/lang/reflect/Constructor.java    Wed Mar 27 
13:40:26 2013 -0400
+++ b/src/share/classes/java/lang/reflect/Constructor.java    Thu Mar 28 
00:02:06 2013 -0700
@@ -284,9 +284,13 @@
       * modifiers {@code public}, {@code protected} or
       * {@code private}.  Only one of these may appear, or none if the
       * constructor has default (package) access.
+     *
+     * @return a string describing this {@code Constructor}
+     * @jls 8.8.3. Constructor Modifiers
       */
      public String toString() {
          return sharedToString(Modifier.constructorModifiers(),
+                              false,
                                parameterTypes,
                                exceptionTypes);
      }
@@ -328,10 +332,11 @@
       * include type parameters
       *
       * @since 1.5
+     * @jls 8.8.3. Constructor Modifiers
       */
      @Override
      public String toGenericString() {
-        return sharedToGenericString(Modifier.constructorModifiers());
+        return sharedToGenericString(Modifier.constructorModifiers(), 
false);
      }

      @Override
diff -r d254a5f9b93f src/share/classes/java/lang/reflect/Executable.java
--- a/src/share/classes/java/lang/reflect/Executable.java    Wed Mar 27 
13:40:26 2013 -0400
+++ b/src/share/classes/java/lang/reflect/Executable.java    Thu Mar 28 
00:02:06 2013 -0700
@@ -89,20 +89,24 @@

      }

-    void printModifiersIfNonzero(StringBuilder sb, int mask) {
+    void printModifiersIfNonzero(StringBuilder sb, int mask, boolean 
isDefault) {
          int mod = getModifiers() & mask;
          if (mod != 0) {
              sb.append(Modifier.toString(mod)).append(' ');
          }
+        if (isDefault) {
+            sb.append("default ");
+        }
      }

      String sharedToString(int modifierMask,
+                          boolean isDefault,
                            Class[] parameterTypes,
                            Class[] exceptionTypes) {
          try {
              StringBuilder sb = new StringBuilder();

-            printModifiersIfNonzero(sb, modifierMask);
+            printModifiersIfNonzero(sb, modifierMask, isDefault);
              specificToStringHeader(sb);

              sb.append('(');
@@ -124,11 +128,11 @@
       */
      abstract void specificToStringHeader(StringBuilder sb);

-    String sharedToGenericString(int modifierMask) {
+    String sharedToGenericString(int modifierMask, boolean isDefault) {
          try {
              StringBuilder sb = new StringBuilder();

-            printModifiersIfNonzero(sb, modifierMask);
+            printModifiersIfNonzero(sb, modifierMask, isDefault);

              TypeVariable[] typeparms = getTypeParameters();
              if (typeparms.length > 0) {
diff -r d254a5f9b93f src/share/classes/java/lang/reflect/Field.java
--- a/src/share/classes/java/lang/reflect/Field.java    Wed Mar 27 
13:40:26 2013 -0400
+++ b/src/share/classes/java/lang/reflect/Field.java    Thu Mar 28 
00:02:06 2013 -0700
@@ -288,6 +288,9 @@
       * {@code protected} or {@code private} first, and then other
       * modifiers in the following order: {@code static}, {@code final},
       * {@code transient}, {@code volatile}.
+     *
+     * @return a string describing this {@code Field}
+     * @jls 8.3.1 Field Modifiers
       */
      public String toString() {
          int mod = getModifiers();
@@ -315,6 +318,7 @@
       * its generic type
       *
       * @since 1.5
+     * @jls 8.3.1 Field Modifiers
       */
      public String toGenericString() {
          int mod = getModifiers();
diff -r d254a5f9b93f src/share/classes/java/lang/reflect/Method.java
--- a/src/share/classes/java/lang/reflect/Method.java    Wed Mar 27 
13:40:26 2013 -0400
+++ b/src/share/classes/java/lang/reflect/Method.java    Thu Mar 28 
00:02:06 2013 -0700
@@ -343,10 +343,16 @@
       * {@code public}, {@code protected} or {@code private} first,
       * and then other modifiers in the following order:
       * {@code abstract}, {@code static}, {@code final},
-     * {@code synchronized}, {@code native}, {@code strictfp}.
+     * {@code synchronized}, {@code native}, {@code strictfp},
+     * {@code default}.
+     *
+     * @return a string describing this {@code Method}
+     *
+     * @jls 8.4.3 Method Modifiers
       */
      public String toString() {
          return sharedToString(Modifier.methodModifiers(),
+                              isDefault(),
                                parameterTypes,
                                exceptionTypes);
      }
@@ -389,16 +395,19 @@
       * {@code public}, {@code protected} or {@code private} first,
       * and then other modifiers in the following order:
       * {@code abstract}, {@code static}, {@code final},
-     * {@code synchronized}, {@code native}, {@code strictfp}.
+     * {@code synchronized}, {@code native}, {@code strictfp},
+     * {@code default}.
       *
       * @return a string describing this {@code Method},
       * include type parameters
       *
       * @since 1.5
+     *
+     * @jls 8.4.3 Method Modifiers
       */
      @Override
      public String toGenericString() {
-        return sharedToGenericString(Modifier.methodModifiers());
+        return sharedToGenericString(Modifier.methodModifiers(), 
isDefault());
      }

      @Override
diff -r d254a5f9b93f test/java/lang/reflect/Method/GenericStringTest.java
--- a/test/java/lang/reflect/Method/GenericStringTest.java    Wed Mar 27 
13:40:26 2013 -0400
+++ b/test/java/lang/reflect/Method/GenericStringTest.java    Thu Mar 28 
00:02:06 2013 -0700
@@ -23,7 +23,7 @@

  /*
   * @test
- * @bug 5033583 6316717 6470106
+ * @bug 5033583 6316717 6470106 8004979
   * @summary Check toGenericString() and toString() methods
   * @author Joseph D. Darcy
   */
@@ -39,6 +39,7 @@
          classList.add(TestClass1.class);
          classList.add(TestClass2.class);
          classList.add(Roebling.class);
+        classList.add(TestInterface1.class);


          for(Class clazz: classList)
@@ -129,6 +130,20 @@
      void varArg(Object ... arg) {}
  }

+interface TestInterface1 {
+    @ExpectedGenericString(
+   "public default void TestInterface1.foo()")
+    @ExpectedString(
+   "public default void TestInterface1.foo()")
+    public default void foo(){;}
+
+    @ExpectedString(
+   "public default java.lang.Object TestInterface1.bar()")
+    @ExpectedGenericString(
+   "public default  A TestInterface1.bar()")
+    default  A bar(){return null;}
+}
+
  @Retention(RetentionPolicy.RUNTIME)
  @interface ExpectedGenericString {
      String value();



From erik.joelsson at oracle.com  Thu Mar 28 08:11:56 2013
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 28 Mar 2013 09:11:56 +0100
Subject: RFR JDK-8010267 & JDK-8010268 : Makefile maintenance for test
	targets
In-Reply-To: <081944A1-4DBD-4E24-8C7C-355AFD37196B@oracle.com>
References: 
	<081944A1-4DBD-4E24-8C7C-355AFD37196B@oracle.com>
Message-ID: <5153FB4C.2020905@oracle.com>

Both of these look good to me, but you still need a jdk8 reviewer.

/Erik

On 2013-03-27 17:27, Mike Duigou wrote:
> I still need a review for both of these changes.
>
> Mike
>
> On Mar 18 2013, at 22:48 , Mike Duigou wrote:
>
>> A two small changes to review:
>>
>> If approved I will commit to TL (or someone else can commit to build for me)
>>
>> Mike
>>
>> JDK-8010267 : Add test-clean for cleaning of testoutput directory from output directory.
>>
>> diff --git a/common/makefiles/Main.gmk b/common/makefiles/Main.gmk
>> --- a/common/makefiles/Main.gmk
>> +++ b/common/makefiles/Main.gmk
>> @@ -191,7 +191,7 @@ source-tips: $(OUTPUT_ROOT)/source_tips
>>
>>
>> # Remove everything, except the output from configure.
>> -clean: clean-langtools clean-corba clean-jaxp clean-jaxws clean-hotspot clean-jdk clean-images clean-overlay-images clean-bootcycle-build clean-docs
>> +clean: clean-langtools clean-corba clean-jaxp clean-jaxws clean-hotspot clean-jdk clean-images clean-overlay-images clean-bootcycle-build clean-docs clean-test
>>         @($(CD) $(OUTPUT_ROOT)&&  $(RM) -r tmp source_tips build.log* build-trace*.log*)
>>         @$(ECHO) Cleaned all build artifacts.
>>
>> @@ -230,6 +230,8 @@ clean-bootcycle-build:
>> clean-docs:
>>         $(call CleanComponent,docs)
>>         $(call CleanComponent,docstemp)
>> +clean-test:
>> +       $(call CleanComponent,testoutput)
>>
>> .PHONY: langtools corba jaxp jaxws hotspot jdk images overlay-images install
>> .PHONY: langtools-only corba-only jaxp-only jaxws-only hotspot-only jdk-only images-only overlay-images-only install-only
>>
>>
>> JDK-8010268 : Remove dependence upon clean target from jdk/test/Makefile prep target
>>
>> None of the current users seem to depend upon the clean behaviour of "prep"
>>
>> diff --git a/test/Makefile b/test/Makefile
>> --- a/test/Makefile
>> +++ b/test/Makefile
>> @@ -336,7 +336,7 @@ all: jdk_default
>>         @$(ECHO) "Testing completed successfully"
>>
>> # Prep for output
>> -prep: clean
>> +prep:
>>         @$(MKDIR) -p $(ABS_TEST_OUTPUT_DIR)
>>         @$(MKDIR) -p `$(DIRNAME) $(ARCHIVE_BUNDLE)`
>>
>>


From john.r.rose at oracle.com  Thu Mar 28 08:54:16 2013
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 28 Mar 2013 01:54:16 -0700
Subject: Review request for 7198429: need checked categorization of
	caller-sensitive methods in the JDK
In-Reply-To: <51532DF4.9020701@oracle.com>
References: <51532DF4.9020701@oracle.com>
Message-ID: <8BA7EB20-0798-41E4-A391-DC195A147317@oracle.com>

On Mar 27, 2013, at 10:35 AM, Mandy Chung  wrote:

> 1. I am working on a fix for 8007035 that proposes to deprecate SecurityManager.checkMemberAccess method as it requires the caller?s frame to be at a stack depth of four, which is fragile and difficult to enforce.

Where you test c=smgr.getClass(), c == SecurityManager.class you should also add
|| c.getMethod("checkSecurityManager", ...).getDeclaringClass() == SecurityManager.class. 

That will accurately detect overloading. 

-- John  (on my iPhone)

From peter.levart at gmail.com  Thu Mar 28 08:56:38 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 28 Mar 2013 09:56:38 +0100
Subject: RFR (M): 7198429: need checked categorization of caller-sensitive
	methods in the JDK
In-Reply-To: <5153BA35.6060808@oracle.com>
References: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com>
	<5149825D.1040608@gmail.com> <514B4D3F.7040600@oracle.com>
	<514B55CA.6040907@gmail.com> <5153BA35.6060808@oracle.com>
Message-ID: <515405C6.9050605@gmail.com>

On 03/28/2013 04:34 AM, Mandy Chung wrote:
> Hi Peter,
>
> On 3/21/2013 11:47 AM, Peter Levart wrote:
>> ...
>>
>> I have seen a utility that uses it to establish the context (package 
>> and ClassLoader) of where to start searching for resources for GUI 
>> components construction. And a utility that wraps 
>> Class.forName(String) - specifying Class.forName(name, true, 
>> Reflection.getCallerClass(2).getClassLoader()) instead to use the 
>> caller's class loader to load the class...
>>
>
> This seems to me that this case is more of visibility issue rather 
> than caller-sensitivity.

Hi Mandy,

The package name and class name of the caller is "caller-sensitivity" 
and the ClassLoader of the caller is "visibility". This is a mixed-case.

>
>> Usually it is only necessary to get the immediate caller.
>>
>>>
>>>> Is there a reason to not "unofficially" support also classes with 
>>>> @CS annotated methods and which are not loaded by bootstrap or 
>>>> extension class-loader ?
>>>
>>> We expect that most of the caller-sensitive cases are in the JDK and 
>>> should be rare for non-system libraries to have caller-sensitive 
>>> code.  It'd be good to understand the use cases and the requirements 
>>> to determine the appropriate support for it.
>>
>> Ok, but why limit? Is it an optimization?
>
> Just out of scope and there will be much more consideration to expand 
> the scope to cover the user caller-sensitive methods (e.g. SE API and 
> implementable by different JDK vendors).
>
> The scope of JEP 176 is target for the system code where it has all 
> permissions that we expect majority of the caller-sensitive cases are in.

I understand that. It's just that there is already some code in the wild 
that does the unforgivable and uses Reflection.getCallerClass() and is 
not loaded by system or extension ClassLoader... I guess it will have to 
be "fixed" to be able to run on JDK8. And the fix will be to pack that 
part of code into an extension bundle and put it into the ext 
ClassLoader's dir...

>
>>
>> Is it for security? For example: one might think that creating an 
>> anonymous class and holding a j.l.Class reference somewhere safe is 
>> enough for safety, so the class itself could have public API. Now if 
>> an untrusted callback object is passed to the code of such class and 
>> it is invoked from within that code, the anonymous class can get 
>> "revealed" to the untrusted code which can use it's public API to 
>> invoke it. Are there any other implications of allowing non-system 
>> code to get the caller?
>
> It'd help if you can have a test case showing this to help the 
> discussion.  However, restricting Reflection.getCallerClass be called 
> by the system code is no difference than defining a module-private 
> class.  sun.reflect.* classes are private to the JDK implementation 
> that are not supported.  If there were modules, applications would not 
> have been able to call it since sun.reflect would not be exported.

The code I'm talking about is being deployed using a kind of modules 
system (NetBeans container) and it seems JDK classes are treated 
specially in this modules system, since the code works without 
specifying special dependencies (whole JDK is treated as one big module 
that exports all it's classes).

Here's the relevant code to illustrate the use-case (see the top 3 
factory methods that enable concise in-line use):

import com.google.common.base.Objects;
import com.google.common.base.Preconditions;
import sun.reflect.Reflection;

import java.io.Serializable;
import java.util.Arrays;

/**
  * A Resource Bundle Locator + Resource Key + Optional Arguments
  */
public final class RBKey implements Serializable {
     private static final long serialVersionUID = 1L;

     public static RBKey of() {
         return new RBKey(Reflection.getCallerClass(2));
     }

     public static RBKey of(String subKey) {
         return new RBKey(Reflection.getCallerClass(2)).sub(subKey);
     }

     public static RBKey of(String subKey, Object... arguments) {
         return new RBKey(Reflection.getCallerClass(2)).sub(subKey, 
arguments);
     }

     public static String bundleName(Class clazz) {
         String className = namedClass(clazz).getName();
         int lastDot = className.lastIndexOf('.');
         return lastDot >= 0 ? className.substring(0, lastDot + 1) + 
"Bundle" : "Bundle";
     }

     public static String keyPrefix(Class clazz) {
         String className = namedClass(clazz).getName();
         int lastDot = className.lastIndexOf('.');
         return lastDot >= 0 ? className.substring(lastDot + 1) : className;
     }

     private static Class namedClass(Class clazz) {
         while (clazz.isAnonymousClass() && clazz.getEnclosingClass() != 
null)
             clazz = clazz.getEnclosingClass();

         return clazz;
     }

     private final Class clazz;
     private final String bundleName, key;
     private final Object[] arguments;

     public RBKey(Class clazz) {
         this(clazz, bundleName(clazz), keyPrefix(clazz), (Object[]) null);
     }

     public RBKey(Class clazz, String bundleName, String keyPrefix, 
Object... arguments) {
         this.clazz = Preconditions.checkNotNull(clazz, "'clazz' should 
be non-null");
         this.bundleName = Preconditions.checkNotNull(bundleName, 
"'bundleName' should be non-null");
         this.key = keyPrefix;
         this.arguments = arguments == null || arguments.length == 0 ? 
null : arguments;
     }

     public Class getClazz() {
         return clazz;
     }

     public String getBundleName() {
         return bundleName;
     }

     public String getKey() {
         return key;
     }

     public Object[] getArguments() {
         return arguments == null ? null : arguments.clone();
     }

     Object[] getArgumentsNoClone() {
         return arguments;
     }

     public RBKey sub(String subKey) {
         if (subKey == null) {
             throw new NullPointerException("'subKey' should not be null");
         }

         return new RBKey(clazz, bundleName, (key == null ? subKey : key 
+ "." + subKey), arguments);
     }

     public RBKey sub(String subKey, Object... arguments) {
         if (subKey == null) {
             throw new NullPointerException("'subKey' should not be null");
         }

         return new RBKey(clazz, bundleName, (key == null ? subKey : key 
+ "." + subKey), arguments);
     }

     public RBKey args(Object... arguments) {
         return new RBKey(clazz, bundleName, key, arguments);
     }

     @Override
     public int hashCode() {
         return clazz.getClassLoader().hashCode() + 31 * (
             bundleName.hashCode() + 31 * (
                 (key == null ? 0 : key.hashCode()) + 31 * 
Arrays.hashCode(arguments)
             )
         );
     }

     @Override
     public boolean equals(Object obj) {
         if (obj == null) return false;
         if (obj == this) return true;
         if (obj.getClass() != RBKey.class) return false;

         RBKey other = (RBKey) obj;

         return this.clazz.getClassLoader() == 
other.clazz.getClassLoader() &&
                Objects.equal(this.key, other.key) &&
                Arrays.equals(this.arguments, other.arguments);
     }

     @Override
     public String toString() {
         StringBuilder sb = new StringBuilder(bundleName);

         if (key != null)
             sb.append('#').append(key);

         if (arguments != null)
             sb.append(Arrays.toString(arguments));

         return sb.toString();
     }
}



>
> I would recommend to file a RFE and describe the use cases that 
> require an API to get the caller class or find caller's context so 
> that we can address it properly.
>
> With this fix, the only way to call Reflection.getCallerClass must be 
> system code (in bootclasspath or extension library).   As a 
> workaround, can you put it on the bootclasspath?

More likely on the extension ClassLoader's classpath. I guess I could 
with some packaging acrobatics.

Regards, Peter

>
> Mandy



From sundararajan.athijegannathan at oracle.com  Thu Mar 28 09:06:59 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Thu, 28 Mar 2013 09:06:59 +0000
Subject: hg: jdk8/tl/jdk: 8010991: Enable
	test/javax/script/GetInterfaceTest.java again
Message-ID: <20130328090857.B19F448458@hg.openjdk.java.net>

Changeset: 811c771acf65
Author:    sundar
Date:      2013-03-28 14:36 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/811c771acf65

8010991: Enable test/javax/script/GetInterfaceTest.java again
Reviewed-by: lagergren, hannesw

! test/javax/script/GetInterfaceTest.java



From bourges.laurent at gmail.com  Thu Mar 28 09:19:02 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Thu, 28 Mar 2013 10:19:02 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due to
	HashMap leads to Integer allocations (boxing)
In-Reply-To: <5153B2C3.4040101@oracle.com>
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com> <514B2E8D.8060701@gmail.com>
	<514B92A7.1000305@oracle.com>
	
	<514C2C94.60700@gmail.com>
	
	<514C4E09.3020008@gmail.com> <514C5C8D.1090406@gmail.com>
	<514C859D.1050705@gmail.com> <51503925.1020403@gmail.com>
	<51507BE0.6000502@gmail.com> <51521537.8070905@oracle.com>
	<51532203.1090902@gmail.com> <5153B2C3.4040101@oracle.com>
Message-ID: 

Dear Mandy & Peter,

I will test your patch asap (+ benchmark)

Few comments below:


> Webrev at:
>    http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8010309/webrev.00/
>
> Please let me know if you don't agree with these changes or you find any
> performance issue.
>
> I have retained the part in webrev.08 that only defines loggerProxy and
> javaLoggerProxy.  I don't think the new defaultLoggerProxy variable is
> needed.  I prefer to use Class.forName to force load JavaLoggerProxy class
> to make very explicit that we don't want the class be initialized.
> JavaLoggerProxy. calls LoggingProxy.parseLevel unconditionally that
> will throw an AssertionError if java.util.logging is not available. If
> JavaLoggerProxy class is initialized, j.u.logging should be present and I
> want to catch error if otherwise.  Also Class.forName will load its
> superclass LoggerProxy.
>

I think it leads to early initialization of JUL Levels (when JUL is maybe
not available or initialized) from PlatformLogger static initialization:

        // initialize javaLevel fields for mapping from Level enum ->
j.u.l.Level object
        static {
            for (Level level : Level.values()) {
                level.javaLevel = LoggingSupport.parseLevel(level.name());
            }
        }

I thought Level.javaLevel should only be defined ONCE JUL is available i.e.
once PlatformLogger.redirectPlatformLoggers() is called.
I propose to move the javaLevel initialization in this method:

    public static synchronized void redirectPlatformLoggers() {
        if (loggingEnabled || !LoggingSupport.isAvailable()) return;

            // Resolve JUL Levels ONLY when JUL is initialized by
application code:
            for (Level level : Level.values()) {
                level.javaLevel = LoggingSupport.parseLevel(level.name());
            }

...
}



>
> As for the PlatformLogger.Level enums, having the members to be defined in
> ascending order is fragile.  It'd be more reliable to specify the value in
> the constructor so that it can be used as the isLoggable comparsion in the
> same way as in the Level implementation.
>

Good idea.


>
> On 3/27/2013 9:44 AM, Peter Levart wrote:
>
> Hi Mandy, Laurent,
>
> It turns out that the API change (change of type for level parameter int
> -> enum Level) is entirely source-compatible. The tip of JDK8 (tl repo)
> builds without a problem. So no-one is currently using
> PlatformLogger.getLevel() method and assigning it to a variable or such...
>
>
> Great thanks.  That is what I expect too.
>

If getLevel() is useless, why keep it in this proprietary API ? (only for
test purposes) ?


>
>
>  Here's the webrev for this change:
>
>
> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.enumapi.01/index.html
>
> Besides doing the replacement of type and renaming and removing of the
> unneeded stuff, I also did some re-arrangements:
>
> - introduced a common abstract superclass for both types of LoggerProxys
> (DefaultLoggerProxy, JavaLoggerProxy), since JavaLoggerProxy does not need
> the fields of DefaultLoggerProxy and now both concrete subclasses can be
> declared final (makes JIT even more happy). Also the abstract LoggerProxy
> could host some common logic (see below about formatting)...
>
>
> That's a good idea.
>
>
>  - DefaultLoggerProxy's levelValue/effectiveLevel were given names just
> the opposite of their meaning. I aligned them with terminology used in
> j.u.l.Logger and renamed levelValue to plain level.
>
>
> Swapping these 2 variables makes sense.
>
>
>  - introduced private method DefaultLoggerProxy.deriveEffectiveLevel(level)
> that currently just returns defaultLevel (INFO) when given null.
>
>
> Ok.
>
>
>  I think with a little more effort, it could be possible to emulate the
> behaviour of j.u.l.Logger which inherits from 1st parent logger that has
> non-null level assigned. Of course with all the caching and invalidation...
>
>
> The only way to change the level to a non-default one is via the logging
> configuration and enable logging.  That's why there is no need for
> DefaultLoggerProxy to inherit level from its parent logger.  Also there is
> no parent logger hierarchy maintained in DefaultLoggerProxy.
>
>
>  - instead of static final DefaultLoggerProxy.defaultStream I created a
> private static method outputStream() that returns System.err. To accomodate
> for the situation when System.err is changed dynamically.
>
>
> Ok.
>
>
>  - fixed the JavaLoggerProxy.isEnabled() method. Original code was:
>
>  532         boolean isEnabled() { 533             Object level = LoggingSupport.getLevel(javaLogger); 534             return level == null || level.equals(levelObjects.get(OFF)) == false;
>  535         }
>
>
> If 'level' is null then it can be that 1st parent that has a non-nul level
> is "OFF". I think that in such situation all the children that don't
> override the level should be disabled too. The following does exactly that:
>
>  597         boolean isEnabled() { 598             return LoggingSupport.isLoggable(javaLogger, Level.OFF.javaLevel);
>  599         }
>
>
>
> That is right.  Good catch.
>
>
>  That's all for 1st rev. Besides the effective level inheritance, the
> following method in JavaLoggerProxy also caught my eye:
>
>         void doLog(Level level, String msg, Object... params) {
>             if (!isLoggable(level)) {
>                 return;
>             }
>             // only pass String objects to the j.u.l.Logger which may
>             // be created by untrusted code
>             int len = (params != null) ? params.length : 0;
>             Object[] sparams = new String[len];
>             for (int i = 0; i < len; i++) {
>                 sparams [i] = String.valueOf(params[i]);
>             }
>             LoggingSupport.log(javaLogger, level.javaLevel, msg, sparams);
>         }
>
> I think this could be improved if the DefaultLoggerProxy.formatMessage()
> is used instead of turning each parameter into a String. The method could
> be moved up to abstract LoggerProxy and used in both implementations so
> that common formatting is applied regardless of back-end used.
>
>
> Let's do this in a separate clean up as it's better to keep 8010309 focus
> on performance improvement (although we have mixed this bag with some
> renaming).
>

I disagree Peter: JUL has its own formatting code: patterns ... and more
efficient than DefaultLoggerProxy.formatMessage().

The good question relies in the comment: why convert object args into
String early as JUL can do formatting / conversion?
What does mean:
            // only pass String objects to the j.u.l.Logger which may
            // be created by untrusted code
?
to avoid security issues ?

Laurent


From bourges.laurent at gmail.com  Thu Mar 28 09:34:22 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Thu, 28 Mar 2013 10:34:22 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due to
	HashMap leads to Integer allocations (boxing)
In-Reply-To: 
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com> <514B2E8D.8060701@gmail.com>
	<514B92A7.1000305@oracle.com>
	
	<514C2C94.60700@gmail.com>
	
	<514C4E09.3020008@gmail.com> <514C5C8D.1090406@gmail.com>
	<514C859D.1050705@gmail.com> <51503925.1020403@gmail.com>
	<51507BE0.6000502@gmail.com> <51521537.8070905@oracle.com>
	<51532203.1090902@gmail.com> <5153B2C3.4040101@oracle.com>
	
Message-ID: 

Sorry for my previous comment: JavaLoggerProxy static initialization is not
called (false argument);

I made the test:
JavaLoggerProxy: static initialization...
LoggingSupport.isAvailable: true
java.lang.Throwable
    at
sun.util.logging.PlatformLogger$JavaLoggerProxy.(PlatformLogger.java:562)
    at
sun.util.logging.PlatformLogger.redirectToJavaLoggerProxy(PlatformLogger.java:200)
    at
sun.util.logging.PlatformLogger.redirectPlatformLoggers(PlatformLogger.java:190)
    at java.util.logging.LogManager$2.run(LogManager.java:290)
    at java.util.logging.LogManager$2.run(LogManager.java:285)
    at java.security.AccessController.doPrivileged(Native Method)
    at
java.util.logging.LogManager.readPrimordialConfiguration(LogManager.java:285)
    at java.util.logging.LogManager.getLogManager(LogManager.java:267)
    at java.util.logging.Logger.(Logger.java:280)
    at java.util.logging.LogManager$RootLogger.(LogManager.java:1372)
    at java.util.logging.LogManager$RootLogger.(LogManager.java:1370)
    at java.util.logging.LogManager$1.run(LogManager.java:198)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.util.logging.LogManager.(LogManager.java:175)
    at test.PlatformLoggerBenchmark.main(PlatformLoggerBenchmark.java:39)

Maybe you should introduce an explicit variable to make it more obvious:
        boolean initialize = false; // lazy initialization

        // force loading of all JavaLoggerProxy (sub)classes to make JIT
de-optimizations
        // less probable.  Don't initialize JavaLoggerProxy class since
        // java.util.logging may not be enabled.
        try {

Class.forName("sun.util.logging.PlatformLogger$DefaultLoggerProxy",
                          initialize,
                          PlatformLogger.class.getClassLoader());
            Class.forName("sun.util.logging.PlatformLogger$JavaLoggerProxy",
                          initialize,
                          PlatformLogger.class.getClassLoader());
        } catch (ClassNotFoundException ex) {
            throw new InternalError(ex);
        }

Laurent


2013/3/28 Laurent Bourg?s 

> Dear Mandy & Peter,
>
> I will test your patch asap (+ benchmark)
>
> Few comments below:
>
>
>> Webrev at:
>>    http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8010309/webrev.00/
>>
>> Please let me know if you don't agree with these changes or you find any
>> performance issue.
>>
>> I have retained the part in webrev.08 that only defines loggerProxy and
>> javaLoggerProxy.  I don't think the new defaultLoggerProxy variable is
>> needed.  I prefer to use Class.forName to force load JavaLoggerProxy class
>> to make very explicit that we don't want the class be initialized.
>> JavaLoggerProxy. calls LoggingProxy.parseLevel unconditionally that
>> will throw an AssertionError if java.util.logging is not available. If
>> JavaLoggerProxy class is initialized, j.u.logging should be present and I
>> want to catch error if otherwise.  Also Class.forName will load its
>> superclass LoggerProxy.
>>
>
> I think it leads to early initialization of JUL Levels (when JUL is maybe
> not available or initialized) from PlatformLogger static initialization:
>
>         // initialize javaLevel fields for mapping from Level enum ->
> j.u.l.Level object
>         static {
>             for (Level level : Level.values()) {
>                 level.javaLevel = LoggingSupport.parseLevel(level.name());
>             }
>         }
>
> I thought Level.javaLevel should only be defined ONCE JUL is available
> i.e. once PlatformLogger.redirectPlatformLoggers() is called.
> I propose to move the javaLevel initialization in this method:
>
>     public static synchronized void redirectPlatformLoggers() {
>         if (loggingEnabled || !LoggingSupport.isAvailable()) return;
>
>             // Resolve JUL Levels ONLY when JUL is initialized by
> application code:
>             for (Level level : Level.values()) {
>                 level.javaLevel = LoggingSupport.parseLevel(level.name());
>             }
>
> ...
> }
>
>
>
>>
>> As for the PlatformLogger.Level enums, having the members to be defined
>> in ascending order is fragile.  It'd be more reliable to specify the value
>> in the constructor so that it can be used as the isLoggable comparsion in
>> the same way as in the Level implementation.
>>
>
> Good idea.
>
>
>>
>> On 3/27/2013 9:44 AM, Peter Levart wrote:
>>
>> Hi Mandy, Laurent,
>>
>> It turns out that the API change (change of type for level parameter int
>> -> enum Level) is entirely source-compatible. The tip of JDK8 (tl repo)
>> builds without a problem. So no-one is currently using
>> PlatformLogger.getLevel() method and assigning it to a variable or such...
>>
>>
>> Great thanks.  That is what I expect too.
>>
>
> If getLevel() is useless, why keep it in this proprietary API ? (only for
> test purposes) ?
>
>
>>
>>
>>  Here's the webrev for this change:
>>
>>
>> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.enumapi.01/index.html
>>
>> Besides doing the replacement of type and renaming and removing of the
>> unneeded stuff, I also did some re-arrangements:
>>
>> - introduced a common abstract superclass for both types of LoggerProxys
>> (DefaultLoggerProxy, JavaLoggerProxy), since JavaLoggerProxy does not need
>> the fields of DefaultLoggerProxy and now both concrete subclasses can be
>> declared final (makes JIT even more happy). Also the abstract LoggerProxy
>> could host some common logic (see below about formatting)...
>>
>>
>> That's a good idea.
>>
>>
>>  - DefaultLoggerProxy's levelValue/effectiveLevel were given names just
>> the opposite of their meaning. I aligned them with terminology used in
>> j.u.l.Logger and renamed levelValue to plain level.
>>
>>
>> Swapping these 2 variables makes sense.
>>
>>
>>  - introduced private method DefaultLoggerProxy.deriveEffectiveLevel(level)
>> that currently just returns defaultLevel (INFO) when given null.
>>
>>
>> Ok.
>>
>>
>>  I think with a little more effort, it could be possible to emulate the
>> behaviour of j.u.l.Logger which inherits from 1st parent logger that has
>> non-null level assigned. Of course with all the caching and invalidation...
>>
>>
>> The only way to change the level to a non-default one is via the logging
>> configuration and enable logging.  That's why there is no need for
>> DefaultLoggerProxy to inherit level from its parent logger.  Also there is
>> no parent logger hierarchy maintained in DefaultLoggerProxy.
>>
>>
>>  - instead of static final DefaultLoggerProxy.defaultStream I created a
>> private static method outputStream() that returns System.err. To accomodate
>> for the situation when System.err is changed dynamically.
>>
>>
>> Ok.
>>
>>
>>  - fixed the JavaLoggerProxy.isEnabled() method. Original code was:
>>
>>  532         boolean isEnabled() { 533             Object level = LoggingSupport.getLevel(javaLogger); 534             return level == null || level.equals(levelObjects.get(OFF)) == false;
>>  535         }
>>
>>
>> If 'level' is null then it can be that 1st parent that has a non-nul
>> level is "OFF". I think that in such situation all the children that don't
>> override the level should be disabled too. The following does exactly that:
>>
>>  597         boolean isEnabled() { 598             return LoggingSupport.isLoggable(javaLogger, Level.OFF.javaLevel);
>>  599         }
>>
>>
>>
>> That is right.  Good catch.
>>
>>
>>  That's all for 1st rev. Besides the effective level inheritance, the
>> following method in JavaLoggerProxy also caught my eye:
>>
>>         void doLog(Level level, String msg, Object... params) {
>>             if (!isLoggable(level)) {
>>                 return;
>>             }
>>             // only pass String objects to the j.u.l.Logger which may
>>             // be created by untrusted code
>>             int len = (params != null) ? params.length : 0;
>>             Object[] sparams = new String[len];
>>             for (int i = 0; i < len; i++) {
>>                 sparams [i] = String.valueOf(params[i]);
>>             }
>>             LoggingSupport.log(javaLogger, level.javaLevel, msg, sparams);
>>         }
>>
>> I think this could be improved if the DefaultLoggerProxy.formatMessage()
>> is used instead of turning each parameter into a String. The method could
>> be moved up to abstract LoggerProxy and used in both implementations so
>> that common formatting is applied regardless of back-end used.
>>
>>
>> Let's do this in a separate clean up as it's better to keep 8010309 focus
>> on performance improvement (although we have mixed this bag with some
>> renaming).
>>
>
> I disagree Peter: JUL has its own formatting code: patterns ... and more
> efficient than DefaultLoggerProxy.formatMessage().
>
> The good question relies in the comment: why convert object args into
> String early as JUL can do formatting / conversion?
> What does mean:
>             // only pass String objects to the j.u.l.Logger which may
>             // be created by untrusted code
> ?
> to avoid security issues ?
>
> Laurent
>
>


From peter.levart at gmail.com  Thu Mar 28 09:52:54 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 28 Mar 2013 10:52:54 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due
	to HashMap leads to Integer allocations (boxing)
In-Reply-To: <5153B2C3.4040101@oracle.com>
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com> <514B2E8D.8060701@gmail.com>
	<514B92A7.1000305@oracle.com>
	
	<514C2C94.60700@gmail.com>
	
	<514C4E09.3020008@gmail.com> <514C5C8D.1090406@gmail.com>
	<514C859D.1050705@gmail.com> <51503925.1020403@gmail.com>
	<51507BE0.6000502@gmail.com> <51521537.8070905@oracle.com>
	<51532203.1090902@gmail.com> <5153B2C3.4040101@oracle.com>
Message-ID: <515412F6.9070706@gmail.com>

On 03/28/2013 04:02 AM, Mandy Chung wrote:
> Hi Peter,
>
> It looks better.   I want to wrap up this patch and push the changeset 
> tomorrow.   I have made slight modification and clean up some comments 
> and the test.  See my comments inlined below.
>
> Webrev at:
> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8010309/webrev.00/
>
> Please let me know if you don't agree with these changes or you find 
> any performance issue.

Hi Mandy,

Your changes make sense. The performance impact (using 2 volatile fields 
instead of 3) is negligable. It is actually a little faster on i7 CPU 
and a little slower on T2-sparc, but only affects the speed of 
DefaultLoggerProxy code-path (see my previous mail for comparison):

##############################################################
# Java: 1.8.0-internal-peter_2013_01_16_13_44-b00
#   VM: OpenJDK 64-Bit Server VM 25.0-b14 (mixed mode)
#   OS: Linux 3.7.9-104.fc17.x86_64 (amd64)
# CPUs: 8 (virtual)
#
#-------------------------------------------------------------
# isLoggableFinest: run duration:  3,000 ms
#
# Warm up:
#           1 threads, Tavg =      1.42 ns/op (? =   0.00 ns/op) [     1.42]
#           1 threads, Tavg =      1.42 ns/op (? =   0.00 ns/op) [     1.42]
# Measure:
             1 threads, Tavg =      1.47 ns/op (? =   0.00 ns/op) [     
1.47]
             2 threads, Tavg =      1.46 ns/op (? =   0.01 ns/op) [     
1.48,      1.45]
             3 threads, Tavg =      1.46 ns/op (? =   0.01 ns/op) [     
1.47,      1.45,      1.45]
             4 threads, Tavg =      1.47 ns/op (? =   0.01 ns/op) [     
1.48,      1.46,      1.48,      1.45]
#
#-------------------------------------------------------------
# java.util.logging enabled
#
#
#-------------------------------------------------------------
# isLoggableFinest: run duration:  3,000 ms
#
# Measure:
             1 threads, Tavg =      1.74 ns/op (? =   0.00 ns/op) [     
1.74]
             2 threads, Tavg =      1.59 ns/op (? =   0.01 ns/op) [     
1.60,      1.58]
             3 threads, Tavg =      1.59 ns/op (? =   0.01 ns/op) [     
1.59,      1.58,      1.58]
             4 threads, Tavg =      1.61 ns/op (? =   0.01 ns/op) [     
1.62,      1.60,      1.60,      1.61]
             1 threads, Tavg =      1.59 ns/op (? =   0.00 ns/op) [     
1.59]
             2 threads, Tavg =      1.59 ns/op (? =   0.01 ns/op) [     
1.59,      1.58]
             3 threads, Tavg =      1.59 ns/op (? =   0.00 ns/op) [     
1.59,      1.59,      1.59]
             4 threads, Tavg =      1.64 ns/op (? =   0.02 ns/op) [     
1.64,      1.64,      1.62,      1.67]
             1 threads, Tavg =      1.59 ns/op (? =   0.00 ns/op) [     
1.59]
             2 threads, Tavg =      1.59 ns/op (? =   0.01 ns/op) [     
1.60,      1.58]
             3 threads, Tavg =      1.69 ns/op (? =   0.15 ns/op) [     
1.59,      1.91,      1.60]
             4 threads, Tavg =      1.59 ns/op (? =   0.01 ns/op) [     
1.60,      1.59,      1.59,      1.59]
#
#-------------------------------------------------------------
# END.
##############################################################

##############################################################
# Java: 1.8.0-ea-b82
#   VM: Java HotSpot(TM) 64-Bit Server VM 25.0-b23 (mixed mode)
#   OS: SunOS 5.10 (sparcv9)
# CPUs: 64 (virtual)
#
#-------------------------------------------------------------
# isLoggableFinest: run duration:  3,000 ms
#
# Warm up:
#           1 threads, Tavg =     45.97 ns/op (? =   0.00 ns/op) [    45.97]
#           1 threads, Tavg =     42.99 ns/op (? =   0.00 ns/op) [    42.99]
# Measure:
             1 threads, Tavg =     43.10 ns/op (? =   0.00 ns/op) [    
43.10]
             2 threads, Tavg =     43.06 ns/op (? =   0.03 ns/op) [    
43.03,     43.08]
             3 threads, Tavg =     43.13 ns/op (? =   0.23 ns/op) [    
43.46,     42.99,     42.95]
             4 threads, Tavg =     43.19 ns/op (? =   0.14 ns/op) [    
42.97,     43.19,     43.36,     43.25]
#
#-------------------------------------------------------------
# java.util.logging enabled
#
#
#-------------------------------------------------------------
# isLoggableFinest: run duration:  3,000 ms
#
# Measure:
             1 threads, Tavg =    102.15 ns/op (? =   0.00 ns/op) [   
102.15]
             2 threads, Tavg =    100.78 ns/op (? =   0.13 ns/op) [   
100.65,    100.90]
             3 threads, Tavg =     49.12 ns/op (? =   0.11 ns/op) [    
48.97,     49.20,     49.18]
             4 threads, Tavg =     49.20 ns/op (? =   0.09 ns/op) [    
49.09,     49.31,     49.13,     49.27]
             1 threads, Tavg =     49.16 ns/op (? =   0.00 ns/op) [    
49.16]
             2 threads, Tavg =     48.98 ns/op (? =   0.03 ns/op) [    
48.95,     49.01]
             3 threads, Tavg =     49.04 ns/op (? =   0.09 ns/op) [    
48.94,     49.15,     49.04]
             4 threads, Tavg =     49.08 ns/op (? =   0.12 ns/op) [    
48.93,     49.11,     49.02,     49.26]
             1 threads, Tavg =     49.06 ns/op (? =   0.00 ns/op) [    
49.06]
             2 threads, Tavg =     49.26 ns/op (? =   0.32 ns/op) [    
48.94,     49.59]
             3 threads, Tavg =     49.01 ns/op (? =   0.06 ns/op) [    
49.09,     48.95,     49.00]
             4 threads, Tavg =     49.66 ns/op (? =   0.34 ns/op) [    
49.90,     49.70,     49.10,     49.96]
#
#-------------------------------------------------------------
# END.
##############################################################


...just a nit! In the test:

     private static void checkPlatformLoggerLevelMapping(Level level) {
         // map the given level to PlatformLogger.Level of the same name 
and value
         PlatformLogger.Level platformLevel = 
PlatformLogger.Level.valueOf(level.getName());
         if (platformLevel == null || platformLevel.intValue() != 
level.intValue()) {
             throw new RuntimeException("Mismatched level: " + level
                     + " PlatformLogger.Level" + platformLevel);
         }

The Level.valueOf(String) is guaranteed to not return null.


Regards, Peter

>
> I have retained the part in webrev.08 that only defines loggerProxy 
> and javaLoggerProxy.  I don't think the new defaultLoggerProxy 
> variable is needed.  I prefer to use Class.forName to force load 
> JavaLoggerProxy class to make very explicit that we don't want the 
> class be initialized. JavaLoggerProxy. calls 
> LoggingProxy.parseLevel unconditionally that will throw an 
> AssertionError if java.util.logging is not available. If 
> JavaLoggerProxy class is initialized, j.u.logging should be present 
> and I want to catch error if otherwise.  Also Class.forName will load 
> its superclass LoggerProxy.
>
> As for the PlatformLogger.Level enums, having the members to be 
> defined in ascending order is fragile.  It'd be more reliable to 
> specify the value in the constructor so that it can be used as the 
> isLoggable comparsion in the same way as in the Level implementation.
>
> I am running the jdk core regression tests on all platforms and should 
> have the result by tomorrow.
>
> On 3/27/2013 9:44 AM, Peter Levart wrote:
>> Hi Mandy, Laurent,
>>
>> It turns out that the API change (change of type for level parameter 
>> int -> enum Level) is entirely source-compatible. The tip of JDK8 (tl 
>> repo) builds without a problem. So no-one is currently using 
>> PlatformLogger.getLevel() method and assigning it to a variable or 
>> such...
>>
>
> Great thanks.  That is what I expect too.
>
>> Here's the webrev for this change:
>>
>> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.enumapi.01/index.html
>>
>> Besides doing the replacement of type and renaming and removing of 
>> the unneeded stuff, I also did some re-arrangements:
>>
>> - introduced a common abstract superclass for both types of 
>> LoggerProxys (DefaultLoggerProxy, JavaLoggerProxy), since 
>> JavaLoggerProxy does not need the fields of DefaultLoggerProxy and 
>> now both concrete subclasses can be declared final (makes JIT even 
>> more happy). Also the abstract LoggerProxy could host some common 
>> logic (see below about formatting)...
>
> That's a good idea.
>
>> - DefaultLoggerProxy's levelValue/effectiveLevel were given names 
>> just the opposite of their meaning. I aligned them with terminology 
>> used in j.u.l.Logger and renamed levelValue to plain level.
>
> Swapping these 2 variables makes sense.
>
>> - introduced private method 
>> DefaultLoggerProxy.deriveEffectiveLevel(level) that currently just 
>> returns defaultLevel (INFO) when given null.
>
> Ok.
>
>> I think with a little more effort, it could be possible to emulate 
>> the behaviour of j.u.l.Logger which inherits from 1st parent logger 
>> that has non-null level assigned. Of course with all the caching and 
>> invalidation...
>
> The only way to change the level to a non-default one is via the 
> logging configuration and enable logging.  That's why there is no need 
> for DefaultLoggerProxy to inherit level from its parent logger.  Also 
> there is no parent logger hierarchy maintained in DefaultLoggerProxy.
>
>> - instead of static final DefaultLoggerProxy.defaultStream I created 
>> a private static method outputStream() that returns System.err. To 
>> accomodate for the situation when System.err is changed dynamically.
>
> Ok.
>
>> - fixed the JavaLoggerProxy.isEnabled() method. Original code was:
>>
>>   532         boolean isEnabled() {
>>   533             Object level = LoggingSupport.getLevel(javaLogger);
>>   534             return level == null || level.equals(levelObjects.get(OFF)) == false;
>>   535         }
>>
>> If 'level' is null then it can be that 1st parent that has a non-nul 
>> level is "OFF". I think that in such situation all the children that 
>> don't override the level should be disabled too. The following does 
>> exactly that:
>>
>>   597         boolean isEnabled() {
>>   598             return LoggingSupport.isLoggable(javaLogger, Level.OFF.javaLevel);
>>   599         }
>>
>
> That is right.  Good catch.
>
>> That's all for 1st rev. Besides the effective level inheritance, the 
>> following method in JavaLoggerProxy also caught my eye:
>>
>>         void doLog(Level level, String msg, Object... params) {
>>             if (!isLoggable(level)) {
>>                 return;
>>             }
>>             // only pass String objects to the j.u.l.Logger which may
>>             // be created by untrusted code
>>             int len = (params != null) ? params.length : 0;
>>             Object[] sparams = new String[len];
>>             for (int i = 0; i < len; i++) {
>>                 sparams [i] = String.valueOf(params[i]);
>>             }
>>             LoggingSupport.log(javaLogger, level.javaLevel, msg, 
>> sparams);
>>         }
>>
>> I think this could be improved if the 
>> DefaultLoggerProxy.formatMessage() is used instead of turning each 
>> parameter into a String. The method could be moved up to abstract 
>> LoggerProxy and used in both implementations so that common 
>> formatting is applied regardless of back-end used.
>>
>
> Let's do this in a separate clean up as it's better to keep 8010309 
> focus on performance improvement (although we have mixed this bag with 
> some renaming).
>
>> The benchmarks still show stable performance:
>>
>
> Great.  Hope we will wrap up tomorrow.
>
> thanks for the contribution.
> Mandy
>
>>
>>
>> Regards, Peter
>>
>>
>> On 03/26/2013 10:37 PM, Mandy Chung wrote:
>>> Hi Peter,
>>>
>>>> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.08/index.html
>>> I'm glad that you observe similar performance improvement without 
>>> the need of method handles.  I reviewed this version and realize 
>>> that the map from j.u.l.Level object to LevelEnum can be removed 
>>> entirely.
>>>
>>> sun.util.logging.PlatformLogger is an internal API that should only 
>>> be used by JDK.  The static final int fields representing the level 
>>> value can be changed to be static final LevelEnum type instead.  I 
>>> checked the JDK code that uses PlatformLogger and no code will be 
>>> impacted by the change of the type of these static fields.  So it 
>>> removes the need to map from an integer value to LevelEnum.  Mapping 
>>> from a j.u.l.Level to LevelEnum is trivial - the name of the 
>>> LevelEnum is the same as j.u.l.Level (e.g. LevelEnum.FINEST and 
>>> Level.FINEST), you can call LoggingSupport.getLevelName(javaLevel) 
>>> to find its name and LevelEnum.valueOf(levelName) returns the 
>>> LevelEnum instance.  However, this would require more changes - 
>>> basically the methods taking "int level" as a parameter would be 
>>> modified to take LevelEnum and getLevel() would return LevelEnum 
>>> too.  I think it's worth doing this cleanup to get rid of the 
>>> unnecessary conversion from int -> enum -> j.u.l.Level and vice 
>>> versa.  I also recommend to rename LevelEnum to Level which is an 
>>> inner class of PlatformLogger.  What do you think of this 
>>> alternative to get rid of the map?
>>>
>>> Some other comments of your patch:
>>> - it renames the class JavaLogger to JavaLoggerProxy and the 
>>> variable from logger to loggerProxy. I'm fine with that.
>>> - L162: JavaLoggerProxy.init() to force load of the class which 
>>> leads to separating the initialization of LevelEnum.javaLevel in a 
>>> new JavaLevel class.  The JavaLevel utility methods are not needed 
>>> if we change the static final fields to LevelEnum.
>>>
>>> Have you tried:
>>> Class.forName("sun.util.logging.PlatformLogger.JavaLoggerProxy", 
>>> false, PlatformLogger.getClassLoader());
>>>
>>> would this give you the same performance improvement?  If so, you 
>>> can keep the static initialization in the JavaLoggerProxy class.
>>>
>>> Thanks for expanding the PlatformLoggerTest to cover additional test 
>>> cases.  It's good that you compare the value of the PlatformLogger 
>>> static final fields with j.u.l.Level.intValue().  You now can use 
>>> the API to compare the LevelEnum with Level rather than reflection.  
>>> Perhaps you can add the getName() and intValue() methods in 
>>> LevelEnum class (just a thought).
>>>
>>> Mandy
>>>
>>>
>>> On 3/25/13 9:31 AM, Peter Levart wrote:
>>>> Well, Laurent, Mandy,
>>>>
>>>> It turns out that the dispatch speed-up (or lack of slow-down to be 
>>>> precise) is possible without MethodHandles too. Maybe some VM guru 
>>>> could shed some light on this, but the following is currently the 
>>>> fastest variant:
>>>>
>>>> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.08/index.html
>>>>
>>>> What I did is a simple "if" deciding between two call-sites, making 
>>>> sure that each is only dispatching to single class. This only 
>>>> works, if both classes (LoggerProxy and JavaLoggerProxy) are loaded 
>>>> in advance, before 1st invocation on any of them is made (might be 
>>>> that using MethodHandles forced initialization of both classes 
>>>> beforehand and hence the speed-up). If I don't load JavaLoggerProxy 
>>>> before warming-up with LoggerProxy, then when j.u.logging is 
>>>> enabled, speed drops for a factor of almost 4 and never catches up 
>>>> even after very long time.
>>>> This pre-loading also helps for a normal single call site dispatch 
>>>> that dispatches to two distinct classes, but the speed 1st drops 
>>>> when the class changes, and only catches-up after several billions 
>>>> of iterations (30s tight loop on i7).
>>>> Now, because JavaLoggerProxy is initialized early, I had to move 
>>>> the initialization of j.u.logging.Level objects and mappings to a 
>>>> separate class "JavaLevel".
>>>>
>>>> Here are the benchmark results for this last iteration...
>>>>
>>>
>>
>



From peter.levart at gmail.com  Thu Mar 28 10:09:45 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 28 Mar 2013 11:09:45 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due
	to HashMap leads to Integer allocations (boxing)
In-Reply-To: 
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com> <514B2E8D.8060701@gmail.com>
	<514B92A7.1000305@oracle.com>
	
	<514C2C94.60700@gmail.com>
	
	<514C4E09.3020008@gmail.com> <514C5C8D.1090406@gmail.com>
	<514C859D.1050705@gmail.com> <51503925.1020403@gmail.com>
	<51507BE0.6000502@gmail.com> <51521537.8070905@oracle.com>
	<51532203.1090902@gmail.com> <5153B2C3.4040101@oracle.com>
	
Message-ID: <515416E9.5090303@gmail.com>

On 03/28/2013 10:19 AM, Laurent Bourg?s wrote:
>
>>     the following method in JavaLoggerProxy also caught my eye:
>>
>>             void doLog(Level level, String msg, Object... params) {
>>                 if (!isLoggable(level)) {
>>                     return;
>>                 }
>>                 // only pass String objects to the j.u.l.Logger which may
>>                 // be created by untrusted code
>>                 int len = (params != null) ? params.length : 0;
>>                 Object[] sparams = new String[len];
>>                 for (int i = 0; i < len; i++) {
>>                     sparams [i] = String.valueOf(params[i]);
>>                 }
>>                 LoggingSupport.log(javaLogger, level.javaLevel, msg,
>>     sparams);
>>             }
>>
>>     I think this could be improved if the
>>     DefaultLoggerProxy.formatMessage() is used instead of turning
>>     each parameter into a String. The method could be moved up to
>>     abstract LoggerProxy and used in both implementations so that
>>     common formatting is applied regardless of back-end used.
>>
>
>     Let's do this in a separate clean up as it's better to keep
>     8010309 focus on performance improvement (although we have mixed
>     this bag with some renaming).
>
>
> I disagree Peter: JUL has its own formatting code: patterns ... and 
> more efficient than DefaultLoggerProxy.formatMessage().
>
> The good question relies in the comment: why convert object args into 
> String early as JUL can do formatting / conversion?
> What does mean:
>             // only pass String objects to the j.u.l.Logger which may
>             // be created by untrusted code
> ?
> to avoid security issues ?

I think so. j.u.logging has a pluggable API and a reference to a 
security-sensitive information could get passed to untrusted code via a 
carelessly written logging statement. The fact that PlatformLogger is 
platform-internal API might give an impression that it is secure. So it 
should be.

I don't know how this formatting actually works in current 
implementation of PlatformLogger delegating to j.u.l.Logger and 
pre-converting the arguments into strings. Isn't formatting in 
j.u.logging type sensitive?

Regards, Peter

>
> Laurent



From jeroen at sumatra.nl  Thu Mar 28 10:38:02 2013
From: jeroen at sumatra.nl (Jeroen Frijters)
Date: Thu, 28 Mar 2013 10:38:02 +0000
Subject: JDK 8 code review request for JDK-8004979
	java.lang.reflect.Modifier.toString should include "default"
In-Reply-To: <5153EB26.7010605@oracle.com>
References: <5153EB26.7010605@oracle.com>
Message-ID: 

Hi Joe,

I notice that Method.isDefault() returns true for static interface methods. I assume that is not correct.

Regards,
Jeroen

> -----Original Message-----
> From: core-libs-dev-bounces at openjdk.java.net [mailto:core-libs-dev-
> bounces at openjdk.java.net] On Behalf Of Joe Darcy
> Sent: Thursday, March 28, 2013 8:03
> To: Core-Libs-Dev
> Subject: JDK 8 code review request for JDK-8004979
> java.lang.reflect.Modifier.toString should include "default"
> 
> Hello,
> 
> Please review these changes to add support for the "default" modifier to
> the output of Method.to[Generic]String:
> 
>      8004979 java.lang.reflect.Modifier.toString should include
> "default"
>      http://cr.openjdk.java.net/~darcy/8004979.0/
> 
> Patch also included below.
> 
> Thanks,
> 
> -Joe
> 
> diff -r d254a5f9b93f
> src/share/classes/java/lang/reflect/Constructor.java
> --- a/src/share/classes/java/lang/reflect/Constructor.java    Wed Mar 27
> 13:40:26 2013 -0400
> +++ b/src/share/classes/java/lang/reflect/Constructor.java    Thu Mar 28
> 00:02:06 2013 -0700
> @@ -284,9 +284,13 @@
>        * modifiers {@code public}, {@code protected} or
>        * {@code private}.  Only one of these may appear, or none if the
>        * constructor has default (package) access.
> +     *
> +     * @return a string describing this {@code Constructor}
> +     * @jls 8.8.3. Constructor Modifiers
>        */
>       public String toString() {
>           return sharedToString(Modifier.constructorModifiers(),
> +                              false,
>                                 parameterTypes,
>                                 exceptionTypes);
>       }
> @@ -328,10 +332,11 @@
>        * include type parameters
>        *
>        * @since 1.5
> +     * @jls 8.8.3. Constructor Modifiers
>        */
>       @Override
>       public String toGenericString() {
> -        return sharedToGenericString(Modifier.constructorModifiers());
> +        return sharedToGenericString(Modifier.constructorModifiers(),
> false);
>       }
> 
>       @Override
> diff -r d254a5f9b93f src/share/classes/java/lang/reflect/Executable.java
> --- a/src/share/classes/java/lang/reflect/Executable.java    Wed Mar 27
> 13:40:26 2013 -0400
> +++ b/src/share/classes/java/lang/reflect/Executable.java    Thu Mar 28
> 00:02:06 2013 -0700
> @@ -89,20 +89,24 @@
> 
>       }
> 
> -    void printModifiersIfNonzero(StringBuilder sb, int mask) {
> +    void printModifiersIfNonzero(StringBuilder sb, int mask, boolean
> isDefault) {
>           int mod = getModifiers() & mask;
>           if (mod != 0) {
>               sb.append(Modifier.toString(mod)).append(' ');
>           }
> +        if (isDefault) {
> +            sb.append("default ");
> +        }
>       }
> 
>       String sharedToString(int modifierMask,
> +                          boolean isDefault,
>                             Class[] parameterTypes,
>                             Class[] exceptionTypes) {
>           try {
>               StringBuilder sb = new StringBuilder();
> 
> -            printModifiersIfNonzero(sb, modifierMask);
> +            printModifiersIfNonzero(sb, modifierMask, isDefault);
>               specificToStringHeader(sb);
> 
>               sb.append('(');
> @@ -124,11 +128,11 @@
>        */
>       abstract void specificToStringHeader(StringBuilder sb);
> 
> -    String sharedToGenericString(int modifierMask) {
> +    String sharedToGenericString(int modifierMask, boolean isDefault) {
>           try {
>               StringBuilder sb = new StringBuilder();
> 
> -            printModifiersIfNonzero(sb, modifierMask);
> +            printModifiersIfNonzero(sb, modifierMask, isDefault);
> 
>               TypeVariable[] typeparms = getTypeParameters();
>               if (typeparms.length > 0) { diff -r d254a5f9b93f
> src/share/classes/java/lang/reflect/Field.java
> --- a/src/share/classes/java/lang/reflect/Field.java    Wed Mar 27
> 13:40:26 2013 -0400
> +++ b/src/share/classes/java/lang/reflect/Field.java    Thu Mar 28
> 00:02:06 2013 -0700
> @@ -288,6 +288,9 @@
>        * {@code protected} or {@code private} first, and then other
>        * modifiers in the following order: {@code static}, {@code
> final},
>        * {@code transient}, {@code volatile}.
> +     *
> +     * @return a string describing this {@code Field}
> +     * @jls 8.3.1 Field Modifiers
>        */
>       public String toString() {
>           int mod = getModifiers();
> @@ -315,6 +318,7 @@
>        * its generic type
>        *
>        * @since 1.5
> +     * @jls 8.3.1 Field Modifiers
>        */
>       public String toGenericString() {
>           int mod = getModifiers();
> diff -r d254a5f9b93f src/share/classes/java/lang/reflect/Method.java
> --- a/src/share/classes/java/lang/reflect/Method.java    Wed Mar 27
> 13:40:26 2013 -0400
> +++ b/src/share/classes/java/lang/reflect/Method.java    Thu Mar 28
> 00:02:06 2013 -0700
> @@ -343,10 +343,16 @@
>        * {@code public}, {@code protected} or {@code private} first,
>        * and then other modifiers in the following order:
>        * {@code abstract}, {@code static}, {@code final},
> -     * {@code synchronized}, {@code native}, {@code strictfp}.
> +     * {@code synchronized}, {@code native}, {@code strictfp},
> +     * {@code default}.
> +     *
> +     * @return a string describing this {@code Method}
> +     *
> +     * @jls 8.4.3 Method Modifiers
>        */
>       public String toString() {
>           return sharedToString(Modifier.methodModifiers(),
> +                              isDefault(),
>                                 parameterTypes,
>                                 exceptionTypes);
>       }
> @@ -389,16 +395,19 @@
>        * {@code public}, {@code protected} or {@code private} first,
>        * and then other modifiers in the following order:
>        * {@code abstract}, {@code static}, {@code final},
> -     * {@code synchronized}, {@code native}, {@code strictfp}.
> +     * {@code synchronized}, {@code native}, {@code strictfp},
> +     * {@code default}.
>        *
>        * @return a string describing this {@code Method},
>        * include type parameters
>        *
>        * @since 1.5
> +     *
> +     * @jls 8.4.3 Method Modifiers
>        */
>       @Override
>       public String toGenericString() {
> -        return sharedToGenericString(Modifier.methodModifiers());
> +        return sharedToGenericString(Modifier.methodModifiers(),
> isDefault());
>       }
> 
>       @Override
> diff -r d254a5f9b93f
> test/java/lang/reflect/Method/GenericStringTest.java
> --- a/test/java/lang/reflect/Method/GenericStringTest.java    Wed Mar 27
> 13:40:26 2013 -0400
> +++ b/test/java/lang/reflect/Method/GenericStringTest.java    Thu Mar 28
> 00:02:06 2013 -0700
> @@ -23,7 +23,7 @@
> 
>   /*
>    * @test
> - * @bug 5033583 6316717 6470106
> + * @bug 5033583 6316717 6470106 8004979
>    * @summary Check toGenericString() and toString() methods
>    * @author Joseph D. Darcy
>    */
> @@ -39,6 +39,7 @@
>           classList.add(TestClass1.class);
>           classList.add(TestClass2.class);
>           classList.add(Roebling.class);
> +        classList.add(TestInterface1.class);
> 
> 
>           for(Class clazz: classList) @@ -129,6 +130,20 @@
>       void varArg(Object ... arg) {}
>   }
> 
> +interface TestInterface1 {
> +    @ExpectedGenericString(
> +   "public default void TestInterface1.foo()")
> +    @ExpectedString(
> +   "public default void TestInterface1.foo()")
> +    public default void foo(){;}
> +
> +    @ExpectedString(
> +   "public default java.lang.Object TestInterface1.bar()")
> +    @ExpectedGenericString(
> +   "public default  A TestInterface1.bar()")
> +    default  A bar(){return null;}
> +}
> +
>   @Retention(RetentionPolicy.RUNTIME)
>   @interface ExpectedGenericString {
>       String value();



From joel.franck at oracle.com  Thu Mar 28 10:55:53 2013
From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=)
Date: Thu, 28 Mar 2013 11:55:53 +0100
Subject: JDK 8 code review request for JDK-8004979
	java.lang.reflect.Modifier.toString should include "default"
In-Reply-To: 
References: <5153EB26.7010605@oracle.com>
	
Message-ID: <460C56FD-8308-4F27-8244-4D311E28ACB4@oracle.com>

Hi Jeroen,

See http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf0049037deb

I'm not sure if this is in a promoted build yet.

cheers
/Joel

On 28 mar 2013, at 11:38, Jeroen Frijters  wrote:

> Hi Joe,
> 
> I notice that Method.isDefault() returns true for static interface methods. I assume that is not correct.
> 
> Regards,
> Jeroen
> 
>> -----Original Message-----
>> From: core-libs-dev-bounces at openjdk.java.net [mailto:core-libs-dev-
>> bounces at openjdk.java.net] On Behalf Of Joe Darcy
>> Sent: Thursday, March 28, 2013 8:03
>> To: Core-Libs-Dev
>> Subject: JDK 8 code review request for JDK-8004979
>> java.lang.reflect.Modifier.toString should include "default"
>> 
>> Hello,
>> 
>> Please review these changes to add support for the "default" modifier to
>> the output of Method.to[Generic]String:
>> 
>>     8004979 java.lang.reflect.Modifier.toString should include
>> "default"
>>     http://cr.openjdk.java.net/~darcy/8004979.0/
>> 
>> Patch also included below.
>> 
>> Thanks,
>> 
>> -Joe
>> 
>> diff -r d254a5f9b93f
>> src/share/classes/java/lang/reflect/Constructor.java
>> --- a/src/share/classes/java/lang/reflect/Constructor.java    Wed Mar 27
>> 13:40:26 2013 -0400
>> +++ b/src/share/classes/java/lang/reflect/Constructor.java    Thu Mar 28
>> 00:02:06 2013 -0700
>> @@ -284,9 +284,13 @@
>>       * modifiers {@code public}, {@code protected} or
>>       * {@code private}.  Only one of these may appear, or none if the
>>       * constructor has default (package) access.
>> +     *
>> +     * @return a string describing this {@code Constructor}
>> +     * @jls 8.8.3. Constructor Modifiers
>>       */
>>      public String toString() {
>>          return sharedToString(Modifier.constructorModifiers(),
>> +                              false,
>>                                parameterTypes,
>>                                exceptionTypes);
>>      }
>> @@ -328,10 +332,11 @@
>>       * include type parameters
>>       *
>>       * @since 1.5
>> +     * @jls 8.8.3. Constructor Modifiers
>>       */
>>      @Override
>>      public String toGenericString() {
>> -        return sharedToGenericString(Modifier.constructorModifiers());
>> +        return sharedToGenericString(Modifier.constructorModifiers(),
>> false);
>>      }
>> 
>>      @Override
>> diff -r d254a5f9b93f src/share/classes/java/lang/reflect/Executable.java
>> --- a/src/share/classes/java/lang/reflect/Executable.java    Wed Mar 27
>> 13:40:26 2013 -0400
>> +++ b/src/share/classes/java/lang/reflect/Executable.java    Thu Mar 28
>> 00:02:06 2013 -0700
>> @@ -89,20 +89,24 @@
>> 
>>      }
>> 
>> -    void printModifiersIfNonzero(StringBuilder sb, int mask) {
>> +    void printModifiersIfNonzero(StringBuilder sb, int mask, boolean
>> isDefault) {
>>          int mod = getModifiers() & mask;
>>          if (mod != 0) {
>>              sb.append(Modifier.toString(mod)).append(' ');
>>          }
>> +        if (isDefault) {
>> +            sb.append("default ");
>> +        }
>>      }
>> 
>>      String sharedToString(int modifierMask,
>> +                          boolean isDefault,
>>                            Class[] parameterTypes,
>>                            Class[] exceptionTypes) {
>>          try {
>>              StringBuilder sb = new StringBuilder();
>> 
>> -            printModifiersIfNonzero(sb, modifierMask);
>> +            printModifiersIfNonzero(sb, modifierMask, isDefault);
>>              specificToStringHeader(sb);
>> 
>>              sb.append('(');
>> @@ -124,11 +128,11 @@
>>       */
>>      abstract void specificToStringHeader(StringBuilder sb);
>> 
>> -    String sharedToGenericString(int modifierMask) {
>> +    String sharedToGenericString(int modifierMask, boolean isDefault) {
>>          try {
>>              StringBuilder sb = new StringBuilder();
>> 
>> -            printModifiersIfNonzero(sb, modifierMask);
>> +            printModifiersIfNonzero(sb, modifierMask, isDefault);
>> 
>>              TypeVariable[] typeparms = getTypeParameters();
>>              if (typeparms.length > 0) { diff -r d254a5f9b93f
>> src/share/classes/java/lang/reflect/Field.java
>> --- a/src/share/classes/java/lang/reflect/Field.java    Wed Mar 27
>> 13:40:26 2013 -0400
>> +++ b/src/share/classes/java/lang/reflect/Field.java    Thu Mar 28
>> 00:02:06 2013 -0700
>> @@ -288,6 +288,9 @@
>>       * {@code protected} or {@code private} first, and then other
>>       * modifiers in the following order: {@code static}, {@code
>> final},
>>       * {@code transient}, {@code volatile}.
>> +     *
>> +     * @return a string describing this {@code Field}
>> +     * @jls 8.3.1 Field Modifiers
>>       */
>>      public String toString() {
>>          int mod = getModifiers();
>> @@ -315,6 +318,7 @@
>>       * its generic type
>>       *
>>       * @since 1.5
>> +     * @jls 8.3.1 Field Modifiers
>>       */
>>      public String toGenericString() {
>>          int mod = getModifiers();
>> diff -r d254a5f9b93f src/share/classes/java/lang/reflect/Method.java
>> --- a/src/share/classes/java/lang/reflect/Method.java    Wed Mar 27
>> 13:40:26 2013 -0400
>> +++ b/src/share/classes/java/lang/reflect/Method.java    Thu Mar 28
>> 00:02:06 2013 -0700
>> @@ -343,10 +343,16 @@
>>       * {@code public}, {@code protected} or {@code private} first,
>>       * and then other modifiers in the following order:
>>       * {@code abstract}, {@code static}, {@code final},
>> -     * {@code synchronized}, {@code native}, {@code strictfp}.
>> +     * {@code synchronized}, {@code native}, {@code strictfp},
>> +     * {@code default}.
>> +     *
>> +     * @return a string describing this {@code Method}
>> +     *
>> +     * @jls 8.4.3 Method Modifiers
>>       */
>>      public String toString() {
>>          return sharedToString(Modifier.methodModifiers(),
>> +                              isDefault(),
>>                                parameterTypes,
>>                                exceptionTypes);
>>      }
>> @@ -389,16 +395,19 @@
>>       * {@code public}, {@code protected} or {@code private} first,
>>       * and then other modifiers in the following order:
>>       * {@code abstract}, {@code static}, {@code final},
>> -     * {@code synchronized}, {@code native}, {@code strictfp}.
>> +     * {@code synchronized}, {@code native}, {@code strictfp},
>> +     * {@code default}.
>>       *
>>       * @return a string describing this {@code Method},
>>       * include type parameters
>>       *
>>       * @since 1.5
>> +     *
>> +     * @jls 8.4.3 Method Modifiers
>>       */
>>      @Override
>>      public String toGenericString() {
>> -        return sharedToGenericString(Modifier.methodModifiers());
>> +        return sharedToGenericString(Modifier.methodModifiers(),
>> isDefault());
>>      }
>> 
>>      @Override
>> diff -r d254a5f9b93f
>> test/java/lang/reflect/Method/GenericStringTest.java
>> --- a/test/java/lang/reflect/Method/GenericStringTest.java    Wed Mar 27
>> 13:40:26 2013 -0400
>> +++ b/test/java/lang/reflect/Method/GenericStringTest.java    Thu Mar 28
>> 00:02:06 2013 -0700
>> @@ -23,7 +23,7 @@
>> 
>>  /*
>>   * @test
>> - * @bug 5033583 6316717 6470106
>> + * @bug 5033583 6316717 6470106 8004979
>>   * @summary Check toGenericString() and toString() methods
>>   * @author Joseph D. Darcy
>>   */
>> @@ -39,6 +39,7 @@
>>          classList.add(TestClass1.class);
>>          classList.add(TestClass2.class);
>>          classList.add(Roebling.class);
>> +        classList.add(TestInterface1.class);
>> 
>> 
>>          for(Class clazz: classList) @@ -129,6 +130,20 @@
>>      void varArg(Object ... arg) {}
>>  }
>> 
>> +interface TestInterface1 {
>> +    @ExpectedGenericString(
>> +   "public default void TestInterface1.foo()")
>> +    @ExpectedString(
>> +   "public default void TestInterface1.foo()")
>> +    public default void foo(){;}
>> +
>> +    @ExpectedString(
>> +   "public default java.lang.Object TestInterface1.bar()")
>> +    @ExpectedGenericString(
>> +   "public default  A TestInterface1.bar()")
>> +    default  A bar(){return null;}
>> +}
>> +
>>  @Retention(RetentionPolicy.RUNTIME)
>>  @interface ExpectedGenericString {
>>      String value();
> 



From fweimer at redhat.com  Thu Mar 28 11:00:08 2013
From: fweimer at redhat.com (Florian Weimer)
Date: Thu, 28 Mar 2013 12:00:08 +0100
Subject: RFR JDK-8003245
In-Reply-To: <24356968-438c-495a-859a-bab0af138c23@default>
References: <24356968-438c-495a-859a-bab0af138c23@default>
Message-ID: <515422B8.1050804@redhat.com>

On 03/27/2013 05:30 PM, John Zavgren wrote:
> Yes, the uninitialized memory will be accessed in some cases, for example:

Okay, in this case, the changes look okay to me (although returning 
structures by value is somewhat unusual, but that's obviously a 
pre-existing issue).

-- 
Florian Weimer / Red Hat Product Security Team


From maurizio.cimadamore at oracle.com  Thu Mar 28 11:40:18 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Thu, 28 Mar 2013 11:40:18 +0000
Subject: hg: jdk8/tl/langtools: 2 new changesets
Message-ID: <20130328114024.08FB148466@hg.openjdk.java.net>

Changeset: 7bebe17ff323
Author:    mcimadamore
Date:      2013-03-28 11:38 +0000
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7bebe17ff323

8010469: Bad assertion in LambdaToMethod
Summary: Add assertion in LambdaToMethod.serializedLambdaName
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java

Changeset: a200d8ccfe47
Author:    mcimadamore
Date:      2013-03-28 11:39 +0000
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a200d8ccfe47

8010490: FindBugs: double assignments in LambdaToMethod.visitIdent
Summary: Remove dead code from LambdaToMethod
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java



From dl at cs.oswego.edu  Thu Mar 28 11:59:21 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Thu, 28 Mar 2013 07:59:21 -0400
Subject: RFR JDK-7143928 : (coll) Optimize for Empty ArrayList and HashMap
In-Reply-To: 
References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com>
	
	<30E35219-D90D-4D71-94FD-45A90F04EE59@oracle.com>
	
Message-ID: <51543099.5070907@cs.oswego.edu>

On 03/27/13 12:17, Martin Buchholz wrote:
> But you can support any requested initial size if stored in the size field
> when list is empty.

In other words: Mike, please do not add a field if your goal is
to save space! Also, I hope you or the performance testing folks
have extensive and accurate enough tests to show that the change
not only helps the empty case but does not hurt the vastly more
common non-empty case. Considering that this is the most
commonly used java.util class, there should be empirical
evidence that this is a net improvement.
My guess is that it can be done (we did something similar for
ConcurrentHashMap) but it takes  a lot of care.

-Doug


>
>
> On Wed, Mar 27, 2013 at 8:02 AM, Mike Duigou  wrote:
>
>> This seems like a good idea. I will follow up with the performance people
>> to see if their findings include the requested initial size.
>>
>> Mike
>>
>> On Mar 26 2013, at 22:53 , Brian Goetz wrote:
>>
>>> What percentage of the empty lists are default-sized?  I suspect it is
>> large, in which case we could apply this trick only for the default-sized
>> lists, and eliminate the extra field.
>>>
>>> On Mar 26, 2013, at 5:25 PM, Mike Duigou wrote:
>>>
>>>> Hello all;
>>>>
>>>> This is a review for optimization work that came out of internal
>> analysis of Oracle's Java applications. It's based upon analysis that shows
>> that in large applications as much as 10% of maps and lists are initialized
>> but never receive any entries. A smaller number spend a large proportion of
>> their lifetime empty. We've found similar results across other workloads as
>> well. This patch is not a substitute for pre-sizing your collections and
>> maps--doing so will *always* have better results.
>>>>
>>>> This patch extends HashMap and ArrayList to provide special handling
>> for newly created instances that avoids creating the backing array until
>> needed. There is a very small additional cost for detecting when to inflate
>> the map or list that is measurable in interpreted tests but disappears in
>> JITed code.
>>>>
>>>> http://cr.openjdk.java.net/~mduigou/JDK-7143928/0/webrev/
>>>>
>>>> We expect that should this code prove successful in Java 8 it will be
>> backported to Java 7 updates.
>>>>
>>>> The unit test may appear to be somewhat unrelated. It was created after
>> resolving a bug in an early version of this patch to detect the issue
>> encountered (LinkedHashMap.init() was not being called in readObject() when
>> the map was empty).
>>>>
>>>> Mike
>>>
>>
>>
>



From peter.levart at gmail.com  Thu Mar 28 12:07:30 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 28 Mar 2013 13:07:30 +0100
Subject: RFR JDK-7143928 : (coll) Optimize for Empty ArrayList and HashMap
In-Reply-To: 
References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com>
	
	<30E35219-D90D-4D71-94FD-45A90F04EE59@oracle.com>
	
	
Message-ID: <51543282.4090508@gmail.com>

Hi Mike,

Have you considered the possibility to re-constitute the initial 
capacity from threshold and loadFactor?

Regards, Peter

On 03/27/2013 05:28 PM, Mike Duigou wrote:
> I started looking at crafty reuse of size but found too many direct references to size to attempt getting this right in the current iteration. Reusing size is definitely still available to someone who wants to dive in and prepare an implementation.
>
> Mike
>
> On Mar 27 2013, at 09:17 , Martin Buchholz wrote:
>
>> But you can support any requested initial size if stored in the size field when list is empty.
>>
>>
>> On Wed, Mar 27, 2013 at 8:02 AM, Mike Duigou  wrote:
>> This seems like a good idea. I will follow up with the performance people to see if their findings include the requested initial size.
>>
>> Mike
>>
>> On Mar 26 2013, at 22:53 , Brian Goetz wrote:
>>
>>> What percentage of the empty lists are default-sized?  I suspect it is large, in which case we could apply this trick only for the default-sized lists, and eliminate the extra field.
>>>
>>> On Mar 26, 2013, at 5:25 PM, Mike Duigou wrote:
>>>
>>>> Hello all;
>>>>
>>>> This is a review for optimization work that came out of internal analysis of Oracle's Java applications. It's based upon analysis that shows that in large applications as much as 10% of maps and lists are initialized but never receive any entries. A smaller number spend a large proportion of their lifetime empty. We've found similar results across other workloads as well. This patch is not a substitute for pre-sizing your collections and maps--doing so will *always* have better results.
>>>>
>>>> This patch extends HashMap and ArrayList to provide special handling for newly created instances that avoids creating the backing array until needed. There is a very small additional cost for detecting when to inflate the map or list that is measurable in interpreted tests but disappears in JITed code.
>>>>
>>>> http://cr.openjdk.java.net/~mduigou/JDK-7143928/0/webrev/
>>>>
>>>> We expect that should this code prove successful in Java 8 it will be backported to Java 7 updates.
>>>>
>>>> The unit test may appear to be somewhat unrelated. It was created after resolving a bug in an early version of this patch to detect the issue encountered (LinkedHashMap.init() was not being called in readObject() when the map was empty).
>>>>
>>>> Mike
>>



From weijun.wang at oracle.com  Thu Mar 28 12:28:44 2013
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Thu, 28 Mar 2013 12:28:44 +0000
Subject: hg: jdk8/tl/jdk: 8010125: keytool -importkeystore could create a
	pkcs12 keystore with different storepass and keypass
Message-ID: <20130328122907.EE76A48467@hg.openjdk.java.net>

Changeset: a87fac00915e
Author:    weijun
Date:      2013-03-28 20:27 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a87fac00915e

8010125: keytool -importkeystore could create a pkcs12 keystore with different storepass and keypass
Reviewed-by: vinnie

! src/share/classes/sun/security/tools/keytool/Main.java
! src/share/classes/sun/security/tools/keytool/Resources.java
+ test/sun/security/tools/keytool/p12importks.sh



From bourges.laurent at gmail.com  Thu Mar 28 12:55:08 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Thu, 28 Mar 2013 13:55:08 +0100
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due to
	HashMap leads to Integer allocations (boxing)
In-Reply-To: <515416E9.5090303@gmail.com>
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com> <514B2E8D.8060701@gmail.com>
	<514B92A7.1000305@oracle.com>
	
	<514C2C94.60700@gmail.com>
	
	<514C4E09.3020008@gmail.com> <514C5C8D.1090406@gmail.com>
	<514C859D.1050705@gmail.com> <51503925.1020403@gmail.com>
	<51507BE0.6000502@gmail.com> <51521537.8070905@oracle.com>
	<51532203.1090902@gmail.com> <5153B2C3.4040101@oracle.com>
	
	<515416E9.5090303@gmail.com>
Message-ID: 

My benchmaks are also OK:
run:
-XX:+AggressiveOpts -XX:ClassMetaspaceSize=104857600
-XX:InitialHeapSize=268435456 -XX:MaxHeapSize=268435456
-XX:+PrintCommandLineFlags -XX:-PrintFlagsFinal
-XX:+UseCompressedKlassPointers -XX:+UseCompressedOops -XX:+UseParallelGC
mars 28, 2013 1:53:57 PM test.PlatformLoggerBenchmark 
##############################################################
SEVERE: PlatformLogger started
# Java: 1.8.0-internal-bourgesl_2013_03_19_14_35-b00
#   VM: OpenJDK 64-Bit Server VM 25.0-b22 (mixed mode)
#   OS: Linux 2.6.35.14-106.fc14.x86_64 (amd64)
# CPUs: 4 (virtual)
#
#-------------------------------------------------------------
# isLoggableFinest: run duration:  5 000 ms
#
# Warm up:
#           1 threads, Tavg =      2,94 ns/op (? =   0,00 ns/op) [     2,94]
#           1 threads, Tavg =      2,93 ns/op (? =   0,00 ns/op) [     2,93]
# Measure:
            1 threads, Tavg =      2,93 ns/op (? =   0,00 ns/op) [     2,93]
            2 threads, Tavg =      3,25 ns/op (? =   0,01 ns/op) [
3,24,      3,26]
#

>> java.util.logging enabled

#-------------------------------------------------------------
# isLoggableFinest: run duration:  5 000 ms
#
# Warm up:
#           1 threads, Tavg =      3,24 ns/op (? =   0,00 ns/op) [     3,24]
#           1 threads, Tavg =      3,24 ns/op (? =   0,00 ns/op) [     3,24]
# Measure:
            1 threads, Tavg =      3,23 ns/op (? =   0,00 ns/op) [     3,23]
            2 threads, Tavg =      3,64 ns/op (? =   0,06 ns/op) [
3,58,      3,70]
#
#-------------------------------------------------------------
# END.
##############################################################
BUILD SUCCESSFUL (total time: 40 seconds)


Mandy, could you submit your changeset to the mercurial repository ?

Do you plan to apply the fix on JDK7 updates ?

Regards,
Laurent

2013/3/28 Peter Levart 

>  On 03/28/2013 10:19 AM, Laurent Bourg?s wrote:
>
>    the following method in JavaLoggerProxy also caught my eye:
>>
>>         void doLog(Level level, String msg, Object... params) {
>>             if (!isLoggable(level)) {
>>                 return;
>>             }
>>             // only pass String objects to the j.u.l.Logger which may
>>             // be created by untrusted code
>>             int len = (params != null) ? params.length : 0;
>>             Object[] sparams = new String[len];
>>             for (int i = 0; i < len; i++) {
>>                 sparams [i] = String.valueOf(params[i]);
>>             }
>>             LoggingSupport.log(javaLogger, level.javaLevel, msg, sparams);
>>         }
>>
>> I think this could be improved if the DefaultLoggerProxy.formatMessage()
>> is used instead of turning each parameter into a String. The method could
>> be moved up to abstract LoggerProxy and used in both implementations so
>> that common formatting is applied regardless of back-end used.
>>
>>
>>  Let's do this in a separate clean up as it's better to keep 8010309
>> focus on performance improvement (although we have mixed this bag with some
>> renaming).
>>
>
> I disagree Peter: JUL has its own formatting code: patterns ... and more
> efficient than DefaultLoggerProxy.formatMessage().
>
> The good question relies in the comment: why convert object args into
> String early as JUL can do formatting / conversion?
> What does mean:
>             // only pass String objects to the j.u.l.Logger which may
>             // be created by untrusted code
> ?
> to avoid security issues ?
>
>
> I think so. j.u.logging has a pluggable API and a reference to a
> security-sensitive information could get passed to untrusted code via a
> carelessly written logging statement. The fact that PlatformLogger is
> platform-internal API might give an impression that it is secure. So it
> should be.
>
> I don't know how this formatting actually works in current implementation
> of PlatformLogger delegating to j.u.l.Logger and pre-converting the
> arguments into strings. Isn't formatting in j.u.logging type sensitive?
>
> Regards, Peter
>
>
> Laurent
>
>
>


From tim.bell at oracle.com  Thu Mar 28 14:01:48 2013
From: tim.bell at oracle.com (Tim Bell)
Date: Thu, 28 Mar 2013 07:01:48 -0700
Subject: RFR JDK-8010267 & JDK-8010268 : Makefile maintenance for test
	targets
In-Reply-To: <5153FB4C.2020905@oracle.com>
References: 
	<081944A1-4DBD-4E24-8C7C-355AFD37196B@oracle.com>
	<5153FB4C.2020905@oracle.com>
Message-ID: <51544D4C.9090709@oracle.com>

Mike -

Looks good to me.

Tim

On 03/28/13 01:11, Erik Joelsson wrote:
> Both of these look good to me, but you still need a jdk8 reviewer.
>
> /Erik
>
> On 2013-03-27 17:27, Mike Duigou wrote:
>> I still need a review for both of these changes.
>>
>> Mike
>>
>> On Mar 18 2013, at 22:48 , Mike Duigou wrote:
>>
>>> A two small changes to review:
>>>
>>> If approved I will commit to TL (or someone else can commit to build 
>>> for me)
>>>
>>> Mike
>>>
>>> JDK-8010267 : Add test-clean for cleaning of testoutput directory 
>>> from output directory.
>>>
>>> diff --git a/common/makefiles/Main.gmk b/common/makefiles/Main.gmk
>>> --- a/common/makefiles/Main.gmk
>>> +++ b/common/makefiles/Main.gmk
>>> @@ -191,7 +191,7 @@ source-tips: $(OUTPUT_ROOT)/source_tips
>>>
>>>
>>> # Remove everything, except the output from configure.
>>> -clean: clean-langtools clean-corba clean-jaxp clean-jaxws 
>>> clean-hotspot clean-jdk clean-images clean-overlay-images 
>>> clean-bootcycle-build clean-docs
>>> +clean: clean-langtools clean-corba clean-jaxp clean-jaxws 
>>> clean-hotspot clean-jdk clean-images clean-overlay-images 
>>> clean-bootcycle-build clean-docs clean-test
>>>         @($(CD) $(OUTPUT_ROOT)&&  $(RM) -r tmp source_tips 
>>> build.log* build-trace*.log*)
>>>         @$(ECHO) Cleaned all build artifacts.
>>>
>>> @@ -230,6 +230,8 @@ clean-bootcycle-build:
>>> clean-docs:
>>>         $(call CleanComponent,docs)
>>>         $(call CleanComponent,docstemp)
>>> +clean-test:
>>> +       $(call CleanComponent,testoutput)
>>>
>>> .PHONY: langtools corba jaxp jaxws hotspot jdk images overlay-images 
>>> install
>>> .PHONY: langtools-only corba-only jaxp-only jaxws-only hotspot-only 
>>> jdk-only images-only overlay-images-only install-only
>>>
>>>
>>> JDK-8010268 : Remove dependence upon clean target from 
>>> jdk/test/Makefile prep target
>>>
>>> None of the current users seem to depend upon the clean behaviour of 
>>> "prep"
>>>
>>> diff --git a/test/Makefile b/test/Makefile
>>> --- a/test/Makefile
>>> +++ b/test/Makefile
>>> @@ -336,7 +336,7 @@ all: jdk_default
>>>         @$(ECHO) "Testing completed successfully"
>>>
>>> # Prep for output
>>> -prep: clean
>>> +prep:
>>>         @$(MKDIR) -p $(ABS_TEST_OUTPUT_DIR)
>>>         @$(MKDIR) -p `$(DIRNAME) $(ARCHIVE_BUNDLE)`
>>>
>>>




From mandy.chung at oracle.com  Thu Mar 28 14:49:17 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 28 Mar 2013 07:49:17 -0700
Subject: 8010309 : PlatformLogger: isLoggable performance / waste due
	to HashMap leads to Integer allocations (boxing)
In-Reply-To: <515412F6.9070706@gmail.com>
References: 
	<514B1249.7010207@gmail.com>
	
	<514B1D06.10007@gmail.com> <514B1F38.9070604@oracle.com>
	
	<514B27C5.1020605@gmail.com> <514B2E8D.8060701@gmail.com>
	<514B92A7.1000305@oracle.com>
	
	<514C2C94.60700@gmail.com>
	
	<514C4E09.3020008@gmail.com> <514C5C8D.1090406@gmail.com>
	<514C859D.1050705@gmail.com> <51503925.1020403@gmail.com>
	<51507BE0.6000502@gmail.com> <51521537.8070905@oracle.com>
	<51532203.1090902@gmail.com> <5153B2C3.4040101@oracle.com>
	<515412F6.9070706@gmail.com>
Message-ID: <5154586D.1070802@oracle.com>

Hi Peter, Laurent,

Thanks for the performance run.  I'll push the changeset once I check 
the test result.

On 3/28/2013 2:52 AM, Peter Levart wrote:
>
> ...just a nit! In the test:
>
>     private static void checkPlatformLoggerLevelMapping(Level level) {
>         // map the given level to PlatformLogger.Level of the same 
> name and value
>         PlatformLogger.Level platformLevel = 
> PlatformLogger.Level.valueOf(level.getName());
>         if (platformLevel == null || platformLevel.intValue() != 
> level.intValue()) {
>             throw new RuntimeException("Mismatched level: " + level
>                     + " PlatformLogger.Level" + platformLevel);
>         }
>
> The Level.valueOf(String) is guaranteed to not return null.

That's right.  Will fix it.

Laurent Bourges wrote:
> Maybe you should introduce an explicit variable to make it more obvious:
>         boolean initialize = false; // lazy initialization

I'll check the comments and see how I can make it clearer.  I think it 
is.   I don't think the variable helps (perhaps add a comment next to 
'false').

>
> Do you plan to apply the fix on JDK7 updates ?

I don't have any issue backporting this to jdk7u.  I'll get back to you 
on this one how to coordinate on this once this is baked in jdk8 repo first.

Thanks
Mandy

>
>
>
>
> Regards, Peter
>
>>
>> I have retained the part in webrev.08 that only defines loggerProxy 
>> and javaLoggerProxy.  I don't think the new defaultLoggerProxy 
>> variable is needed.  I prefer to use Class.forName to force load 
>> JavaLoggerProxy class to make very explicit that we don't want the 
>> class be initialized. JavaLoggerProxy. calls 
>> LoggingProxy.parseLevel unconditionally that will throw an 
>> AssertionError if java.util.logging is not available. If 
>> JavaLoggerProxy class is initialized, j.u.logging should be present 
>> and I want to catch error if otherwise.  Also Class.forName will load 
>> its superclass LoggerProxy.
>>
>> As for the PlatformLogger.Level enums, having the members to be 
>> defined in ascending order is fragile.  It'd be more reliable to 
>> specify the value in the constructor so that it can be used as the 
>> isLoggable comparsion in the same way as in the Level implementation.
>>
>> I am running the jdk core regression tests on all platforms and 
>> should have the result by tomorrow.
>>
>> On 3/27/2013 9:44 AM, Peter Levart wrote:
>>> Hi Mandy, Laurent,
>>>
>>> It turns out that the API change (change of type for level parameter 
>>> int -> enum Level) is entirely source-compatible. The tip of JDK8 
>>> (tl repo) builds without a problem. So no-one is currently using 
>>> PlatformLogger.getLevel() method and assigning it to a variable or 
>>> such...
>>>
>>
>> Great thanks.  That is what I expect too.
>>
>>> Here's the webrev for this change:
>>>
>>> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.enumapi.01/index.html
>>>
>>> Besides doing the replacement of type and renaming and removing of 
>>> the unneeded stuff, I also did some re-arrangements:
>>>
>>> - introduced a common abstract superclass for both types of 
>>> LoggerProxys (DefaultLoggerProxy, JavaLoggerProxy), since 
>>> JavaLoggerProxy does not need the fields of DefaultLoggerProxy and 
>>> now both concrete subclasses can be declared final (makes JIT even 
>>> more happy). Also the abstract LoggerProxy could host some common 
>>> logic (see below about formatting)...
>>
>> That's a good idea.
>>
>>> - DefaultLoggerProxy's levelValue/effectiveLevel were given names 
>>> just the opposite of their meaning. I aligned them with terminology 
>>> used in j.u.l.Logger and renamed levelValue to plain level.
>>
>> Swapping these 2 variables makes sense.
>>
>>> - introduced private method 
>>> DefaultLoggerProxy.deriveEffectiveLevel(level) that currently just 
>>> returns defaultLevel (INFO) when given null.
>>
>> Ok.
>>
>>> I think with a little more effort, it could be possible to emulate 
>>> the behaviour of j.u.l.Logger which inherits from 1st parent logger 
>>> that has non-null level assigned. Of course with all the caching and 
>>> invalidation...
>>
>> The only way to change the level to a non-default one is via the 
>> logging configuration and enable logging.  That's why there is no 
>> need for DefaultLoggerProxy to inherit level from its parent logger.  
>> Also there is no parent logger hierarchy maintained in 
>> DefaultLoggerProxy.
>>
>>> - instead of static final DefaultLoggerProxy.defaultStream I created 
>>> a private static method outputStream() that returns System.err. To 
>>> accomodate for the situation when System.err is changed dynamically.
>>
>> Ok.
>>
>>> - fixed the JavaLoggerProxy.isEnabled() method. Original code was:
>>>
>>>   532         boolean isEnabled() {
>>>   533             Object level = LoggingSupport.getLevel(javaLogger);
>>>   534             return level == null || level.equals(levelObjects.get(OFF)) == false;
>>>   535         }
>>>
>>> If 'level' is null then it can be that 1st parent that has a non-nul 
>>> level is "OFF". I think that in such situation all the children that 
>>> don't override the level should be disabled too. The following does 
>>> exactly that:
>>>
>>>   597         boolean isEnabled() {
>>>   598             return LoggingSupport.isLoggable(javaLogger, Level.OFF.javaLevel);
>>>   599         }
>>>
>>
>> That is right.  Good catch.
>>
>>> That's all for 1st rev. Besides the effective level inheritance, the 
>>> following method in JavaLoggerProxy also caught my eye:
>>>
>>>         void doLog(Level level, String msg, Object... params) {
>>>             if (!isLoggable(level)) {
>>>                 return;
>>>             }
>>>             // only pass String objects to the j.u.l.Logger which may
>>>             // be created by untrusted code
>>>             int len = (params != null) ? params.length : 0;
>>>             Object[] sparams = new String[len];
>>>             for (int i = 0; i < len; i++) {
>>>                 sparams [i] = String.valueOf(params[i]);
>>>             }
>>>             LoggingSupport.log(javaLogger, level.javaLevel, msg, 
>>> sparams);
>>>         }
>>>
>>> I think this could be improved if the 
>>> DefaultLoggerProxy.formatMessage() is used instead of turning each 
>>> parameter into a String. The method could be moved up to abstract 
>>> LoggerProxy and used in both implementations so that common 
>>> formatting is applied regardless of back-end used.
>>>
>>
>> Let's do this in a separate clean up as it's better to keep 8010309 
>> focus on performance improvement (although we have mixed this bag 
>> with some renaming).
>>
>>> The benchmarks still show stable performance:
>>>
>>
>> Great.  Hope we will wrap up tomorrow.
>>
>> thanks for the contribution.
>> Mandy
>>
>>>
>>>
>>> Regards, Peter
>>>
>>>
>>> On 03/26/2013 10:37 PM, Mandy Chung wrote:
>>>> Hi Peter,
>>>>
>>>>> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.08/index.html
>>>> I'm glad that you observe similar performance improvement without 
>>>> the need of method handles.  I reviewed this version and realize 
>>>> that the map from j.u.l.Level object to LevelEnum can be removed 
>>>> entirely.
>>>>
>>>> sun.util.logging.PlatformLogger is an internal API that should only 
>>>> be used by JDK.  The static final int fields representing the level 
>>>> value can be changed to be static final LevelEnum type instead.  I 
>>>> checked the JDK code that uses PlatformLogger and no code will be 
>>>> impacted by the change of the type of these static fields.  So it 
>>>> removes the need to map from an integer value to LevelEnum. Mapping 
>>>> from a j.u.l.Level to LevelEnum is trivial - the name of the 
>>>> LevelEnum is the same as j.u.l.Level (e.g. LevelEnum.FINEST and 
>>>> Level.FINEST), you can call LoggingSupport.getLevelName(javaLevel) 
>>>> to find its name and LevelEnum.valueOf(levelName) returns the 
>>>> LevelEnum instance.  However, this would require more changes - 
>>>> basically the methods taking "int level" as a parameter would be 
>>>> modified to take LevelEnum and getLevel() would return LevelEnum 
>>>> too.  I think it's worth doing this cleanup to get rid of the 
>>>> unnecessary conversion from int -> enum -> j.u.l.Level and vice 
>>>> versa.  I also recommend to rename LevelEnum to Level which is an 
>>>> inner class of PlatformLogger.  What do you think of this 
>>>> alternative to get rid of the map?
>>>>
>>>> Some other comments of your patch:
>>>> - it renames the class JavaLogger to JavaLoggerProxy and the 
>>>> variable from logger to loggerProxy. I'm fine with that.
>>>> - L162: JavaLoggerProxy.init() to force load of the class which 
>>>> leads to separating the initialization of LevelEnum.javaLevel in a 
>>>> new JavaLevel class.  The JavaLevel utility methods are not needed 
>>>> if we change the static final fields to LevelEnum.
>>>>
>>>> Have you tried:
>>>> Class.forName("sun.util.logging.PlatformLogger.JavaLoggerProxy", 
>>>> false, PlatformLogger.getClassLoader());
>>>>
>>>> would this give you the same performance improvement?  If so, you 
>>>> can keep the static initialization in the JavaLoggerProxy class.
>>>>
>>>> Thanks for expanding the PlatformLoggerTest to cover additional 
>>>> test cases.  It's good that you compare the value of the 
>>>> PlatformLogger static final fields with j.u.l.Level.intValue().  
>>>> You now can use the API to compare the LevelEnum with Level rather 
>>>> than reflection. Perhaps you can add the getName() and intValue() 
>>>> methods in LevelEnum class (just a thought).
>>>>
>>>> Mandy
>>>>
>>>>
>>>> On 3/25/13 9:31 AM, Peter Levart wrote:
>>>>> Well, Laurent, Mandy,
>>>>>
>>>>> It turns out that the dispatch speed-up (or lack of slow-down to 
>>>>> be precise) is possible without MethodHandles too. Maybe some VM 
>>>>> guru could shed some light on this, but the following is currently 
>>>>> the fastest variant:
>>>>>
>>>>> http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.08/index.html
>>>>>
>>>>> What I did is a simple "if" deciding between two call-sites, 
>>>>> making sure that each is only dispatching to single class. This 
>>>>> only works, if both classes (LoggerProxy and JavaLoggerProxy) are 
>>>>> loaded in advance, before 1st invocation on any of them is made 
>>>>> (might be that using MethodHandles forced initialization of both 
>>>>> classes beforehand and hence the speed-up). If I don't load 
>>>>> JavaLoggerProxy before warming-up with LoggerProxy, then when 
>>>>> j.u.logging is enabled, speed drops for a factor of almost 4 and 
>>>>> never catches up even after very long time.
>>>>> This pre-loading also helps for a normal single call site dispatch 
>>>>> that dispatches to two distinct classes, but the speed 1st drops 
>>>>> when the class changes, and only catches-up after several billions 
>>>>> of iterations (30s tight loop on i7).
>>>>> Now, because JavaLoggerProxy is initialized early, I had to move 
>>>>> the initialization of j.u.logging.Level objects and mappings to a 
>>>>> separate class "JavaLevel".
>>>>>
>>>>> Here are the benchmark results for this last iteration...
>>>>>
>>>>
>>>
>>
>



From brian.goetz at oracle.com  Thu Mar 28 15:34:23 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 28 Mar 2013 08:34:23 -0700
Subject: hg: jdk8/tl/jdk: 8001642: Add Optional, OptionalDouble,
	OptionalInt, OptionalLong
In-Reply-To: 
References: <20130319231031.7F46B48272@hg.openjdk.java.net>
	
Message-ID: 

> Has the optional classes been verified to serialize/deserialize correctly?
> 
They are not serializable.  
> Finally, are these utilities critical to some other part JDK 8 that they were pushed out now as opposed to JDK 9?
> 
> 
They are part of the libraries being added by JSR-335 / Project Lambda.  There is extensive discussion on Optional on lambda-dev and the JSR 335 EG lists.  




From paul.sandoz at oracle.com  Thu Mar 28 15:59:52 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 28 Mar 2013 16:59:52 +0100
Subject: RFR JDK-8010096 : Initial java.util.Spliterator putback
Message-ID: <09A8DF98-6FF6-452E-8150-E86D9113E580@oracle.com>

Hi,

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010096

Webrev:
http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8010096/webrev/
 
Spec diff:
http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8010096/specdiff/overview-summary.html
 
Relevant JavaDoc generated from lambda repo (required for viewing @apiNote, @implSpec, @implNote declarations):
http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8010096/api/java/

Note: some of the JavaDoc generated from the lambda repo may contain additional methods or specification that is relevant to the stream framework.

--

To enable bulk operations, in parallel, on a data source it is required that such a source efficiently partition itself into smaller parts, where parts are processed concurrently, and each part is traversed sequentially.
 
A new data interface is required that defines the contract for efficient partitioning and traversal.
 
Collections need to implement that new data interface so the JSR-335 stream library can support bulk operations on common collection implementations, such as List/Set and arrays, in addition to other forms of data source e.g. third party collections.

java.util.Spliterator, and primitive specializations of, is the key data interface that enables partitioning and traversal. JSR-335 java.util.stream.Stream instances will be constructed from spliterators.
 
Collection is extended to define the default method spliterator(). Implementations are expected to override this method. The default implementation utilizes the collection's iterator and size to provide a spliterator implementation that permits limited parallism.  Default overriding implementations are also provided for List, Set and SortedSet that support additional properties associated with those collections.
 
Together with Spliterator some implementations are provided for creating Spliterator instances from data sources that are iterators and arrays.

Note: Optimal spliterator implementations for many collection implementations in java.util and java.util.concurrent are present in the lambda repository and will duly make their way into TL after this webrev has been reviewed and pushed.

--

Once this webrev is reviewed and pushed then the Stream API can follow, and then the fun really begins :-)

The class com.sun.tools.jdi/EventSetImpl has been modified but is likely to change when spliterator implementations are pushed. This class cannot decide if it wants to be a List or a Set!! The compiler cannot work out if the default implementation of spliterator() for List or Set should apply. When the concrete collection implementations of spliterator arrive this class will not need to implement spliterator() and will inherit the implementation from ArrayList (implementations on classes always win over default implementations on interfaces).

Unfortunately to build TL with this patch applied requires one also apply:

  http://hg.openjdk.java.net/lambda/lambda/jdk/rev/fbcafacf92ef

Which i suspect was lost in the wash and should have been pushed to TL a while ago. Will follow up with Robert on that one.

A JPRT of TL with both patches applied did not show any abnormal test failures.

Paul.

From martinrb at google.com  Thu Mar 28 16:05:52 2013
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 28 Mar 2013 09:05:52 -0700
Subject: RFR: Optimize StringBuilder.append(null)
In-Reply-To: 
References: 
	<5153826E.6070007@univ-mlv.fr>
	
	
Message-ID: 

I took Laurent's suggestion of renaming count to c, even though the result
looks like a value judgement on a competing programming environment:

        value[c++] = 'n';
        value[c++] = 'u';
        value[c++] = 'l';
        value[c++] = 'l';



On Wed, Mar 27, 2013 at 11:42 PM, Laurent Bourg?s  wrote:

> Maybe the local var count could be renamed _count or c to avoid name
> conflict with the member count and make the code more readable / obvious.
>
>
>


From joe.darcy at oracle.com  Thu Mar 28 16:18:59 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 28 Mar 2013 09:18:59 -0700
Subject: JDK 8 code review request for JDK-8004979
	java.lang.reflect.Modifier.toString should include "default"
In-Reply-To: <460C56FD-8308-4F27-8244-4D311E28ACB4@oracle.com>
References: <5153EB26.7010605@oracle.com>
	
	<460C56FD-8308-4F27-8244-4D311E28ACB4@oracle.com>
Message-ID: <51546D73.70606@oracle.com>

Hi Jeroen and Joel,

Static methods on interfaces and *not* default methods and that 
distinction is made my the changeset Joel references. The changeset is 
not in the master repository yet, but should be there soon.

Thanks,

-Joe

On 03/28/2013 03:55 AM, Joel Borggr?n-Franck wrote:
> Hi Jeroen,
>
> See http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf0049037deb
>
> I'm not sure if this is in a promoted build yet.
>
> cheers
> /Joel
>
> On 28 mar 2013, at 11:38, Jeroen Frijters  wrote:
>
>> Hi Joe,
>>
>> I notice that Method.isDefault() returns true for static interface methods. I assume that is not correct.
>>
>> Regards,
>> Jeroen
>>
>>> -----Original Message-----
>>> From: core-libs-dev-bounces at openjdk.java.net [mailto:core-libs-dev-
>>> bounces at openjdk.java.net] On Behalf Of Joe Darcy
>>> Sent: Thursday, March 28, 2013 8:03
>>> To: Core-Libs-Dev
>>> Subject: JDK 8 code review request for JDK-8004979
>>> java.lang.reflect.Modifier.toString should include "default"
>>>
>>> Hello,
>>>
>>> Please review these changes to add support for the "default" modifier to
>>> the output of Method.to[Generic]String:
>>>
>>>      8004979 java.lang.reflect.Modifier.toString should include
>>> "default"
>>>      http://cr.openjdk.java.net/~darcy/8004979.0/
>>>
>>> Patch also included below.
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>> diff -r d254a5f9b93f
>>> src/share/classes/java/lang/reflect/Constructor.java
>>> --- a/src/share/classes/java/lang/reflect/Constructor.java    Wed Mar 27
>>> 13:40:26 2013 -0400
>>> +++ b/src/share/classes/java/lang/reflect/Constructor.java    Thu Mar 28
>>> 00:02:06 2013 -0700
>>> @@ -284,9 +284,13 @@
>>>        * modifiers {@code public}, {@code protected} or
>>>        * {@code private}.  Only one of these may appear, or none if the
>>>        * constructor has default (package) access.
>>> +     *
>>> +     * @return a string describing this {@code Constructor}
>>> +     * @jls 8.8.3. Constructor Modifiers
>>>        */
>>>       public String toString() {
>>>           return sharedToString(Modifier.constructorModifiers(),
>>> +                              false,
>>>                                 parameterTypes,
>>>                                 exceptionTypes);
>>>       }
>>> @@ -328,10 +332,11 @@
>>>        * include type parameters
>>>        *
>>>        * @since 1.5
>>> +     * @jls 8.8.3. Constructor Modifiers
>>>        */
>>>       @Override
>>>       public String toGenericString() {
>>> -        return sharedToGenericString(Modifier.constructorModifiers());
>>> +        return sharedToGenericString(Modifier.constructorModifiers(),
>>> false);
>>>       }
>>>
>>>       @Override
>>> diff -r d254a5f9b93f src/share/classes/java/lang/reflect/Executable.java
>>> --- a/src/share/classes/java/lang/reflect/Executable.java    Wed Mar 27
>>> 13:40:26 2013 -0400
>>> +++ b/src/share/classes/java/lang/reflect/Executable.java    Thu Mar 28
>>> 00:02:06 2013 -0700
>>> @@ -89,20 +89,24 @@
>>>
>>>       }
>>>
>>> -    void printModifiersIfNonzero(StringBuilder sb, int mask) {
>>> +    void printModifiersIfNonzero(StringBuilder sb, int mask, boolean
>>> isDefault) {
>>>           int mod = getModifiers() & mask;
>>>           if (mod != 0) {
>>>               sb.append(Modifier.toString(mod)).append(' ');
>>>           }
>>> +        if (isDefault) {
>>> +            sb.append("default ");
>>> +        }
>>>       }
>>>
>>>       String sharedToString(int modifierMask,
>>> +                          boolean isDefault,
>>>                             Class[] parameterTypes,
>>>                             Class[] exceptionTypes) {
>>>           try {
>>>               StringBuilder sb = new StringBuilder();
>>>
>>> -            printModifiersIfNonzero(sb, modifierMask);
>>> +            printModifiersIfNonzero(sb, modifierMask, isDefault);
>>>               specificToStringHeader(sb);
>>>
>>>               sb.append('(');
>>> @@ -124,11 +128,11 @@
>>>        */
>>>       abstract void specificToStringHeader(StringBuilder sb);
>>>
>>> -    String sharedToGenericString(int modifierMask) {
>>> +    String sharedToGenericString(int modifierMask, boolean isDefault) {
>>>           try {
>>>               StringBuilder sb = new StringBuilder();
>>>
>>> -            printModifiersIfNonzero(sb, modifierMask);
>>> +            printModifiersIfNonzero(sb, modifierMask, isDefault);
>>>
>>>               TypeVariable[] typeparms = getTypeParameters();
>>>               if (typeparms.length > 0) { diff -r d254a5f9b93f
>>> src/share/classes/java/lang/reflect/Field.java
>>> --- a/src/share/classes/java/lang/reflect/Field.java    Wed Mar 27
>>> 13:40:26 2013 -0400
>>> +++ b/src/share/classes/java/lang/reflect/Field.java    Thu Mar 28
>>> 00:02:06 2013 -0700
>>> @@ -288,6 +288,9 @@
>>>        * {@code protected} or {@code private} first, and then other
>>>        * modifiers in the following order: {@code static}, {@code
>>> final},
>>>        * {@code transient}, {@code volatile}.
>>> +     *
>>> +     * @return a string describing this {@code Field}
>>> +     * @jls 8.3.1 Field Modifiers
>>>        */
>>>       public String toString() {
>>>           int mod = getModifiers();
>>> @@ -315,6 +318,7 @@
>>>        * its generic type
>>>        *
>>>        * @since 1.5
>>> +     * @jls 8.3.1 Field Modifiers
>>>        */
>>>       public String toGenericString() {
>>>           int mod = getModifiers();
>>> diff -r d254a5f9b93f src/share/classes/java/lang/reflect/Method.java
>>> --- a/src/share/classes/java/lang/reflect/Method.java    Wed Mar 27
>>> 13:40:26 2013 -0400
>>> +++ b/src/share/classes/java/lang/reflect/Method.java    Thu Mar 28
>>> 00:02:06 2013 -0700
>>> @@ -343,10 +343,16 @@
>>>        * {@code public}, {@code protected} or {@code private} first,
>>>        * and then other modifiers in the following order:
>>>        * {@code abstract}, {@code static}, {@code final},
>>> -     * {@code synchronized}, {@code native}, {@code strictfp}.
>>> +     * {@code synchronized}, {@code native}, {@code strictfp},
>>> +     * {@code default}.
>>> +     *
>>> +     * @return a string describing this {@code Method}
>>> +     *
>>> +     * @jls 8.4.3 Method Modifiers
>>>        */
>>>       public String toString() {
>>>           return sharedToString(Modifier.methodModifiers(),
>>> +                              isDefault(),
>>>                                 parameterTypes,
>>>                                 exceptionTypes);
>>>       }
>>> @@ -389,16 +395,19 @@
>>>        * {@code public}, {@code protected} or {@code private} first,
>>>        * and then other modifiers in the following order:
>>>        * {@code abstract}, {@code static}, {@code final},
>>> -     * {@code synchronized}, {@code native}, {@code strictfp}.
>>> +     * {@code synchronized}, {@code native}, {@code strictfp},
>>> +     * {@code default}.
>>>        *
>>>        * @return a string describing this {@code Method},
>>>        * include type parameters
>>>        *
>>>        * @since 1.5
>>> +     *
>>> +     * @jls 8.4.3 Method Modifiers
>>>        */
>>>       @Override
>>>       public String toGenericString() {
>>> -        return sharedToGenericString(Modifier.methodModifiers());
>>> +        return sharedToGenericString(Modifier.methodModifiers(),
>>> isDefault());
>>>       }
>>>
>>>       @Override
>>> diff -r d254a5f9b93f
>>> test/java/lang/reflect/Method/GenericStringTest.java
>>> --- a/test/java/lang/reflect/Method/GenericStringTest.java    Wed Mar 27
>>> 13:40:26 2013 -0400
>>> +++ b/test/java/lang/reflect/Method/GenericStringTest.java    Thu Mar 28
>>> 00:02:06 2013 -0700
>>> @@ -23,7 +23,7 @@
>>>
>>>   /*
>>>    * @test
>>> - * @bug 5033583 6316717 6470106
>>> + * @bug 5033583 6316717 6470106 8004979
>>>    * @summary Check toGenericString() and toString() methods
>>>    * @author Joseph D. Darcy
>>>    */
>>> @@ -39,6 +39,7 @@
>>>           classList.add(TestClass1.class);
>>>           classList.add(TestClass2.class);
>>>           classList.add(Roebling.class);
>>> +        classList.add(TestInterface1.class);
>>>
>>>
>>>           for(Class clazz: classList) @@ -129,6 +130,20 @@
>>>       void varArg(Object ... arg) {}
>>>   }
>>>
>>> +interface TestInterface1 {
>>> +    @ExpectedGenericString(
>>> +   "public default void TestInterface1.foo()")
>>> +    @ExpectedString(
>>> +   "public default void TestInterface1.foo()")
>>> +    public default void foo(){;}
>>> +
>>> +    @ExpectedString(
>>> +   "public default java.lang.Object TestInterface1.bar()")
>>> +    @ExpectedGenericString(
>>> +   "public default  A TestInterface1.bar()")
>>> +    default  A bar(){return null;}
>>> +}
>>> +
>>>   @Retention(RetentionPolicy.RUNTIME)
>>>   @interface ExpectedGenericString {
>>>       String value();



From mike.duigou at oracle.com  Thu Mar 28 17:38:44 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 28 Mar 2013 10:38:44 -0700
Subject: RFR JDK-7143928 : (coll) Optimize for Empty ArrayList and HashMap
In-Reply-To: <51543099.5070907@cs.oswego.edu>
References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com>
	
	<30E35219-D90D-4D71-94FD-45A90F04EE59@oracle.com>
	
	<51543099.5070907@cs.oswego.edu>
Message-ID: <05339A88-8D24-4BF2-BAAF-845973640901@oracle.com>

We have heard back from the performance folks that 85% of empty lists are created at default size. The proposed patch is going to be revised to do the inflation trick only for default sized maps which will eliminate the need for a new field. Something creative involving the use of the existing size field can certainly be considered for a future optimization.


On Mar 28 2013, at 04:59 , Doug Lea wrote:

> On 03/27/13 12:17, Martin Buchholz wrote:
>> But you can support any requested initial size if stored in the size field
>> when list is empty.
> 
> In other words: Mike, please do not add a field if your goal is
> to save space!

Part of the analysis was that with current object layouts the added fields did not change the memory footprint of either class. This, of course only applies to current versions of Hotspot and it's object layout.

> Also, I hope you or the performance testing folks
> have extensive and accurate enough tests to show that the change
> not only helps the empty case but does not hurt the vastly more
> common non-empty case.

They do. I believe that the object layout hides any increase in size.

> Considering that this is the most
> commonly used java.util class, there should be empirical
> evidence that this is a net improvement.

I will try to find how much of the analysis I can share.

> My guess is that it can be done (we did something similar for
> ConcurrentHashMap) but it takes  a lot of care.
> 
> -Doug
> 
> 
>> 
>> 
>> On Wed, Mar 27, 2013 at 8:02 AM, Mike Duigou  wrote:
>> 
>>> This seems like a good idea. I will follow up with the performance people
>>> to see if their findings include the requested initial size.
>>> 
>>> Mike
>>> 
>>> On Mar 26 2013, at 22:53 , Brian Goetz wrote:
>>> 
>>>> What percentage of the empty lists are default-sized?  I suspect it is
>>> large, in which case we could apply this trick only for the default-sized
>>> lists, and eliminate the extra field.
>>>> 
>>>> On Mar 26, 2013, at 5:25 PM, Mike Duigou wrote:
>>>> 
>>>>> Hello all;
>>>>> 
>>>>> This is a review for optimization work that came out of internal
>>> analysis of Oracle's Java applications. It's based upon analysis that shows
>>> that in large applications as much as 10% of maps and lists are initialized
>>> but never receive any entries. A smaller number spend a large proportion of
>>> their lifetime empty. We've found similar results across other workloads as
>>> well. This patch is not a substitute for pre-sizing your collections and
>>> maps--doing so will *always* have better results.
>>>>> 
>>>>> This patch extends HashMap and ArrayList to provide special handling
>>> for newly created instances that avoids creating the backing array until
>>> needed. There is a very small additional cost for detecting when to inflate
>>> the map or list that is measurable in interpreted tests but disappears in
>>> JITed code.
>>>>> 
>>>>> http://cr.openjdk.java.net/~mduigou/JDK-7143928/0/webrev/
>>>>> 
>>>>> We expect that should this code prove successful in Java 8 it will be
>>> backported to Java 7 updates.
>>>>> 
>>>>> The unit test may appear to be somewhat unrelated. It was created after
>>> resolving a bug in an early version of this patch to detect the issue
>>> encountered (LinkedHashMap.init() was not being called in readObject() when
>>> the map was empty).
>>>>> 
>>>>> Mike
>>>> 
>>> 
>>> 
>> 
> 



From jim.gish at oracle.com  Thu Mar 28 17:47:09 2013
From: jim.gish at oracle.com (Jim Gish)
Date: Thu, 28 Mar 2013 13:47:09 -0400
Subject: RFR: Optimize StringBuilder.append(null)
In-Reply-To: 
References: 
	<5153826E.6070007@univ-mlv.fr>
	
	
	
Message-ID: <5154821D.2010909@oracle.com>

Thanks, Martin,

We've all heard of code "smells" -- I hereby dub this a code "chuckle"  :-)

The change looks good to me otherwise as well.

Thanks,
    Jim

On 03/28/2013 12:05 PM, Martin Buchholz wrote:
> I took Laurent's suggestion of renaming count to c, even though the result
> looks like a value judgement on a competing programming environment:
>
>          value[c++] = 'n';
>          value[c++] = 'u';
>          value[c++] = 'l';
>          value[c++] = 'l';
>
>
>
> On Wed, Mar 27, 2013 at 11:42 PM, Laurent Bourg?s > wrote:
>> Maybe the local var count could be renamed _count or c to avoid name
>> conflict with the member count and make the code more readable / obvious.
>>
>>
>>

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From jonathan.gibbons at oracle.com  Thu Mar 28 17:49:57 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 28 Mar 2013 17:49:57 +0000
Subject: hg: jdk8/tl/langtools: 8006346: doclint should make allowance for
	headers generated by standard doclet
Message-ID: <20130328175002.0B94F48470@hg.openjdk.java.net>

Changeset: 991f11e13598
Author:    jjg
Date:      2013-03-28 10:49 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/991f11e13598

8006346: doclint should make allowance for headers generated by standard doclet
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/doclint/Checker.java
! src/share/classes/com/sun/tools/doclint/DocLint.java
! src/share/classes/com/sun/tools/doclint/Env.java
! src/share/classes/com/sun/tools/javac/main/Main.java
! src/share/classes/com/sun/tools/javadoc/DocEnv.java
+ test/tools/javac/doclint/ImplicitHeadersTest.java
+ test/tools/javadoc/doclint/ImplicitHeadersTest.java



From jonathan.gibbons at oracle.com  Thu Mar 28 17:59:01 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 28 Mar 2013 17:59:01 +0000
Subject: hg: jdk8/tl/langtools: 8010511: Tests are creating files in /tmp
Message-ID: <20130328175906.7F55348471@hg.openjdk.java.net>

Changeset: d3648557391b
Author:    jjg
Date:      2013-03-28 10:58 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d3648557391b

8010511: Tests are creating files in /tmp
Reviewed-by: darcy

! test/tools/javac/T6558476.java
! test/tools/javac/T6900149.java
! test/tools/javac/diags/CheckExamples.java
! test/tools/javac/diags/RunExamples.java



From christian.thalinger at oracle.com  Thu Mar 28 18:09:11 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 28 Mar 2013 11:09:11 -0700
Subject: Review request for 7198429: need checked categorization of
	caller-sensitive methods in the JDK
In-Reply-To: <5153B27C.4070806@oracle.com>
References: <51532DF4.9020701@oracle.com>
	<60D0308F-42ED-4C0B-9A9E-BADA73B26F10@oracle.com>
	<5153B27C.4070806@oracle.com>
Message-ID: <0C5DD51E-8B0D-4286-A2B8-71383B3EB20B@oracle.com>


On Mar 27, 2013, at 8:01 PM, Mandy Chung  wrote:

> Thanks for the review.  I forgot to mention that Chris contributed the initial patch (thanks).
> 
> On 3/27/2013 1:13 PM, Christian Thalinger wrote:
>> On Mar 27, 2013, at 10:35 AM, Mandy Chung  wrote:
>> 
>>> This is the JDK change for JEP 176: JEP 176: Mechanical Checking of Caller-Sensitive Methods [1].  Christian has posted the webrev for the hotspot VM change a couple weeks ago [2].
>>> 
>>> Webrev at:
>>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7198429/webrev.00/
>> src/share/classes/java/lang/ClassLoader.java:
>> 
>> +    static void checkClassLoaderPermission(ClassLoader cl, Class caller) {
>> 
>> I think we should rename that method to:
>> 
>> +    static void checkGetClassLoaderPermission(ClassLoader cl, Class caller) {
> 
> I think checkClassLoaderPermission and needsClassLoaderPermissionCheck are just fine.  I'd like to keep it as it is not to make the method name too long.
> 
>> src/share/classes/java/lang/invoke/MethodHandleImpl.java:
>> 
>> +        @sun.reflect.CallerSensitive
>> +            Class actual = sun.reflect.Reflection.getCallerClass();
>> 
>> Why are we not using imports here?
> 
> imports are for convenience and ease of development.  For only one reference,

Well, it's actually two ;-)  I was thinking about people grep'ing for @CallerSensitive and not getting a hit on this one.  Just a suggestion.

> I don't see any difference to import or not.
> 
>> src/share/classes/java/util/logging/Logger.java:
>> 
>>              // 0: Reflection 1: Logger.demandLogger 2: Logger.getLogger 3: caller
>>              final int SKIP_FRAMES = 3;
>> 
>> Please remove these lines as well.
> 
> Removed.  Thanks for catching the leftover comment.
>> src/share/native/sun/reflect/Reflection.c:
>> 
>> Could you put back this comment:
>> 
>> +     // Let's do at least some basic handshaking:
>> +     const int depth = -1;
>> 
>> It makes it clearer why it's -1.
> 
> I added this comment:
>  32     // with the presence of @CallerSensitive annotation,
>  33     // JVM_GetCallerClass asserts depth == -1 as the basic handshaking

Thanks.

> 
>> test/sun/reflect/GetCallerClass.sh:
>> 
>> Could you please don't use a shell script to copy the class file?
> 
> The shell test doesn't do a copy.  It compiles the source file in a separate directory that will be specified in -Xbootclasspath/a option in javac and java commands.
> 
> jtreg in the code-tool repo has added the bootclasspath support:
>    http://hg.openjdk.java.net/code-tools/jtreg/rev/98387c9f36e3
> 
> You can specify in the @run tag:
>    @run main/bootclasspath opt class
> 
> This will be a better way to run a test on the bootclasspath.

That's great.

> 
>> For example this test:
>> 
>> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/file/tip/test/compiler/whitebox/DeoptimizeAllTest.java
>> 
>> does the same thing using a little Java program ClassFileInstaller:
>> 
>> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/file/tip/test/testlibrary/ClassFileInstaller.java
> 
> This is a nice workaround to avoid shell tests.  It compiles the source file in $TESTCLASSES and copies the one in a different location (dest) that will be used in a @run main -Xbootclasspath/a:dest class.
> 
> I prefer to use the new jtreg bootclasspath support when it's released rather than adding yet another workaround to avoid shell tests.   We should replace many, if not all, existing shell tests that currently put classes in the bootclasspath with the jtreg bootclasspath support in one patch.  I keep the test as it is.

I take your word for it that you will remove it.  Checking back in a year... :-)

-- Chris

> 
> Mandy
> 
>> -- Chris
>> 
>>> While it touches many files, the fix is simple and straight-forward for review.
>>> 
>>> This fix annotates all methods that call Reflection.getCallerClass() method with @sun.reflect.CallerSensitive annotation so that it enables the VM to reliably enforce that methods looking up its immediate caller class are marked as caller-sensitive. The JVM will set a new caller-sensitive bit when resolving a MemberName and java.lang.invoke.MethodHandleNatives.isCallerSensitive is upgraded to query it directly.
>>> The hand-maintained method list in MethodHandleNatives is removed.
>>> 
>>> A couple things to mention:
>>> 1. I am working on a fix for 8007035 that proposes to deprecate SecurityManager.checkMemberAccess method as it requires the caller?s frame to be at a stack depth of four, which is fragile and difficult to enforce.
>>> 
>>> 2. NashornScriptEngineFactory.getAppClassLoader()
>>> 
>>> The change is to workaround the issue until 8009783 is resolved.
>>> 
>>> The current implementation walks the stack to find the classloader of the user context that NashornScriptEngine is running on which is fragile.  Also other script engine implementations may require similiar capability.  8009783 has been filed to revisit the scripting API to pass the user "context" to the script engine rather than relying the implementation to find it magically.
>>> 
>>> Thanks
>>> Mandy
>>> 
>>> [1] http://openjdk.java.net/jeps/176
>>> [2] http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008915.html
> 



From martinrb at google.com  Thu Mar 28 18:12:55 2013
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 28 Mar 2013 11:12:55 -0700
Subject: RFR-8008118
In-Reply-To: 
References: 
	<20130327015819.D24BE97129@rebar.astron.com>
	
	
Message-ID: 

My apologies for unrelenting perfectionism - I noticed that we can:
- colocate the pathv and path in one malloc'ed chunk
- can discard xstrdup
- can iterate through path with only one char* pointer.

Making this code even cleaner, more concise and efficient.


http://cr.openjdk.java.net/~martin/webrevs/openjdk8/pathv/


From kevinb at google.com  Thu Mar 28 18:23:45 2013
From: kevinb at google.com (Kevin Bourrillion)
Date: Thu, 28 Mar 2013 11:23:45 -0700
Subject: RFR : JDK-8001642 : Add Optional, OptionalDouble, OptionalInt,
	OptionalLong
In-Reply-To: <513710CC.3010903@univ-mlv.fr>
References: 
	<513710CC.3010903@univ-mlv.fr>
Message-ID: 

I do NOT wish to restart this discussion; I just noticed a falsehood that
was never exposed:


On Wed, Mar 6, 2013 at 1:47 AM, Remi Forax  wrote:

Google's Guava, which is a popular library, defines a class named Optional,
> but allow to store null unlike the current proposed implementation, this
> will generate a lot of confusions and frustrations.
>

Guava's Optional *cannot* be used to hold null. So this particular concern
is not a concern at all.


-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com


From dl at cs.oswego.edu  Thu Mar 28 18:45:44 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Thu, 28 Mar 2013 14:45:44 -0400
Subject: Spliterator flags as enum (was Initial java.util.Spliterator
	putback)
In-Reply-To: 
References: 
Message-ID: <51548FD8.7030103@cs.oswego.edu>

On 03/28/13 13:18, Tim Peierls wrote:
> I can't find a discussion of why Spliterator flags are ints rather than enum.

We started out with enums on (my) initial Spliterator side vs
control flags internal to streams. The we had to somehow
mesh these to work together. On the stream side, you need
to set and unset various bits across stages. Clearly
you can't do that to someone's EnumSet -- they will not expect
you to modify it, but enforcing this makes it both unwieldy and
sleaze-inducing (we'd have to grab underlying representation from
EnumSet).

Another way of saying this is that we needed an efficient
propagate-by-value small-N bit set mechanism, and the only candidate
was the traditional one. This amounts to the same reason
that nio "interest" flags are done the same way.

-Doug







From Lance.Andersen at oracle.com  Thu Mar 28 18:57:06 2013
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Thu, 28 Mar 2013 14:57:06 -0400
Subject: Review request for 7198429: need checked categorization of
	caller-sensitive methods in the JDK
In-Reply-To: <51532DF4.9020701@oracle.com>
References: <51532DF4.9020701@oracle.com>
Message-ID: <20D92FFB-ED94-4989-BB15-5A04FFF6A034@oracle.com>

Hi Mandy

the DriverManager change looks fine.

Best
Lance
On Mar 27, 2013, at 1:35 PM, Mandy Chung wrote:

> This is the JDK change for JEP 176: JEP 176: Mechanical Checking of Caller-Sensitive Methods [1].  Christian has posted the webrev for the hotspot VM change a couple weeks ago [2].
> 
> Webrev at:
> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7198429/webrev.00/
> 
> While it touches many files, the fix is simple and straight-forward for review.
> 
> This fix annotates all methods that call Reflection.getCallerClass() method with @sun.reflect.CallerSensitive annotation so that it enables the VM to reliably enforce that methods looking up its immediate caller class are marked as caller-sensitive. The JVM will set a new caller-sensitive bit when resolving a MemberName and java.lang.invoke.MethodHandleNatives.isCallerSensitive is upgraded to query it directly.
> The hand-maintained method list in MethodHandleNatives is removed.
> 
> A couple things to mention:
> 1. I am working on a fix for 8007035 that proposes to deprecate SecurityManager.checkMemberAccess method as it requires the caller?s frame to be at a stack depth of four, which is fragile and difficult to enforce.
> 
> 2. NashornScriptEngineFactory.getAppClassLoader()
> 
> The change is to workaround the issue until 8009783 is resolved.
> 
> The current implementation walks the stack to find the classloader of the user context that NashornScriptEngine is running on which is fragile.  Also other script engine implementations may require similiar capability.  8009783 has been filed to revisit the scripting API to pass the user "context" to the script engine rather than relying the implementation to find it magically.
> 
> Thanks
> Mandy
> 
> [1] http://openjdk.java.net/jeps/176
> [2] http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008915.html

-------------- next part --------------

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com


From dl at cs.oswego.edu  Thu Mar 28 19:06:17 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Thu, 28 Mar 2013 15:06:17 -0400
Subject: Spliterator flags as enum (was Initial java.util.Spliterator
	putback)
In-Reply-To: 
References: 
	<51548FD8.7030103@cs.oswego.edu>
	
Message-ID: <515494A9.30600@cs.oswego.edu>

On 03/28/13 14:52, Joshua Bloch wrote:
> Doug,
>
> I don't get it. You can set and unset flags on your own EnumSet.  Why isn't that
> sufficient?

There are a lot of problems. First, even
though most spliterators will return the same set of
characteristics each time, you can't just create one static one:

class MySpliterator { ...
   static final EnumSet  cs = EnumSet.of(...);
   EnumSet  characteristics() return cs; }
}

... because you cannot risk that no one will modify.

Second, when inside streams, you'd have to create a new EnumSet
Object across each stage, that somehow secretly extends the
public Characteristics with non-public internal control flags.
Which means either some slow conversion table or grabbing
private EnumSet internals.

So it is both slow and painful. I tried to make it less so,
knowing that people sometimes react hostilely to plain bit
sets. But I'm sure that the current scheme is better than all
I tried. (Ditto for Brian Goetz and Paul Sandoz).
In fact, I think the current scheme is sorta nice in
an absolute sense.

-Doug






>
>
>      Josh
>
> On Thu, Mar 28, 2013 at 11:45 AM, Doug Lea 
 > wrote:
>
>     On 03/28/13 13:18, Tim Peierls wrote:
>
>         I can't find a discussion of why Spliterator flags are ints rather than
>         enum.
>
>
>     We started out with enums on (my) initial Spliterator side vs
>     control flags internal to streams. The we had to somehow
>     mesh these to work together. On the stream side, you need
>     to set and unset various bits across stages. Clearly
>     you can't do that to someone's EnumSet -- they will not expect
>     you to modify it, but enforcing this makes it both unwieldy and
>     sleaze-inducing (we'd have to grab underlying representation from
>     EnumSet).
>
>     Another way of saying this is that we needed an efficient
>     propagate-by-value small-N bit set mechanism, and the only candidate
>     was the traditional one. This amounts to the same reason
>     that nio "interest" flags are done the same way.
>
>     -Doug
>
>
>
>
>
>



From christos at zoulas.com  Thu Mar 28 19:10:27 2013
From: christos at zoulas.com (Christos Zoulas)
Date: Thu, 28 Mar 2013 15:10:27 -0400
Subject: RFR-8008118
In-Reply-To: 
	from Martin Buchholz (Mar 28, 11:12am)
Message-ID: <20130328191027.22BC597129@rebar.astron.com>

On Mar 28, 11:12am, martinrb at google.com (Martin Buchholz) wrote:
-- Subject: Re: RFR-8008118

| My apologies for unrelenting perfectionism - I noticed that we can:
| - colocate the pathv and path in one malloc'ed chunk
| - can discard xstrdup
| - can iterate through path with only one char* pointer.
| 
| Making this code even cleaner, more concise and efficient.


-    for (i = 0; i < count; i++, p++) {
-        pathv[i] = ((*p == ':') || (*p == '\0')) ? "." : p;
-        while (! ((*p == ':') || (*p == '\0')))
-            p++;
-        *p = '\0';
-     }
-     pathv[count] = NULL;

+     for (i = 0; (pathv[i] = strsep(&p, ":")) != NULL; i++)
+	if (!pathv[i][0])
+		pathv[i] = ".";

christos


From philip.race at oracle.com  Thu Mar 28 19:38:39 2013
From: philip.race at oracle.com (Phil Race)
Date: Thu, 28 Mar 2013 12:38:39 -0700
Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
In-Reply-To: 
References: 
	
	<51506136.4020909@oracle.com> <51508139.9000507@oracle.com>
	
Message-ID: <51549C3F.1020301@oracle.com>

Maintaining a pool of objects might be an appropriate thing for an 
applications,
but its a lot trickier for the platform as the application's usage 
pattern or intent
is largely unknown. Weak references or soft references might be of use but
weak references usually go away even at the next incremental GC and soft
references tend to not go away at all until you run out of heap.

You may well be right that always doubling the array size may be too 
simplistic,
but it would need some analysis of the code and its usage to see how much
better we can do.

 >Apparently, Arrays.fill is always faster (size in 10 ... 10 000) !
 > I suspect hotspot to optimize its code and use native functions, 
isn't it ???

I suppose there is some hotspot magic involved to recognise and 
intrinsify this
method, since the source code looks like a plain old for loop.

-phil.


On 3/26/2013 4:00 AM, Laurent Bourg?s wrote:
> Dear all,
>
> First I joined recently the openJDK contributors, and I plan to fix 
> java2D pisces code in my spare time.
>
> I have a full time job on Aspro2: http://www.jmmc.fr/aspro; it is an 
> application to prepare astronomical observations at VLTI / CHARA and 
> is very used in our community (200 users): it provides scientific 
> computations (observability, model images using complex numbers ...) 
> and zoomable plots thanks to jFreeChart.
>
> Aspro2 is known to be very efficient (computation parallelization) and 
> I am often doing profiling using netbeans profiler or visualVM.
>
> To fix huge memory usages by java2d.pisces, I started implementing an 
> efficient ArrayCache (int[] and float[]) (in thread local to 
> concurrency problems):
> - arrays in sizes between 10 and 10000 (more small arrays used than 
> big ones)
> - resizing support (Arrays.copyOf) without wasting arrays
> - reentrance i.e. many arrays are used at the same time (java2D Pisces 
> stroke / dash creates many segments to render)
> - GC / Heap friendly ie support cache eviction and avoid consuming too 
> much memory
>
> I know object pooling is known to be not efficient with recent VM (GC 
> is better) but I think it is counter productive to create so many 
> int[] arrays in java2d.pisces and let the GC remove such wasted memory.
>
> Does someone have implemented such (open source) array cache 
> (core-libs) ?
> Opinions are welcome (but avoid "trolls").
>
> Moreover, sun.java2d.pisces.Helpers.widenArray() performs a lot of 
> array resizing / copy (Arrays.copyOf) that I want to avoid mostly:
>     // These use a hardcoded factor of 2 for increasing sizes. Perhaps 
> this
>     // should be provided as an argument.
>     static float[] widenArray(float[] in, final int cursize, final int 
> numToAdd) {
>         if (in.length >= cursize + numToAdd) {
>             return in;
>         }
>         return Arrays.copyOf(in, 2 * (cursize + numToAdd));
>     }
>
>     static int[] widenArray(int[] in, final int cursize, final int 
> numToAdd) {
>         if (in.length >= cursize + numToAdd) {
>             return in;
>         }
>         return Arrays.copyOf(in, 2 * (cursize + numToAdd));
>     }
>
> Thanks to Peter Levart, I use its microbench tool 
> (https://github.com/plevart/micro-bench/tree/v2) to benchmark 
> ArrayCache operations... and J2DBench to test java2d performances
>
> What is the fastest way to clear an array (part) ie fill by 0:
> - public static void fill(int[] a, int fromIndex, int toIndex, int val)
> - public static native void arraycopy(Object src,  int  srcPos, Object 
> dest, int destPos, int length);
> - unsafe.setMemory(array, Unsafe.ARRAY_INT_BASE_OFFSET, 512 * 
> SIZEOF_INT, (byte) 0)
>
> Apparently, Arrays.fill is always faster (size in 10 ... 10 000) !
> I suspect hotspot to optimize its code and use native functions, isn't 
> it ???
>
> Benchmarks results:
> >> JVM START: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
> Testing arrays: int[1]...
> #
> # ZeroFill: run duration:  5 000 ms, #of logical CPUS: 4
> #
> # Warm up:
> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal 
> [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =      4,47 ns/op (? =   0,00 ns/op) [     
> 4,47]
> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal 
> [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =      4,40 ns/op (? =   0,00 ns/op) [     
> 4,40]
> # Measure:
> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal 
> [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =      4,43 ns/op (? =   0,00 ns/op) [     
> 4,43]
> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal 
> [OpenJDK 64-Bit Server VM 25.0-b22]
>            2 threads, Tavg =      5,55 ns/op (? =   0,16 ns/op) [     
> 5,40,      5,72]
>
> #
> # FillArraySystemCopy: run duration:  5 000 ms, #of logical CPUS: 4
> #
> # Warm up:
> runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =      6,47 ns/op (? =   0,00 ns/op) [     
> 6,47]
> runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =      6,21 ns/op (? =   0,00 ns/op) [     
> 6,21]
> # Measure:
> runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =      6,19 ns/op (? =   0,00 ns/op) [     
> 6,19]
> runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            2 threads, Tavg =      7,80 ns/op (? =   0,10 ns/op) [     
> 7,90,      7,71]
>
> #
> # FillArrayUnsafe: run duration:  5 000 ms, #of logical CPUS: 4
> #
> # Warm up:
> runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =     26,82 ns/op (? =   0,00 ns/op) [    
> 26,82]
> runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =     23,48 ns/op (? =   0,00 ns/op) [    
> 23,48]
> # Measure:
> runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =     22,42 ns/op (? =   0,00 ns/op) [    
> 22,42]
> runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            2 threads, Tavg =     28,21 ns/op (? =   0,88 ns/op) [    
> 29,11,     27,36]
>
> Testing arrays: int[100]...
> #
> # ZeroFill: run duration:  5 000 ms, #of logical CPUS: 4
> #
> # Warm up:
> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal 
> [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =     16,49 ns/op (? =   0,00 ns/op) [    
> 16,49]
> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal 
> [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =     15,97 ns/op (? =   0,00 ns/op) [    
> 15,97]
> # Measure:
> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal 
> [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =     16,03 ns/op (? =   0,00 ns/op) [    
> 16,03]
> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal 
> [OpenJDK 64-Bit Server VM 25.0-b22]
>            2 threads, Tavg =     19,32 ns/op (? =   0,46 ns/op) [    
> 18,87,     19,80]
>
> #
> # FillArraySystemCopy: run duration:  5 000 ms, #of logical CPUS: 4
> #
> # Warm up:
> runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =     14,51 ns/op (? =   0,00 ns/op) [    
> 14,51]
> runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =     14,17 ns/op (? =   0,00 ns/op) [    
> 14,17]
> # Measure:
> runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =     14,09 ns/op (? =   0,00 ns/op) [    
> 14,09]
> runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            2 threads, Tavg =     31,15 ns/op (? =   4,04 ns/op) [    
> 27,65,     35,67]
>
> #
> # FillArrayUnsafe: run duration:  5 000 ms, #of logical CPUS: 4
> #
> # Warm up:
> runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =     52,32 ns/op (? =   0,00 ns/op) [    
> 52,32]
> runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =     52,82 ns/op (? =   0,00 ns/op) [    
> 52,82]
> # Measure:
> runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =     52,19 ns/op (? =   0,00 ns/op) [    
> 52,19]
> runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            2 threads, Tavg =     70,87 ns/op (? =   0,71 ns/op) [    
> 70,17,     71,59]
>
> Testing arrays: int[10000]...
> #
> # ZeroFill: run duration:  5 000 ms, #of logical CPUS: 4
> #
> # Warm up:
> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal 
> [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =  1 208,64 ns/op (? =   0,00 ns/op) [ 
> 1 208,64]
> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal 
> [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =  1 238,01 ns/op (? =   0,00 ns/op) [ 
> 1 238,01]
> # Measure:
> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal 
> [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =  1 235,81 ns/op (? =   0,00 ns/op) [ 
> 1 235,81]
> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal 
> [OpenJDK 64-Bit Server VM 25.0-b22]
>            2 threads, Tavg =  1 325,11 ns/op (? =   7,01 ns/op) [ 
> 1 332,16,  1 318,14]
>
> #
> # FillArraySystemCopy: run duration:  5 000 ms, #of logical CPUS: 4
> #
> # Warm up:
> runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =  1 930,93 ns/op (? =   0,00 ns/op) [ 
> 1 930,93]
> runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =  2 060,80 ns/op (? =   0,00 ns/op) [ 
> 2 060,80]
> # Measure:
> runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =  2 105,21 ns/op (? =   0,00 ns/op) [ 
> 2 105,21]
> runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            2 threads, Tavg =  2 160,33 ns/op (? =  13,74 ns/op) [ 
> 2 146,68,  2 174,15]
>
> #
> # FillArrayUnsafe: run duration:  5 000 ms, #of logical CPUS: 4
> #
> # Warm up:
> runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =  3 099,50 ns/op (? =   0,00 ns/op) [ 
> 3 099,50]
> runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =  3 041,81 ns/op (? =   0,00 ns/op) [ 
> 3 041,81]
> # Measure:
> runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =  3 068,34 ns/op (? =   0,00 ns/op) [ 
> 3 068,34]
> runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            2 threads, Tavg =  3 296,13 ns/op (? =  34,97 ns/op) [ 
> 3 331,47,  3 261,53]
>
>
> PS: java.awt.geom.Path2D has also memory allocation issues:
>         void needRoom(boolean needMove, int newCoords) {
>             if (needMove && numTypes == 0) {
> throw new IllegalPathStateException("missing initial moveto "+
> "in path definition");
>             }
>             int size = pointTypes.length;
>             if (numTypes >= size) {
> int grow = size;
>                 if (grow > EXPAND_MAX) {
> grow = EXPAND_MAX;
>                 }
> pointTypes = Arrays.copyOf(pointTypes, size+grow);
>             }
>             size = floatCoords.length;
>             if (numCoords + newCoords > size) {
> int grow = size;
>                 if (grow > EXPAND_MAX * 2) {
> grow = EXPAND_MAX * 2;
>                 }
>                 if (grow < newCoords) {
> grow = newCoords;
>                 }
> floatCoords = Arrays.copyOf(floatCoords, size+grow);
>             }
>         }
>
> Best regards,
> Laurent



From daniel.fuchs at oracle.com  Thu Mar 28 19:37:08 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 28 Mar 2013 20:37:08 +0100
Subject: JDK-8010495: Update JAXP NetBeans project - add support for
	generating javadoc
In-Reply-To: <515038DA.3010802@oracle.com>
References: <515038DA.3010802@oracle.com>
Message-ID: <51549BE4.2090102@oracle.com>

Hi,

Please find below a revised patch:



I had oversimplified the changes in project.xml.
It seems you need to declare a source folder of type 'java'
as well as a compilation-unit in order for 'Find Usage' to work
properly in the editor.

I have also restrained the packageset for the javadoc
target as suggested by Joe.

-- daniel


On 3/25/13 12:45 PM, Daniel Fuchs wrote:
> Hi guys,
>
> I'd like to propose a small change to jaxp/build.xml and
> jaxp/nbproject/project.xml - in order to allow editing
> JAXP sources in NetBeans, as well as generating the JAXP
> javadoc for previewing purposes.
>
> I actually stole the javadoc target from
> jdk/make/netbeans/common/shared.xml
>
> The changes are small & targeted at developers.
> There should be no impact on the build process.
>
> Here is the webrev:
>
> http://cr.openjdk.java.net/~dfuchs/JDK-8010495/jdk8/webrev.00/
>
> best regards,
>
> -- daniel



From mandy.chung at oracle.com  Thu Mar 28 20:16:32 2013
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Thu, 28 Mar 2013 20:16:32 +0000
Subject: hg: jdk8/tl/jdk: 8010309: Improve PlatformLogger.isLoggable
	performance by direct mapping from an integer to Level
Message-ID: <20130328201656.E120C48477@hg.openjdk.java.net>

Changeset: e433ed08b733
Author:    mchung
Date:      2013-03-28 13:14 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e433ed08b733

8010309: Improve PlatformLogger.isLoggable performance by direct mapping from an integer to Level
Reviewed-by: mchung
Contributed-by: peter.levart at gmail.com, bourges.laurent at gmail.com

! src/share/classes/sun/util/logging/PlatformLogger.java
! test/sun/util/logging/PlatformLoggerTest.java



From philip.race at oracle.com  Thu Mar 28 20:49:17 2013
From: philip.race at oracle.com (Phil Race)
Date: Thu, 28 Mar 2013 13:49:17 -0700
Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
In-Reply-To: 
References: 
	
	<51506136.4020909@oracle.com> <51508139.9000507@oracle.com>
	
	<51549C3F.1020301@oracle.com>
	
Message-ID: <5154ACCD.5090105@oracle.com>

B'ccing discuss and core-libs as I realise this is mostly spam for those 
lists.


On 3/28/2013 1:40 PM, Andrea Aime wrote:
> On Thu, Mar 28, 2013 at 8:38 PM, Phil Race  > wrote:
>
>     Maintaining a pool of objects might be an appropriate thing for an
>     applications,
>     but its a lot trickier for the platform as the application's usage
>     pattern or intent
>     is largely unknown. Weak references or soft references might be of
>     use but
>     weak references usually go away even at the next incremental GC
>     and soft
>     references tend to not go away at all until you run out of heap.
>
>
> At the same time, the current decision is affecting some applications 
> badly.
> I've seen the same happening for another old java2d bug, where the alpha
> tile is cached and coordinated with JVM synchronized statement that 
> kill scalability in
> server side applications heavily using Java2D (e.g, map servers):
> http://bugs.sun.com/view_bug.do?bug_id=6508591

In fact that bug is not related to pisces, or the issue here.
its in the closed source ductus code which is native, not java.

>
> For these kinds of decisions sometimes it's not possible to find a one 
> size that
> fits all: it would be good if there was some way for the application 
> to plug-in their
> own behavior, ideally with a Graphics2D rendering hint, less ideally 
> with a system
> variable (a JVM can run multiple applications, not all might have the 
> same needs).
>
> Now, I understand that today (java 7 or java 8) one could plug-in 
> their own rasterizer,
> yet writing a rasterizer from scratch is kind of a tall order.

The pluggable interface wasn't so that others could do it, it was just 
so that
JDK could operate with either pisces or ductus.

-phil.

> Being able to get some control on these kind of decisions via hints 
> would be nicer imho.
>
> Cheers
> Andrea



From mike.duigou at oracle.com  Thu Mar 28 22:58:38 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 28 Mar 2013 15:58:38 -0700
Subject: JDK 8 code review request for JDK-8004979
	java.lang.reflect.Modifier.toString should include "default"
In-Reply-To: <5153EB26.7010605@oracle.com>
References: <5153EB26.7010605@oracle.com>
Message-ID: <9D0EC462-1FD9-4764-82E4-33F7190F57FC@oracle.com>

Technically the changes look fine but I am a little concerned by the position of default in the order placement. The emerging practice is to put default first immediately following the access modifier. Counter to this is the correct preference for using the "blessed modifier order". Can we move default to the beginning of the order?

Mike

On Mar 28 2013, at 00:03 , Joe Darcy wrote:

> Hello,
> 
> Please review these changes to add support for the "default" modifier to the output of Method.to[Generic]String:
> 
>    8004979 java.lang.reflect.Modifier.toString should include "default"
>    http://cr.openjdk.java.net/~darcy/8004979.0/
> 
> Patch also included below.
> 
> Thanks,
> 
> -Joe
> 
> diff -r d254a5f9b93f src/share/classes/java/lang/reflect/Constructor.java
> --- a/src/share/classes/java/lang/reflect/Constructor.java    Wed Mar 27 13:40:26 2013 -0400
> +++ b/src/share/classes/java/lang/reflect/Constructor.java    Thu Mar 28 00:02:06 2013 -0700
> @@ -284,9 +284,13 @@
>      * modifiers {@code public}, {@code protected} or
>      * {@code private}.  Only one of these may appear, or none if the
>      * constructor has default (package) access.
> +     *
> +     * @return a string describing this {@code Constructor}
> +     * @jls 8.8.3. Constructor Modifiers
>      */
>     public String toString() {
>         return sharedToString(Modifier.constructorModifiers(),
> +                              false,
>                               parameterTypes,
>                               exceptionTypes);
>     }
> @@ -328,10 +332,11 @@
>      * include type parameters
>      *
>      * @since 1.5
> +     * @jls 8.8.3. Constructor Modifiers
>      */
>     @Override
>     public String toGenericString() {
> -        return sharedToGenericString(Modifier.constructorModifiers());
> +        return sharedToGenericString(Modifier.constructorModifiers(), false);
>     }
> 
>     @Override
> diff -r d254a5f9b93f src/share/classes/java/lang/reflect/Executable.java
> --- a/src/share/classes/java/lang/reflect/Executable.java    Wed Mar 27 13:40:26 2013 -0400
> +++ b/src/share/classes/java/lang/reflect/Executable.java    Thu Mar 28 00:02:06 2013 -0700
> @@ -89,20 +89,24 @@
> 
>     }
> 
> -    void printModifiersIfNonzero(StringBuilder sb, int mask) {
> +    void printModifiersIfNonzero(StringBuilder sb, int mask, boolean isDefault) {
>         int mod = getModifiers() & mask;
>         if (mod != 0) {
>             sb.append(Modifier.toString(mod)).append(' ');
>         }
> +        if (isDefault) {
> +            sb.append("default ");
> +        }
>     }
> 
>     String sharedToString(int modifierMask,
> +                          boolean isDefault,
>                           Class[] parameterTypes,
>                           Class[] exceptionTypes) {
>         try {
>             StringBuilder sb = new StringBuilder();
> 
> -            printModifiersIfNonzero(sb, modifierMask);
> +            printModifiersIfNonzero(sb, modifierMask, isDefault);
>             specificToStringHeader(sb);
> 
>             sb.append('(');
> @@ -124,11 +128,11 @@
>      */
>     abstract void specificToStringHeader(StringBuilder sb);
> 
> -    String sharedToGenericString(int modifierMask) {
> +    String sharedToGenericString(int modifierMask, boolean isDefault) {
>         try {
>             StringBuilder sb = new StringBuilder();
> 
> -            printModifiersIfNonzero(sb, modifierMask);
> +            printModifiersIfNonzero(sb, modifierMask, isDefault);
> 
>             TypeVariable[] typeparms = getTypeParameters();
>             if (typeparms.length > 0) {
> diff -r d254a5f9b93f src/share/classes/java/lang/reflect/Field.java
> --- a/src/share/classes/java/lang/reflect/Field.java    Wed Mar 27 13:40:26 2013 -0400
> +++ b/src/share/classes/java/lang/reflect/Field.java    Thu Mar 28 00:02:06 2013 -0700
> @@ -288,6 +288,9 @@
>      * {@code protected} or {@code private} first, and then other
>      * modifiers in the following order: {@code static}, {@code final},
>      * {@code transient}, {@code volatile}.
> +     *
> +     * @return a string describing this {@code Field}
> +     * @jls 8.3.1 Field Modifiers
>      */
>     public String toString() {
>         int mod = getModifiers();
> @@ -315,6 +318,7 @@
>      * its generic type
>      *
>      * @since 1.5
> +     * @jls 8.3.1 Field Modifiers
>      */
>     public String toGenericString() {
>         int mod = getModifiers();
> diff -r d254a5f9b93f src/share/classes/java/lang/reflect/Method.java
> --- a/src/share/classes/java/lang/reflect/Method.java    Wed Mar 27 13:40:26 2013 -0400
> +++ b/src/share/classes/java/lang/reflect/Method.java    Thu Mar 28 00:02:06 2013 -0700
> @@ -343,10 +343,16 @@
>      * {@code public}, {@code protected} or {@code private} first,
>      * and then other modifiers in the following order:
>      * {@code abstract}, {@code static}, {@code final},
> -     * {@code synchronized}, {@code native}, {@code strictfp}.
> +     * {@code synchronized}, {@code native}, {@code strictfp},
> +     * {@code default}.
> +     *
> +     * @return a string describing this {@code Method}
> +     *
> +     * @jls 8.4.3 Method Modifiers
>      */
>     public String toString() {
>         return sharedToString(Modifier.methodModifiers(),
> +                              isDefault(),
>                               parameterTypes,
>                               exceptionTypes);
>     }
> @@ -389,16 +395,19 @@
>      * {@code public}, {@code protected} or {@code private} first,
>      * and then other modifiers in the following order:
>      * {@code abstract}, {@code static}, {@code final},
> -     * {@code synchronized}, {@code native}, {@code strictfp}.
> +     * {@code synchronized}, {@code native}, {@code strictfp},
> +     * {@code default}.
>      *
>      * @return a string describing this {@code Method},
>      * include type parameters
>      *
>      * @since 1.5
> +     *
> +     * @jls 8.4.3 Method Modifiers
>      */
>     @Override
>     public String toGenericString() {
> -        return sharedToGenericString(Modifier.methodModifiers());
> +        return sharedToGenericString(Modifier.methodModifiers(), isDefault());
>     }
> 
>     @Override
> diff -r d254a5f9b93f test/java/lang/reflect/Method/GenericStringTest.java
> --- a/test/java/lang/reflect/Method/GenericStringTest.java    Wed Mar 27 13:40:26 2013 -0400
> +++ b/test/java/lang/reflect/Method/GenericStringTest.java    Thu Mar 28 00:02:06 2013 -0700
> @@ -23,7 +23,7 @@
> 
> /*
>  * @test
> - * @bug 5033583 6316717 6470106
> + * @bug 5033583 6316717 6470106 8004979
>  * @summary Check toGenericString() and toString() methods
>  * @author Joseph D. Darcy
>  */
> @@ -39,6 +39,7 @@
>         classList.add(TestClass1.class);
>         classList.add(TestClass2.class);
>         classList.add(Roebling.class);
> +        classList.add(TestInterface1.class);
> 
> 
>         for(Class clazz: classList)
> @@ -129,6 +130,20 @@
>     void varArg(Object ... arg) {}
> }
> 
> +interface TestInterface1 {
> +    @ExpectedGenericString(
> +   "public default void TestInterface1.foo()")
> +    @ExpectedString(
> +   "public default void TestInterface1.foo()")
> +    public default void foo(){;}
> +
> +    @ExpectedString(
> +   "public default java.lang.Object TestInterface1.bar()")
> +    @ExpectedGenericString(
> +   "public default  A TestInterface1.bar()")
> +    default  A bar(){return null;}
> +}
> +
> @Retention(RetentionPolicy.RUNTIME)
> @interface ExpectedGenericString {
>     String value();
> 



From vitalyd at gmail.com  Thu Mar 28 23:56:13 2013
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 28 Mar 2013 19:56:13 -0400
Subject: Spliterator flags as enum (was Initial java.util.Spliterator
	putback)
In-Reply-To: 
References: 
	<51548FD8.7030103@cs.oswego.edu>
	
	<515494A9.30600@cs.oswego.edu>
	
Message-ID: 

Enum and EnumSet *are* good, but the problem is the overhead of
representation.  If all you want is 32 bits to play with, you pay exactly 4
bytes in price if using int.  With EnumSet, you pay object/heap overhead -
on x64, 4 bytes vs 24; you pay GC price if you have lots of objects with
embedded EnumSet instances in them, there's indirection in loading/passing
them, etc

Until JVM supports/implements value type/structure semantics, the overhead
for these types of things continues to be an eyebrow raising issue.

Sorry Josh, I know this isn't related to Spliterator directly and you did
say that bit fields are *usually* not a good idea, but just wanted to throw
this out there as more a plea for Oracle to do something about struct/value
type hole. :)

Sent from my phone
On Mar 28, 2013 3:38 PM, "Joshua Bloch"  wrote:

> Doug,
>
> On Thu, Mar 28, 2013 at 12:06 PM, Doug Lea 
 wrote:
>
> > On 03/28/13 14:52, Joshua Bloch wrote:
> >
> >> Doug,
> >>
> >> I don't get it. You can set and unset flags on your own EnumSet.  Why
> >> isn't that
> >> sufficient?
> >>
> >
> > There are a lot of problems. First, even
> > though most spliterators will return the same set of
> > characteristics each time, you can't just create one static one:
> >
> > class MySpliterator { ...
> >   static final EnumSet  cs = EnumSet.of(...);
> >   EnumSet  characteristics() return cs; }
> > }
> >
> > ... because you cannot risk that no one will modify.
> >
>
> Sounds like a perfect opportunity to put in immutableEnumSet, which is
> trivial to implement and generally useful. Alternatively, don't share, and
> see if the performance it good enough.  (I suspect it will be.)
>
> Second, when inside streams, you'd have to create a new EnumSet
> > Object across each stage, that somehow secretly extends the
> > public Characteristics with non-public internal control flags.
> > Which means either some slow conversion table or grabbing
> > private EnumSet internals.
> >
>
> Or having two EnumSets: one public, consisting of public constants, and one
> private, consisting of private constants. Again, doesn't sound like a big
> deal.
>
> So it is both slow and painful.
>
>
> You haven't convinced me of either (yet).  Did you measure the performance?
>
>
> > I tried to make it less so,
> > knowing that people sometimes react hostilely to plain bit
> > sets. But I'm sure that the current scheme is better than all
> > I tried. (Ditto for Brian Goetz and Paul Sandoz).
> > In fact, I think the current scheme is sorta nice in
> > an absolute sense.
>
>
> Could be.  I haven't seen it. That said, I find that bit fields are usually
> not a good idea in the post-enum age.
>
>      Josh
>
>


From martinrb at google.com  Fri Mar 29 00:07:53 2013
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 28 Mar 2013 17:07:53 -0700
Subject: RFR-8008118
In-Reply-To: <20130328191027.22BC597129@rebar.astron.com>
References: 
	<20130328191027.22BC597129@rebar.astron.com>
Message-ID: 

strsep is nice, but not standard enough to use in the JDK.
OTOH, strcspn is already used in the JDK, but doesn't really  buy much:

    for (i = 0; i < count; i++) {
        int len = strcspn(p, ":");
        pathv[i] = (len == 0) ? "." : p;
        p[len] = '\0';
        p += len + 1;
    }



On Thu, Mar 28, 2013 at 12:10 PM, Christos Zoulas wrote:

>
> +     for (i = 0; (pathv[i] = strsep(&p, ":")) != NULL; i++)
> +       if (!pathv[i][0])
> +               pathv[i] = ".";
>
> christos
>


From joe.darcy at oracle.com  Fri Mar 29 00:59:17 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 28 Mar 2013 17:59:17 -0700
Subject: JDK 8 code review request for JDK-8004979
	java.lang.reflect.Modifier.toString should include "default"
In-Reply-To: <9D0EC462-1FD9-4764-82E4-33F7190F57FC@oracle.com>
References: <5153EB26.7010605@oracle.com>
	<9D0EC462-1FD9-4764-82E4-33F7190F57FC@oracle.com>
Message-ID: <5154E765.2010300@oracle.com>

Hi Mike,

Sure; I've checked with the latest lambda draft and changed the code to 
output any default modifier after any public / private / protected 
modifiers. The main change is in the printModifiersIfNonzero method:

     void printModifiersIfNonzero(StringBuilder sb, int mask, boolean 
isDefault) {
         int mod = getModifiers() & mask;

         if (mod != 0 && !isDefault) {
             sb.append(Modifier.toString(mod)).append(' ');
         } else {
             int access_mod = mod & Modifier.ACCESS_MODIFIERS;
             if (access_mod != 0)
                 sb.append(Modifier.toString(access_mod)).append(' ');
             if (isDefault)
                 sb.append("default ");
             mod = (mod & ~Modifier.ACCESS_MODIFIERS);
             if (mod != 0)
                 sb.append(Modifier.toString(mod)).append(' ');
         }
     }

Updated webrev including a "public default strictfp" test case at:

    http://cr.openjdk.java.net/~darcy/8004979.1/

Thanks,

-Joe

On 03/28/2013 03:58 PM, Mike Duigou wrote:
> Technically the changes look fine but I am a little concerned by the position of default in the order placement. The emerging practice is to put default first immediately following the access modifier. Counter to this is the correct preference for using the "blessed modifier order". Can we move default to the beginning of the order?
>
> Mike
>
> On Mar 28 2013, at 00:03 , Joe Darcy wrote:
>
>> Hello,
>>
>> Please review these changes to add support for the "default" modifier to the output of Method.to[Generic]String:
>>
>>     8004979 java.lang.reflect.Modifier.toString should include "default"
>>     http://cr.openjdk.java.net/~darcy/8004979.0/
>>
>> Patch also included below.
>>
>> Thanks,
>>
>> -Joe
>>
>> diff -r d254a5f9b93f src/share/classes/java/lang/reflect/Constructor.java
>> --- a/src/share/classes/java/lang/reflect/Constructor.java    Wed Mar 27 13:40:26 2013 -0400
>> +++ b/src/share/classes/java/lang/reflect/Constructor.java    Thu Mar 28 00:02:06 2013 -0700
>> @@ -284,9 +284,13 @@
>>       * modifiers {@code public}, {@code protected} or
>>       * {@code private}.  Only one of these may appear, or none if the
>>       * constructor has default (package) access.
>> +     *
>> +     * @return a string describing this {@code Constructor}
>> +     * @jls 8.8.3. Constructor Modifiers
>>       */
>>      public String toString() {
>>          return sharedToString(Modifier.constructorModifiers(),
>> +                              false,
>>                                parameterTypes,
>>                                exceptionTypes);
>>      }
>> @@ -328,10 +332,11 @@
>>       * include type parameters
>>       *
>>       * @since 1.5
>> +     * @jls 8.8.3. Constructor Modifiers
>>       */
>>      @Override
>>      public String toGenericString() {
>> -        return sharedToGenericString(Modifier.constructorModifiers());
>> +        return sharedToGenericString(Modifier.constructorModifiers(), false);
>>      }
>>
>>      @Override
>> diff -r d254a5f9b93f src/share/classes/java/lang/reflect/Executable.java
>> --- a/src/share/classes/java/lang/reflect/Executable.java    Wed Mar 27 13:40:26 2013 -0400
>> +++ b/src/share/classes/java/lang/reflect/Executable.java    Thu Mar 28 00:02:06 2013 -0700
>> @@ -89,20 +89,24 @@
>>
>>      }
>>
>> -    void printModifiersIfNonzero(StringBuilder sb, int mask) {
>> +    void printModifiersIfNonzero(StringBuilder sb, int mask, boolean isDefault) {
>>          int mod = getModifiers() & mask;
>>          if (mod != 0) {
>>              sb.append(Modifier.toString(mod)).append(' ');
>>          }
>> +        if (isDefault) {
>> +            sb.append("default ");
>> +        }
>>      }
>>
>>      String sharedToString(int modifierMask,
>> +                          boolean isDefault,
>>                            Class[] parameterTypes,
>>                            Class[] exceptionTypes) {
>>          try {
>>              StringBuilder sb = new StringBuilder();
>>
>> -            printModifiersIfNonzero(sb, modifierMask);
>> +            printModifiersIfNonzero(sb, modifierMask, isDefault);
>>              specificToStringHeader(sb);
>>
>>              sb.append('(');
>> @@ -124,11 +128,11 @@
>>       */
>>      abstract void specificToStringHeader(StringBuilder sb);
>>
>> -    String sharedToGenericString(int modifierMask) {
>> +    String sharedToGenericString(int modifierMask, boolean isDefault) {
>>          try {
>>              StringBuilder sb = new StringBuilder();
>>
>> -            printModifiersIfNonzero(sb, modifierMask);
>> +            printModifiersIfNonzero(sb, modifierMask, isDefault);
>>
>>              TypeVariable[] typeparms = getTypeParameters();
>>              if (typeparms.length > 0) {
>> diff -r d254a5f9b93f src/share/classes/java/lang/reflect/Field.java
>> --- a/src/share/classes/java/lang/reflect/Field.java    Wed Mar 27 13:40:26 2013 -0400
>> +++ b/src/share/classes/java/lang/reflect/Field.java    Thu Mar 28 00:02:06 2013 -0700
>> @@ -288,6 +288,9 @@
>>       * {@code protected} or {@code private} first, and then other
>>       * modifiers in the following order: {@code static}, {@code final},
>>       * {@code transient}, {@code volatile}.
>> +     *
>> +     * @return a string describing this {@code Field}
>> +     * @jls 8.3.1 Field Modifiers
>>       */
>>      public String toString() {
>>          int mod = getModifiers();
>> @@ -315,6 +318,7 @@
>>       * its generic type
>>       *
>>       * @since 1.5
>> +     * @jls 8.3.1 Field Modifiers
>>       */
>>      public String toGenericString() {
>>          int mod = getModifiers();
>> diff -r d254a5f9b93f src/share/classes/java/lang/reflect/Method.java
>> --- a/src/share/classes/java/lang/reflect/Method.java    Wed Mar 27 13:40:26 2013 -0400
>> +++ b/src/share/classes/java/lang/reflect/Method.java    Thu Mar 28 00:02:06 2013 -0700
>> @@ -343,10 +343,16 @@
>>       * {@code public}, {@code protected} or {@code private} first,
>>       * and then other modifiers in the following order:
>>       * {@code abstract}, {@code static}, {@code final},
>> -     * {@code synchronized}, {@code native}, {@code strictfp}.
>> +     * {@code synchronized}, {@code native}, {@code strictfp},
>> +     * {@code default}.
>> +     *
>> +     * @return a string describing this {@code Method}
>> +     *
>> +     * @jls 8.4.3 Method Modifiers
>>       */
>>      public String toString() {
>>          return sharedToString(Modifier.methodModifiers(),
>> +                              isDefault(),
>>                                parameterTypes,
>>                                exceptionTypes);
>>      }
>> @@ -389,16 +395,19 @@
>>       * {@code public}, {@code protected} or {@code private} first,
>>       * and then other modifiers in the following order:
>>       * {@code abstract}, {@code static}, {@code final},
>> -     * {@code synchronized}, {@code native}, {@code strictfp}.
>> +     * {@code synchronized}, {@code native}, {@code strictfp},
>> +     * {@code default}.
>>       *
>>       * @return a string describing this {@code Method},
>>       * include type parameters
>>       *
>>       * @since 1.5
>> +     *
>> +     * @jls 8.4.3 Method Modifiers
>>       */
>>      @Override
>>      public String toGenericString() {
>> -        return sharedToGenericString(Modifier.methodModifiers());
>> +        return sharedToGenericString(Modifier.methodModifiers(), isDefault());
>>      }
>>
>>      @Override
>> diff -r d254a5f9b93f test/java/lang/reflect/Method/GenericStringTest.java
>> --- a/test/java/lang/reflect/Method/GenericStringTest.java    Wed Mar 27 13:40:26 2013 -0400
>> +++ b/test/java/lang/reflect/Method/GenericStringTest.java    Thu Mar 28 00:02:06 2013 -0700
>> @@ -23,7 +23,7 @@
>>
>> /*
>>   * @test
>> - * @bug 5033583 6316717 6470106
>> + * @bug 5033583 6316717 6470106 8004979
>>   * @summary Check toGenericString() and toString() methods
>>   * @author Joseph D. Darcy
>>   */
>> @@ -39,6 +39,7 @@
>>          classList.add(TestClass1.class);
>>          classList.add(TestClass2.class);
>>          classList.add(Roebling.class);
>> +        classList.add(TestInterface1.class);
>>
>>
>>          for(Class clazz: classList)
>> @@ -129,6 +130,20 @@
>>      void varArg(Object ... arg) {}
>> }
>>
>> +interface TestInterface1 {
>> +    @ExpectedGenericString(
>> +   "public default void TestInterface1.foo()")
>> +    @ExpectedString(
>> +   "public default void TestInterface1.foo()")
>> +    public default void foo(){;}
>> +
>> +    @ExpectedString(
>> +   "public default java.lang.Object TestInterface1.bar()")
>> +    @ExpectedGenericString(
>> +   "public default  A TestInterface1.bar()")
>> +    default  A bar(){return null;}
>> +}
>> +
>> @Retention(RetentionPolicy.RUNTIME)
>> @interface ExpectedGenericString {
>>      String value();
>>



From mike.duigou at oracle.com  Fri Mar 29 01:02:37 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 28 Mar 2013 18:02:37 -0700
Subject: JDK 8 code review request for JDK-8004979
	java.lang.reflect.Modifier.toString should include "default"
In-Reply-To: <5154E765.2010300@oracle.com>
References: <5153EB26.7010605@oracle.com>
	<9D0EC462-1FD9-4764-82E4-33F7190F57FC@oracle.com>
	<5154E765.2010300@oracle.com>
Message-ID: <1545A7F5-9ADA-423D-B36C-FDFD42639EE7@oracle.com>

Thanks for making the change. It looks good to me.

Mike

On Mar 28 2013, at 17:59 , Joe Darcy wrote:

> Hi Mike,
> 
> Sure; I've checked with the latest lambda draft and changed the code to output any default modifier after any public / private / protected modifiers. The main change is in the printModifiersIfNonzero method:
> 
>    void printModifiersIfNonzero(StringBuilder sb, int mask, boolean isDefault) {
>        int mod = getModifiers() & mask;
> 
>        if (mod != 0 && !isDefault) {
>            sb.append(Modifier.toString(mod)).append(' ');
>        } else {
>            int access_mod = mod & Modifier.ACCESS_MODIFIERS;
>            if (access_mod != 0)
>                sb.append(Modifier.toString(access_mod)).append(' ');
>            if (isDefault)
>                sb.append("default ");
>            mod = (mod & ~Modifier.ACCESS_MODIFIERS);
>            if (mod != 0)
>                sb.append(Modifier.toString(mod)).append(' ');
>        }
>    }
> 
> Updated webrev including a "public default strictfp" test case at:
> 
>   http://cr.openjdk.java.net/~darcy/8004979.1/
> 
> Thanks,
> 
> -Joe
> 
> On 03/28/2013 03:58 PM, Mike Duigou wrote:
>> Technically the changes look fine but I am a little concerned by the position of default in the order placement. The emerging practice is to put default first immediately following the access modifier. Counter to this is the correct preference for using the "blessed modifier order". Can we move default to the beginning of the order?
>> 
>> Mike
>> 
>> On Mar 28 2013, at 00:03 , Joe Darcy wrote:
>> 
>>> Hello,
>>> 
>>> Please review these changes to add support for the "default" modifier to the output of Method.to[Generic]String:
>>> 
>>>    8004979 java.lang.reflect.Modifier.toString should include "default"
>>>    http://cr.openjdk.java.net/~darcy/8004979.0/
>>> 
>>> Patch also included below.
>>> 
>>> Thanks,
>>> 
>>> -Joe
>>> 
>>> diff -r d254a5f9b93f src/share/classes/java/lang/reflect/Constructor.java
>>> --- a/src/share/classes/java/lang/reflect/Constructor.java    Wed Mar 27 13:40:26 2013 -0400
>>> +++ b/src/share/classes/java/lang/reflect/Constructor.java    Thu Mar 28 00:02:06 2013 -0700
>>> @@ -284,9 +284,13 @@
>>>      * modifiers {@code public}, {@code protected} or
>>>      * {@code private}.  Only one of these may appear, or none if the
>>>      * constructor has default (package) access.
>>> +     *
>>> +     * @return a string describing this {@code Constructor}
>>> +     * @jls 8.8.3. Constructor Modifiers
>>>      */
>>>     public String toString() {
>>>         return sharedToString(Modifier.constructorModifiers(),
>>> +                              false,
>>>                               parameterTypes,
>>>                               exceptionTypes);
>>>     }
>>> @@ -328,10 +332,11 @@
>>>      * include type parameters
>>>      *
>>>      * @since 1.5
>>> +     * @jls 8.8.3. Constructor Modifiers
>>>      */
>>>     @Override
>>>     public String toGenericString() {
>>> -        return sharedToGenericString(Modifier.constructorModifiers());
>>> +        return sharedToGenericString(Modifier.constructorModifiers(), false);
>>>     }
>>> 
>>>     @Override
>>> diff -r d254a5f9b93f src/share/classes/java/lang/reflect/Executable.java
>>> --- a/src/share/classes/java/lang/reflect/Executable.java    Wed Mar 27 13:40:26 2013 -0400
>>> +++ b/src/share/classes/java/lang/reflect/Executable.java    Thu Mar 28 00:02:06 2013 -0700
>>> @@ -89,20 +89,24 @@
>>> 
>>>     }
>>> 
>>> -    void printModifiersIfNonzero(StringBuilder sb, int mask) {
>>> +    void printModifiersIfNonzero(StringBuilder sb, int mask, boolean isDefault) {
>>>         int mod = getModifiers() & mask;
>>>         if (mod != 0) {
>>>             sb.append(Modifier.toString(mod)).append(' ');
>>>         }
>>> +        if (isDefault) {
>>> +            sb.append("default ");
>>> +        }
>>>     }
>>> 
>>>     String sharedToString(int modifierMask,
>>> +                          boolean isDefault,
>>>                           Class[] parameterTypes,
>>>                           Class[] exceptionTypes) {
>>>         try {
>>>             StringBuilder sb = new StringBuilder();
>>> 
>>> -            printModifiersIfNonzero(sb, modifierMask);
>>> +            printModifiersIfNonzero(sb, modifierMask, isDefault);
>>>             specificToStringHeader(sb);
>>> 
>>>             sb.append('(');
>>> @@ -124,11 +128,11 @@
>>>      */
>>>     abstract void specificToStringHeader(StringBuilder sb);
>>> 
>>> -    String sharedToGenericString(int modifierMask) {
>>> +    String sharedToGenericString(int modifierMask, boolean isDefault) {
>>>         try {
>>>             StringBuilder sb = new StringBuilder();
>>> 
>>> -            printModifiersIfNonzero(sb, modifierMask);
>>> +            printModifiersIfNonzero(sb, modifierMask, isDefault);
>>> 
>>>             TypeVariable[] typeparms = getTypeParameters();
>>>             if (typeparms.length > 0) {
>>> diff -r d254a5f9b93f src/share/classes/java/lang/reflect/Field.java
>>> --- a/src/share/classes/java/lang/reflect/Field.java    Wed Mar 27 13:40:26 2013 -0400
>>> +++ b/src/share/classes/java/lang/reflect/Field.java    Thu Mar 28 00:02:06 2013 -0700
>>> @@ -288,6 +288,9 @@
>>>      * {@code protected} or {@code private} first, and then other
>>>      * modifiers in the following order: {@code static}, {@code final},
>>>      * {@code transient}, {@code volatile}.
>>> +     *
>>> +     * @return a string describing this {@code Field}
>>> +     * @jls 8.3.1 Field Modifiers
>>>      */
>>>     public String toString() {
>>>         int mod = getModifiers();
>>> @@ -315,6 +318,7 @@
>>>      * its generic type
>>>      *
>>>      * @since 1.5
>>> +     * @jls 8.3.1 Field Modifiers
>>>      */
>>>     public String toGenericString() {
>>>         int mod = getModifiers();
>>> diff -r d254a5f9b93f src/share/classes/java/lang/reflect/Method.java
>>> --- a/src/share/classes/java/lang/reflect/Method.java    Wed Mar 27 13:40:26 2013 -0400
>>> +++ b/src/share/classes/java/lang/reflect/Method.java    Thu Mar 28 00:02:06 2013 -0700
>>> @@ -343,10 +343,16 @@
>>>      * {@code public}, {@code protected} or {@code private} first,
>>>      * and then other modifiers in the following order:
>>>      * {@code abstract}, {@code static}, {@code final},
>>> -     * {@code synchronized}, {@code native}, {@code strictfp}.
>>> +     * {@code synchronized}, {@code native}, {@code strictfp},
>>> +     * {@code default}.
>>> +     *
>>> +     * @return a string describing this {@code Method}
>>> +     *
>>> +     * @jls 8.4.3 Method Modifiers
>>>      */
>>>     public String toString() {
>>>         return sharedToString(Modifier.methodModifiers(),
>>> +                              isDefault(),
>>>                               parameterTypes,
>>>                               exceptionTypes);
>>>     }
>>> @@ -389,16 +395,19 @@
>>>      * {@code public}, {@code protected} or {@code private} first,
>>>      * and then other modifiers in the following order:
>>>      * {@code abstract}, {@code static}, {@code final},
>>> -     * {@code synchronized}, {@code native}, {@code strictfp}.
>>> +     * {@code synchronized}, {@code native}, {@code strictfp},
>>> +     * {@code default}.
>>>      *
>>>      * @return a string describing this {@code Method},
>>>      * include type parameters
>>>      *
>>>      * @since 1.5
>>> +     *
>>> +     * @jls 8.4.3 Method Modifiers
>>>      */
>>>     @Override
>>>     public String toGenericString() {
>>> -        return sharedToGenericString(Modifier.methodModifiers());
>>> +        return sharedToGenericString(Modifier.methodModifiers(), isDefault());
>>>     }
>>> 
>>>     @Override
>>> diff -r d254a5f9b93f test/java/lang/reflect/Method/GenericStringTest.java
>>> --- a/test/java/lang/reflect/Method/GenericStringTest.java    Wed Mar 27 13:40:26 2013 -0400
>>> +++ b/test/java/lang/reflect/Method/GenericStringTest.java    Thu Mar 28 00:02:06 2013 -0700
>>> @@ -23,7 +23,7 @@
>>> 
>>> /*
>>>  * @test
>>> - * @bug 5033583 6316717 6470106
>>> + * @bug 5033583 6316717 6470106 8004979
>>>  * @summary Check toGenericString() and toString() methods
>>>  * @author Joseph D. Darcy
>>>  */
>>> @@ -39,6 +39,7 @@
>>>         classList.add(TestClass1.class);
>>>         classList.add(TestClass2.class);
>>>         classList.add(Roebling.class);
>>> +        classList.add(TestInterface1.class);
>>> 
>>> 
>>>         for(Class clazz: classList)
>>> @@ -129,6 +130,20 @@
>>>     void varArg(Object ... arg) {}
>>> }
>>> 
>>> +interface TestInterface1 {
>>> +    @ExpectedGenericString(
>>> +   "public default void TestInterface1.foo()")
>>> +    @ExpectedString(
>>> +   "public default void TestInterface1.foo()")
>>> +    public default void foo(){;}
>>> +
>>> +    @ExpectedString(
>>> +   "public default java.lang.Object TestInterface1.bar()")
>>> +    @ExpectedGenericString(
>>> +   "public default  A TestInterface1.bar()")
>>> +    default  A bar(){return null;}
>>> +}
>>> +
>>> @Retention(RetentionPolicy.RUNTIME)
>>> @interface ExpectedGenericString {
>>>     String value();
>>> 
> 



From mandy.chung at oracle.com  Fri Mar 29 02:55:01 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 28 Mar 2013 19:55:01 -0700
Subject: Review Request 8007035: Deprecate SecurityManager.checkMemberAccess
Message-ID: <51550285.9050706@oracle.com>

Sean, John, Joe,

Can you review this fix todeprecatesthe |SecurityManager.checkMemberAccess|
method as proposed in http://openjdk.java.net/jeps/176?

Webrev at:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8007035/webrev.00

Specdiff:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8007035/specdiff

The |checkMemberAccess| method requires the caller?s frame to be
at a stack depth of four, which is fragile and difficult to enforce.

The fix deprecates the SecurityManager.checkMemberAccess method and
will throw an exception unconditionally in a future release.There
are several methods in java.lang.Class and the class spec of 
java.lang.invoke.MethodHandles.Lookup in the JDK specify to call
SecurityManager.checkMemberAccess.  The spec and implementation are
updated to do the appropriate permission check.

SecurityManager.checkMemberAccess is not final and it can be overridden
by a subclass.  However, we believe a SecurityManager subclass
implementation that overrides the checkMemberAccess method and behaves
differently than the default implementation is very rare. Thus
we decide not to handle the SecurityManager subclass case that
overrids the checkMemberAccess method with this fix and the compatibility
risk should be low.

Thanks
Mandy



From mandy.chung at oracle.com  Fri Mar 29 02:57:25 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 28 Mar 2013 19:57:25 -0700
Subject: Review request for 7198429: need checked categorization of
	caller-sensitive methods in the JDK
In-Reply-To: <8BA7EB20-0798-41E4-A391-DC195A147317@oracle.com>
References: <51532DF4.9020701@oracle.com>
	<8BA7EB20-0798-41E4-A391-DC195A147317@oracle.com>
Message-ID: <51550315.3080800@oracle.com>


On 3/28/2013 1:54 AM, John Rose wrote:
> On Mar 27, 2013, at 10:35 AM, Mandy Chung  wrote:
>
>> 1. I am working on a fix for 8007035 that proposes to deprecate SecurityManager.checkMemberAccess method as it requires the caller?s frame to be at a stack depth of four, which is fragile and difficult to enforce.
> Where you test c=smgr.getClass(), c == SecurityManager.class you should also add
> || c.getMethod("checkSecurityManager", ...).getDeclaringClass() == SecurityManager.class.
>
> That will accurately detect overloading.

With the fix for 8007035, this test will no longer be needed.  I just 
posted the code review for 8007035 [1].   I'll send out a webrev with 
both fixes once 8007035 is reviewed.

Mandy
[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-March/015547.html



From martinrb at google.com  Fri Mar 29 03:42:54 2013
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 28 Mar 2013 20:42:54 -0700
Subject: RFR-8008118
In-Reply-To: 
References: 
	<20130328191027.22BC597129@rebar.astron.com>
	
Message-ID: 

Latest webrev does it this way:

    for (i = 0; i < count; i++) {
        char *q = p + strcspn(p, ":");
        pathv[i] = (p == q) ? "." : p;
        *q = '\0';
        p = q + 1;
    }



On Thu, Mar 28, 2013 at 5:07 PM, Martin Buchholz wrote:

> strsep is nice, but not standard enough to use in the JDK.
> OTOH, strcspn is already used in the JDK, but doesn't really  buy much:
>
>     for (i = 0; i < count; i++) {
>         int len = strcspn(p, ":");
>         pathv[i] = (len == 0) ? "." : p;
>         p[len] = '\0';
>         p += len + 1;
>     }
>
>
>
> On Thu, Mar 28, 2013 at 12:10 PM, Christos Zoulas wrote:
>
>>
>> +     for (i = 0; (pathv[i] = strsep(&p, ":")) != NULL; i++)
>> +       if (!pathv[i][0])
>> +               pathv[i] = ".";
>>
>> christos
>>
>
>


From pbenedict at apache.org  Fri Mar 29 04:39:53 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Thu, 28 Mar 2013 23:39:53 -0500
Subject: Spliterator flags as enum (was Initial java.util.Spliterator
	putback)
In-Reply-To: 
References: 
	<51548FD8.7030103@cs.oswego.edu>
	
	<515494A9.30600@cs.oswego.edu>
	
	
Message-ID: 

I think the use of EnumSet in a public API is superior to bit flags.
Worrying about the number of bytes here is not important since they will
all end up being garbage collected when the stream processing ends.


On Thu, Mar 28, 2013 at 6:56 PM, Vitaly Davidovich wrote:

> Enum and EnumSet *are* good, but the problem is the overhead of
> representation.  If all you want is 32 bits to play with, you pay exactly 4
> bytes in price if using int.  With EnumSet, you pay object/heap overhead -
> on x64, 4 bytes vs 24; you pay GC price if you have lots of objects with
> embedded EnumSet instances in them, there's indirection in loading/passing
> them, etc
>
> Until JVM supports/implements value type/structure semantics, the overhead
> for these types of things continues to be an eyebrow raising issue.
>
> Sorry Josh, I know this isn't related to Spliterator directly and you did
> say that bit fields are *usually* not a good idea, but just wanted to throw
> this out there as more a plea for Oracle to do something about struct/value
> type hole. :)
>
> Sent from my phone
> On Mar 28, 2013 3:38 PM, "Joshua Bloch"  wrote:
>
> > Doug,
> >
> > On Thu, Mar 28, 2013 at 12:06 PM, Doug Lea 
 wrote:
> >
> > > On 03/28/13 14:52, Joshua Bloch wrote:
> > >
> > >> Doug,
> > >>
> > >> I don't get it. You can set and unset flags on your own EnumSet.  Why
> > >> isn't that
> > >> sufficient?
> > >>
> > >
> > > There are a lot of problems. First, even
> > > though most spliterators will return the same set of
> > > characteristics each time, you can't just create one static one:
> > >
> > > class MySpliterator { ...
> > >   static final EnumSet  cs = EnumSet.of(...);
> > >   EnumSet  characteristics() return cs; }
> > > }
> > >
> > > ... because you cannot risk that no one will modify.
> > >
> >
> > Sounds like a perfect opportunity to put in immutableEnumSet, which is
> > trivial to implement and generally useful. Alternatively, don't share,
> and
> > see if the performance it good enough.  (I suspect it will be.)
> >
> > Second, when inside streams, you'd have to create a new EnumSet
> > > Object across each stage, that somehow secretly extends the
> > > public Characteristics with non-public internal control flags.
> > > Which means either some slow conversion table or grabbing
> > > private EnumSet internals.
> > >
> >
> > Or having two EnumSets: one public, consisting of public constants, and
> one
> > private, consisting of private constants. Again, doesn't sound like a big
> > deal.
> >
> > So it is both slow and painful.
> >
> >
> > You haven't convinced me of either (yet).  Did you measure the
> performance?
> >
> >
> > > I tried to make it less so,
> > > knowing that people sometimes react hostilely to plain bit
> > > sets. But I'm sure that the current scheme is better than all
> > > I tried. (Ditto for Brian Goetz and Paul Sandoz).
> > > In fact, I think the current scheme is sorta nice in
> > > an absolute sense.
> >
> >
> > Could be.  I haven't seen it. That said, I find that bit fields are
> usually
> > not a good idea in the post-enum age.
> >
> >      Josh
> >
> >
>
>


From huizhe.wang at oracle.com  Fri Mar 29 07:37:41 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Fri, 29 Mar 2013 00:37:41 -0700
Subject: JDK-8010495: Update JAXP NetBeans project - add support for
	generating javadoc
In-Reply-To: <51549BE4.2090102@oracle.com>
References: <515038DA.3010802@oracle.com> <51549BE4.2090102@oracle.com>
Message-ID: <515544C5.90205@oracle.com>

Hi Daniel,

Looks good.  The docs are "for preview purposes only" anyways, I 
shouldn't be picky :-)

Thanks,
Joe

On 3/28/2013 12:37 PM, Daniel Fuchs wrote:
> Hi,
>
> Please find below a revised patch:
>
> 
>
> I had oversimplified the changes in project.xml.
> It seems you need to declare a source folder of type 'java'
> as well as a compilation-unit in order for 'Find Usage' to work
> properly in the editor.
>
> I have also restrained the packageset for the javadoc
> target as suggested by Joe.
>
> -- daniel
>
>
> On 3/25/13 12:45 PM, Daniel Fuchs wrote:
>> Hi guys,
>>
>> I'd like to propose a small change to jaxp/build.xml and
>> jaxp/nbproject/project.xml - in order to allow editing
>> JAXP sources in NetBeans, as well as generating the JAXP
>> javadoc for previewing purposes.
>>
>> I actually stole the javadoc target from
>> jdk/make/netbeans/common/shared.xml
>>
>> The changes are small & targeted at developers.
>> There should be no impact on the build process.
>>
>> Here is the webrev:
>>
>> http://cr.openjdk.java.net/~dfuchs/JDK-8010495/jdk8/webrev.00/
>>
>> best regards,
>>
>> -- daniel
>



From peter.levart at gmail.com  Fri Mar 29 08:34:59 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 29 Mar 2013 09:34:59 +0100
Subject: RFR JDK-7143928 : (coll) Optimize for Empty ArrayList and HashMap
In-Reply-To: <05339A88-8D24-4BF2-BAAF-845973640901@oracle.com>
References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com>
	
	<30E35219-D90D-4D71-94FD-45A90F04EE59@oracle.com>
	
	<51543099.5070907@cs.oswego.edu>
	<05339A88-8D24-4BF2-BAAF-845973640901@oracle.com>
Message-ID: <51555233.604@gmail.com>


On 03/28/2013 06:38 PM, Mike Duigou wrote:
> We have heard back from the performance folks that 85% of empty lists are created at default size. The proposed patch is going to be revised to do the inflation trick only for default sized maps which will eliminate the need for a new field. Something creative involving the use of the existing size field can certainly be considered for a future optimization.

This is actually a better approach, since it leaves a gate to non-lazy 
allocation. As with all lazy things, delaying failure can have 
undesirable effects. Catching OOME at HashMap construction vs. 1st put...

Regards, Peter

>
> On Mar 28 2013, at 04:59 , Doug Lea wrote:
>
>> On 03/27/13 12:17, Martin Buchholz wrote:
>>> But you can support any requested initial size if stored in the size field
>>> when list is empty.
>> In other words: Mike, please do not add a field if your goal is
>> to save space!
> Part of the analysis was that with current object layouts the added fields did not change the memory footprint of either class. This, of course only applies to current versions of Hotspot and it's object layout.
>
>> Also, I hope you or the performance testing folks
>> have extensive and accurate enough tests to show that the change
>> not only helps the empty case but does not hurt the vastly more
>> common non-empty case.
> They do. I believe that the object layout hides any increase in size.
>
>> Considering that this is the most
>> commonly used java.util class, there should be empirical
>> evidence that this is a net improvement.
> I will try to find how much of the analysis I can share.
>
>> My guess is that it can be done (we did something similar for
>> ConcurrentHashMap) but it takes  a lot of care.
>>
>> -Doug
>>
>>
>>> On Wed, Mar 27, 2013 at 8:02 AM, Mike Duigou  wrote:
>>>
>>>> This seems like a good idea. I will follow up with the performance people
>>>> to see if their findings include the requested initial size.
>>>>
>>>> Mike
>>>>
>>>> On Mar 26 2013, at 22:53 , Brian Goetz wrote:
>>>>
>>>>> What percentage of the empty lists are default-sized?  I suspect it is
>>>> large, in which case we could apply this trick only for the default-sized
>>>> lists, and eliminate the extra field.
>>>>> On Mar 26, 2013, at 5:25 PM, Mike Duigou wrote:
>>>>>
>>>>>> Hello all;
>>>>>>
>>>>>> This is a review for optimization work that came out of internal
>>>> analysis of Oracle's Java applications. It's based upon analysis that shows
>>>> that in large applications as much as 10% of maps and lists are initialized
>>>> but never receive any entries. A smaller number spend a large proportion of
>>>> their lifetime empty. We've found similar results across other workloads as
>>>> well. This patch is not a substitute for pre-sizing your collections and
>>>> maps--doing so will *always* have better results.
>>>>>> This patch extends HashMap and ArrayList to provide special handling
>>>> for newly created instances that avoids creating the backing array until
>>>> needed. There is a very small additional cost for detecting when to inflate
>>>> the map or list that is measurable in interpreted tests but disappears in
>>>> JITed code.
>>>>>> http://cr.openjdk.java.net/~mduigou/JDK-7143928/0/webrev/
>>>>>>
>>>>>> We expect that should this code prove successful in Java 8 it will be
>>>> backported to Java 7 updates.
>>>>>> The unit test may appear to be somewhat unrelated. It was created after
>>>> resolving a bug in an early version of this patch to detect the issue
>>>> encountered (LinkedHashMap.init() was not being called in readObject() when
>>>> the map was empty).
>>>>>> Mike



From bourges.laurent at gmail.com  Fri Mar 29 13:53:09 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Fri, 29 Mar 2013 14:53:09 +0100
Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
In-Reply-To: <51549C3F.1020301@oracle.com>
References: 
	
	<51506136.4020909@oracle.com> <51508139.9000507@oracle.com>
	
	<51549C3F.1020301@oracle.com>
Message-ID: 

Phil,

I agree it is a complex issue to improve memory usage while maintaining
performance at the JDK level: applications can use java2d pisces in very
different contexts: Swing app (client with only EDT thread), server-side
application (multi thread headless) ...

For the moment, I spent a lot of my time understanding the different
classes in java2d.pisces and analyzing memory usage / performance ... using
J2DBench (all graphics tests).

In my Swing application, pisces produces a lot of waste (GC) but on server
side, the GC overhead can be more important if several threads use pisces.

Pisces uses memory differently:
- fixed arrays (dasher, stroker)
- dynamic arrays (edges ...) rowAARLE (very big one for big shapes)

For the moment I am trying to avoid memory waste (pooling or kept
reference) without any memory constraint (no eviction) but I agree it is an
important aspect for server-side applications.

To avoid concurrency issues, I use a ThreadLocal context named
RendererContext to keep few temporary arrays (float6 and a BIG rowAARLE
instance) but there is also dynamic IntArrayCache et FloatArrayCache which
have several pools divided in buckets (256, 1024, 4096, 16384, 32768)
containing only few instances.

To have best performance, I studied pisces code to clear only the used
array parts when recycling or using dirty arrays (only clear
rowAARLE[...][1]).

I think Andrea's proposal is interesting to maybe put some system
properties to give hints (low memory footprint, use cache or not ...).

2013/3/28 Phil Race 

> Maintaining a pool of objects might be an appropriate thing for an
> applications,
> but its a lot trickier for the platform as the application's usage pattern
> or intent
> is largely unknown. Weak references or soft references might be of use but
> weak references usually go away even at the next incremental GC and soft
> references tend to not go away at all until you run out of heap.
>

Agreed; for the moment, pool eviction policy is not implemented but kept in
mind.
FYI: each RendererContext (per thread) has its own array pools (not shared)
that could have different caching policies:
For instance, AWT / EDT (repaint) could use a large cache although other
threads do not use array caching at all.


> You may well be right that always doubling the array size may be too
> simplistic,
> but it would need some analysis of the code and its usage to see how much
> better we can do.


There is two part:
- initial array size for dynamic arrays: difficult to estimate but for now
set to very low capacity (8 / 50 ...) to avoid memory waste for rectangle /
line shapes. In my patch, I have defined MIN_ARRAY_SIZE = 128 (array pool)
to avoid too much resizing as I am doing array recycling.
- grow: I use x4 instead of x2 to avoid array copies.

Laurent



2013/3/28 Phil Race 

> Maintaining a pool of objects might be an appropriate thing for an
> applications,
> but its a lot trickier for the platform as the application's usage pattern
> or intent
> is largely unknown. Weak references or soft references might be of use but
> weak references usually go away even at the next incremental GC and soft
> references tend to not go away at all until you run out of heap.
>
> You may well be right that always doubling the array size may be too
> simplistic,
> but it would need some analysis of the code and its usage to see how much
> better we can do.
>
>
> >Apparently, Arrays.fill is always faster (size in 10 ... 10 000) !
> > I suspect hotspot to optimize its code and use native functions, isn't
> it ???
>
> I suppose there is some hotspot magic involved to recognise and intrinsify
> this
> method, since the source code looks like a plain old for loop.
>
> -phil.
>
>
>
> On 3/26/2013 4:00 AM, Laurent Bourg?s wrote:
>
>> Dear all,
>>
>> First I joined recently the openJDK contributors, and I plan to fix
>> java2D pisces code in my spare time.
>>
>> I have a full time job on Aspro2: http://www.jmmc.fr/aspro; it is an
>> application to prepare astronomical observations at VLTI / CHARA and is
>> very used in our community (200 users): it provides scientific computations
>> (observability, model images using complex numbers ...) and zoomable plots
>> thanks to jFreeChart.
>>
>> Aspro2 is known to be very efficient (computation parallelization) and I
>> am often doing profiling using netbeans profiler or visualVM.
>>
>> To fix huge memory usages by java2d.pisces, I started implementing an
>> efficient ArrayCache (int[] and float[]) (in thread local to concurrency
>> problems):
>> - arrays in sizes between 10 and 10000 (more small arrays used than big
>> ones)
>> - resizing support (Arrays.copyOf) without wasting arrays
>> - reentrance i.e. many arrays are used at the same time (java2D Pisces
>> stroke / dash creates many segments to render)
>> - GC / Heap friendly ie support cache eviction and avoid consuming too
>> much memory
>>
>> I know object pooling is known to be not efficient with recent VM (GC is
>> better) but I think it is counter productive to create so many int[] arrays
>> in java2d.pisces and let the GC remove such wasted memory.
>>
>> Does someone have implemented such (open source) array cache (core-libs) ?
>> Opinions are welcome (but avoid "trolls").
>>
>> Moreover, sun.java2d.pisces.Helpers.**widenArray() performs a lot of
>> array resizing / copy (Arrays.copyOf) that I want to avoid mostly:
>>     // These use a hardcoded factor of 2 for increasing sizes. Perhaps
>> this
>>     // should be provided as an argument.
>>     static float[] widenArray(float[] in, final int cursize, final int
>> numToAdd) {
>>         if (in.length >= cursize + numToAdd) {
>>             return in;
>>         }
>>         return Arrays.copyOf(in, 2 * (cursize + numToAdd));
>>     }
>>
>>     static int[] widenArray(int[] in, final int cursize, final int
>> numToAdd) {
>>         if (in.length >= cursize + numToAdd) {
>>             return in;
>>         }
>>         return Arrays.copyOf(in, 2 * (cursize + numToAdd));
>>     }
>>
>> Thanks to Peter Levart, I use its microbench tool (
>> https://github.com/plevart/**micro-bench/tree/v2)
>> to benchmark ArrayCache operations... and J2DBench to test java2d
>> performances
>>
>> What is the fastest way to clear an array (part) ie fill by 0:
>> - public static void fill(int[] a, int fromIndex, int toIndex, int val)
>> - public static native void arraycopy(Object src,  int  srcPos, Object
>> dest, int destPos, int length);
>> - unsafe.setMemory(array, Unsafe.ARRAY_INT_BASE_OFFSET, 512 * SIZEOF_INT,
>> (byte) 0)
>>
>> Apparently, Arrays.fill is always faster (size in 10 ... 10 000) !
>> I suspect hotspot to optimize its code and use native functions, isn't it
>> ???
>>
>> Benchmarks results:
>> >> JVM START: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>> Testing arrays: int[1]...
>> #
>> # ZeroFill: run duration:  5 000 ms, #of logical CPUS: 4
>> #
>> # Warm up:
>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =      4,47 ns/op (? =   0,00 ns/op) [
>> 4,47]
>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =      4,40 ns/op (? =   0,00 ns/op) [
>> 4,40]
>> # Measure:
>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =      4,43 ns/op (? =   0,00 ns/op) [
>> 4,43]
>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>            2 threads, Tavg =      5,55 ns/op (? =   0,16 ns/op) [
>> 5,40,      5,72]
>>
>> #
>> # FillArraySystemCopy: run duration:  5 000 ms, #of logical CPUS: 4
>> #
>> # Warm up:
>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =      6,47 ns/op (? =   0,00 ns/op) [
>> 6,47]
>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =      6,21 ns/op (? =   0,00 ns/op) [
>> 6,21]
>> # Measure:
>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =      6,19 ns/op (? =   0,00 ns/op) [
>> 6,19]
>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            2 threads, Tavg =      7,80 ns/op (? =   0,10 ns/op) [
>> 7,90,      7,71]
>>
>> #
>> # FillArrayUnsafe: run duration:  5 000 ms, #of logical CPUS: 4
>> #
>> # Warm up:
>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =     26,82 ns/op (? =   0,00 ns/op) [
>>  26,82]
>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =     23,48 ns/op (? =   0,00 ns/op) [
>>  23,48]
>> # Measure:
>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =     22,42 ns/op (? =   0,00 ns/op) [
>>  22,42]
>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            2 threads, Tavg =     28,21 ns/op (? =   0,88 ns/op) [
>>  29,11,     27,36]
>>
>> Testing arrays: int[100]...
>> #
>> # ZeroFill: run duration:  5 000 ms, #of logical CPUS: 4
>> #
>> # Warm up:
>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =     16,49 ns/op (? =   0,00 ns/op) [
>>  16,49]
>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =     15,97 ns/op (? =   0,00 ns/op) [
>>  15,97]
>> # Measure:
>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =     16,03 ns/op (? =   0,00 ns/op) [
>>  16,03]
>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>            2 threads, Tavg =     19,32 ns/op (? =   0,46 ns/op) [
>>  18,87,     19,80]
>>
>> #
>> # FillArraySystemCopy: run duration:  5 000 ms, #of logical CPUS: 4
>> #
>> # Warm up:
>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =     14,51 ns/op (? =   0,00 ns/op) [
>>  14,51]
>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =     14,17 ns/op (? =   0,00 ns/op) [
>>  14,17]
>> # Measure:
>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =     14,09 ns/op (? =   0,00 ns/op) [
>>  14,09]
>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            2 threads, Tavg =     31,15 ns/op (? =   4,04 ns/op) [
>>  27,65,     35,67]
>>
>> #
>> # FillArrayUnsafe: run duration:  5 000 ms, #of logical CPUS: 4
>> #
>> # Warm up:
>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =     52,32 ns/op (? =   0,00 ns/op) [
>>  52,32]
>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =     52,82 ns/op (? =   0,00 ns/op) [
>>  52,82]
>> # Measure:
>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =     52,19 ns/op (? =   0,00 ns/op) [
>>  52,19]
>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            2 threads, Tavg =     70,87 ns/op (? =   0,71 ns/op) [
>>  70,17,     71,59]
>>
>> Testing arrays: int[10000]...
>> #
>> # ZeroFill: run duration:  5 000 ms, #of logical CPUS: 4
>> #
>> # Warm up:
>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =  1 208,64 ns/op (? =   0,00 ns/op) [ 1
>> 208,64]
>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =  1 238,01 ns/op (? =   0,00 ns/op) [ 1
>> 238,01]
>> # Measure:
>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =  1 235,81 ns/op (? =   0,00 ns/op) [ 1
>> 235,81]
>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>            2 threads, Tavg =  1 325,11 ns/op (? =   7,01 ns/op) [ 1
>> 332,16,  1 318,14]
>>
>> #
>> # FillArraySystemCopy: run duration:  5 000 ms, #of logical CPUS: 4
>> #
>> # Warm up:
>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =  1 930,93 ns/op (? =   0,00 ns/op) [ 1
>> 930,93]
>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =  2 060,80 ns/op (? =   0,00 ns/op) [ 2
>> 060,80]
>> # Measure:
>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =  2 105,21 ns/op (? =   0,00 ns/op) [ 2
>> 105,21]
>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            2 threads, Tavg =  2 160,33 ns/op (? =  13,74 ns/op) [ 2
>> 146,68,  2 174,15]
>>
>> #
>> # FillArrayUnsafe: run duration:  5 000 ms, #of logical CPUS: 4
>> #
>> # Warm up:
>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =  3 099,50 ns/op (? =   0,00 ns/op) [ 3
>> 099,50]
>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =  3 041,81 ns/op (? =   0,00 ns/op) [ 3
>> 041,81]
>> # Measure:
>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =  3 068,34 ns/op (? =   0,00 ns/op) [ 3
>> 068,34]
>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            2 threads, Tavg =  3 296,13 ns/op (? =  34,97 ns/op) [ 3
>> 331,47,  3 261,53]
>>
>>
>> PS: java.awt.geom.Path2D has also memory allocation issues:
>>         void needRoom(boolean needMove, int newCoords) {
>>             if (needMove && numTypes == 0) {
>> throw new IllegalPathStateException("**missing initial moveto "+
>> "in path definition");
>>             }
>>             int size = pointTypes.length;
>>             if (numTypes >= size) {
>> int grow = size;
>>                 if (grow > EXPAND_MAX) {
>> grow = EXPAND_MAX;
>>                 }
>> pointTypes = Arrays.copyOf(pointTypes, size+grow);
>>             }
>>             size = floatCoords.length;
>>             if (numCoords + newCoords > size) {
>> int grow = size;
>>                 if (grow > EXPAND_MAX * 2) {
>> grow = EXPAND_MAX * 2;
>>                 }
>>                 if (grow < newCoords) {
>> grow = newCoords;
>>                 }
>> floatCoords = Arrays.copyOf(floatCoords, size+grow);
>>             }
>>         }
>>
>> Best regards,
>> Laurent
>>
>
>


From christos at zoulas.com  Fri Mar 29 13:59:08 2013
From: christos at zoulas.com (Christos Zoulas)
Date: Fri, 29 Mar 2013 09:59:08 -0400
Subject: RFR-8008118
In-Reply-To: 
	from Martin Buchholz (Mar 28,  8:42pm)
Message-ID: <20130329135908.9CACE97129@rebar.astron.com>

On Mar 28,  8:42pm, martinrb at google.com (Martin Buchholz) wrote:
-- Subject: Re: RFR-8008118

| Latest webrev does it this way:
| 
|     for (i = 0; i < count; i++) {
|         char *q = p + strcspn(p, ":");
|         pathv[i] = (p == q) ? "." : p;
|         *q = '\0';
|         p = q + 1;
|     }

I prefer to have loops where the sentinel is the actual condition instead
of something computed independently, but that's fine too. 

christos

PS: Can we please add strsep(3) to solaris at some point? Everyone else
relevant seems to have it.


From bourges.laurent at gmail.com  Fri Mar 29 14:16:39 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Fri, 29 Mar 2013 15:16:39 +0100
Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
In-Reply-To: 
References: 
	
	<51506136.4020909@oracle.com> <51508139.9000507@oracle.com>
	
	<51549C3F.1020301@oracle.com>
	
	<5154ACCD.5090105@oracle.com>
	
Message-ID: 

Andrea,

It could be very interesting if you could provide some concrete example
about your map server: typical image height / width, shape complexity
(number, size, path sizes ...).

Ideally if you could write a test class (sample) computing a single image
it would be very helpful for me to compare my patched pisces vs current one.

Laurent


From paul.sandoz at oracle.com  Fri Mar 29 14:45:16 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 29 Mar 2013 15:45:16 +0100
Subject: Spliterator flags as enum (was Initial java.util.Spliterator
	putback)
In-Reply-To: 
References: 
	<51548FD8.7030103@cs.oswego.edu>
	
	<515494A9.30600@cs.oswego.edu>
	
	
	
Message-ID: <252DC5A1-0B61-433C-A50F-5BD8AD544D2C@oracle.com>

On Mar 29, 2013, at 5:39 AM, Paul Benedict  wrote:
> I think the use of EnumSet in a public API is superior to bit flags.
> Worrying about the number of bytes here is not important since they will
> all end up being garbage collected when the stream processing ends.
> 

I worry.

We need to reduce the fixed costs of setting up the pipeline so using streams are not unduly expensive compared to a for loop using an equivalent lambda. Fixed costs are especially noticeable for small data sizes e.g. < 10.

We are currently working on refactoring the internals to further reduce fixed costs.

Paul.

From dl at cs.oswego.edu  Fri Mar 29 14:53:44 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Fri, 29 Mar 2013 10:53:44 -0400
Subject: Spliterator flags as enum (was Initial java.util.Spliterator
	putback)
In-Reply-To: 
References: 
	<51548FD8.7030103@cs.oswego.edu>
	
	<515494A9.30600@cs.oswego.edu>
	
Message-ID: <5155AAF8.1050103@cs.oswego.edu>

On 03/28/13 15:14, Joshua Bloch wrote:

> Sounds like a perfect opportunity to put in immutableEnumSet, which is trivial
> to implement and generally useful. Alternatively, don't share, and see if the
> performance it good enough.  (I suspect it will be.)

Did you think that I of all people would I participate in a
performance-related decision without measuring performance? :-)

Imagine that you had to create a new EnumSet object
every time you invoked arrayList.iterator(). You'd surely
consider alternatives.

But really, the painfulness quotient is equally important.
We'd need to create immutableEnumSet class, and another class
that can arbitrarily extend the Spliterator's enums with
other control flags, all for the sake of arriving at an API
that seems less clear and less easy to use than what we have.

-Doug



From tim at peierls.net  Thu Mar 28 17:18:51 2013
From: tim at peierls.net (Tim Peierls)
Date: Thu, 28 Mar 2013 13:18:51 -0400
Subject: Spliterator flags as enum (was Initial java.util.Spliterator putback)
Message-ID: 

I can't find a discussion of why Spliterator flags are ints rather than
enum. The only thing coming close is this months-old update from Brian:

*Sept 25, 2012 - Oct 24, 2012*
> *...
> **Stream flags improvements (Paul). *Added an "encounter order" flag.
> Define flags with an enum. Make flags into declarative properties of Ops,
> where an op can declare that they preserve, inject, or clear a given flag,
> and move responsibility for flag computation into AbstractPipeline. Pass
> flags to wrap{Sink,Iterator} so they can act on the current set of flags.

But that was in another country, and besides, the Ops are dead. Is there
anything more recent about this? I'm prepared to hear that it's for
performance reasons, but there should at least be a record of the process
through which this was determined.

--tim


From josh at bloch.us  Thu Mar 28 18:52:29 2013
From: josh at bloch.us (Joshua Bloch)
Date: Thu, 28 Mar 2013 11:52:29 -0700
Subject: Spliterator flags as enum (was Initial java.util.Spliterator
	putback)
In-Reply-To: <51548FD8.7030103@cs.oswego.edu>
References: 
	<51548FD8.7030103@cs.oswego.edu>
Message-ID: 

Doug,

I don't get it. You can set and unset flags on your own EnumSet.  Why isn't
that sufficient?


    Josh

On Thu, Mar 28, 2013 at 11:45 AM, Doug Lea 
 wrote:

> On 03/28/13 13:18, Tim Peierls wrote:
>
>> I can't find a discussion of why Spliterator flags are ints rather than
>> enum.
>>
>
> We started out with enums on (my) initial Spliterator side vs
> control flags internal to streams. The we had to somehow
> mesh these to work together. On the stream side, you need
> to set and unset various bits across stages. Clearly
> you can't do that to someone's EnumSet -- they will not expect
> you to modify it, but enforcing this makes it both unwieldy and
> sleaze-inducing (we'd have to grab underlying representation from
> EnumSet).
>
> Another way of saying this is that we needed an efficient
> propagate-by-value small-N bit set mechanism, and the only candidate
> was the traditional one. This amounts to the same reason
> that nio "interest" flags are done the same way.
>
> -Doug
>
>
>
>
>
>


From josh at bloch.us  Thu Mar 28 19:14:54 2013
From: josh at bloch.us (Joshua Bloch)
Date: Thu, 28 Mar 2013 12:14:54 -0700
Subject: Spliterator flags as enum (was Initial java.util.Spliterator
	putback)
In-Reply-To: <515494A9.30600@cs.oswego.edu>
References: 
	<51548FD8.7030103@cs.oswego.edu>
	
	<515494A9.30600@cs.oswego.edu>
Message-ID: 

Doug,

On Thu, Mar 28, 2013 at 12:06 PM, Doug Lea 
 wrote:

> On 03/28/13 14:52, Joshua Bloch wrote:
>
>> Doug,
>>
>> I don't get it. You can set and unset flags on your own EnumSet.  Why
>> isn't that
>> sufficient?
>>
>
> There are a lot of problems. First, even
> though most spliterators will return the same set of
> characteristics each time, you can't just create one static one:
>
> class MySpliterator { ...
>   static final EnumSet  cs = EnumSet.of(...);
>   EnumSet  characteristics() return cs; }
> }
>
> ... because you cannot risk that no one will modify.
>

Sounds like a perfect opportunity to put in immutableEnumSet, which is
trivial to implement and generally useful. Alternatively, don't share, and
see if the performance it good enough.  (I suspect it will be.)

Second, when inside streams, you'd have to create a new EnumSet
> Object across each stage, that somehow secretly extends the
> public Characteristics with non-public internal control flags.
> Which means either some slow conversion table or grabbing
> private EnumSet internals.
>

Or having two EnumSets: one public, consisting of public constants, and one
private, consisting of private constants. Again, doesn't sound like a big
deal.

So it is both slow and painful.


You haven't convinced me of either (yet).  Did you measure the performance?


> I tried to make it less so,
> knowing that people sometimes react hostilely to plain bit
> sets. But I'm sure that the current scheme is better than all
> I tried. (Ditto for Brian Goetz and Paul Sandoz).
> In fact, I think the current scheme is sorta nice in
> an absolute sense.


Could be.  I haven't seen it. That said, I find that bit fields are usually
not a good idea in the post-enum age.

     Josh


From andrea.aime at geo-solutions.it  Thu Mar 28 20:40:47 2013
From: andrea.aime at geo-solutions.it (Andrea Aime)
Date: Thu, 28 Mar 2013 21:40:47 +0100
Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
In-Reply-To: <51549C3F.1020301@oracle.com>
References: 
	
	<51506136.4020909@oracle.com> <51508139.9000507@oracle.com>
	
	<51549C3F.1020301@oracle.com>
Message-ID: 

On Thu, Mar 28, 2013 at 8:38 PM, Phil Race  wrote:

> Maintaining a pool of objects might be an appropriate thing for an
> applications,
> but its a lot trickier for the platform as the application's usage pattern
> or intent
> is largely unknown. Weak references or soft references might be of use but
> weak references usually go away even at the next incremental GC and soft
> references tend to not go away at all until you run out of heap.
>

At the same time, the current decision is affecting some applications badly.
I've seen the same happening for another old java2d bug, where the alpha
tile is cached and coordinated with JVM synchronized statement that kill
scalability in
server side applications heavily using Java2D (e.g, map servers):
http://bugs.sun.com/view_bug.do?bug_id=6508591

For these kinds of decisions sometimes it's not possible to find a one size
that
fits all: it would be good if there was some way for the application to
plug-in their
own behavior, ideally with a Graphics2D rendering hint, less ideally with a
system
variable (a JVM can run multiple applications, not all might have the same
needs).

Now, I understand that today (java 7 or java 8) one could plug-in their own
rasterizer,
yet writing a rasterizer from scratch is kind of a tall order.
Being able to get some control on these kind of decisions via hints would
be nicer imho.

Cheers
Andrea


From philip.race at oracle.com  Thu Mar 28 20:51:30 2013
From: philip.race at oracle.com (Phil Race)
Date: Thu, 28 Mar 2013 13:51:30 -0700
Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
In-Reply-To: 
References: 
	
	<51506136.4020909@oracle.com> <51508139.9000507@oracle.com>
	
	<51549C3F.1020301@oracle.com>
	
Message-ID: <5154AD52.7020503@oracle.com>

B'ccing discuss and core-libs as I realise this is mostly spam for those 
lists.

On 3/28/2013 1:40 PM, Andrea Aime wrote:
> On Thu, Mar 28, 2013 at 8:38 PM, Phil Race  > wrote:
>
>     Maintaining a pool of objects might be an appropriate thing for an
>     applications,
>     but its a lot trickier for the platform as the application's usage
>     pattern or intent
>     is largely unknown. Weak references or soft references might be of
>     use but
>     weak references usually go away even at the next incremental GC
>     and soft
>     references tend to not go away at all until you run out of heap.
>
>
> At the same time, the current decision is affecting some applications 
> badly.
> I've seen the same happening for another old java2d bug, where the alpha
> tile is cached and coordinated with JVM synchronized statement that 
> kill scalability in
> server side applications heavily using Java2D (e.g, map servers):
> http://bugs.sun.com/view_bug.do?bug_id=6508591

In fact that bug is not related to pisces, or the issue here.
its in the closed source ductus code which is native, not java.

>
> For these kinds of decisions sometimes it's not possible to find a one 
> size that
> fits all: it would be good if there was some way for the application 
> to plug-in their
> own behavior, ideally with a Graphics2D rendering hint, less ideally 
> with a system
> variable (a JVM can run multiple applications, not all might have the 
> same needs).
>
> Now, I understand that today (java 7 or java 8) one could plug-in 
> their own rasterizer,
> yet writing a rasterizer from scratch is kind of a tall order.

The pluggable interface wasn't so that others could do it, it was just 
so that
JDK could operate with either pisces or ductus.

-phil.

> Being able to get some control on these kind of decisions via hints 
> would be nicer imho.
>
> Cheers
> Andrea



From andrea.aime at geo-solutions.it  Fri Mar 29 14:01:59 2013
From: andrea.aime at geo-solutions.it (Andrea Aime)
Date: Fri, 29 Mar 2013 15:01:59 +0100
Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
In-Reply-To: <5154ACCD.5090105@oracle.com>
References: 
	
	<51506136.4020909@oracle.com> <51508139.9000507@oracle.com>
	
	<51549C3F.1020301@oracle.com>
	
	<5154ACCD.5090105@oracle.com>
Message-ID: 

On Thu, Mar 28, 2013 at 9:49 PM, Phil Race  wrote:

> At the same time, the current decision is affecting some applications
>> badly.
>> I've seen the same happening for another old java2d bug, where the alpha
>> tile is cached and coordinated with JVM synchronized statement that kill
>> scalability in
>> server side applications heavily using Java2D (e.g, map servers):
>> http://bugs.sun.com/view_bug.**do?bug_id=6508591
>>
>
> In fact that bug is not related to pisces, or the issue here.
> its in the closed source ductus code which is native, not java.


I was not contesting that bug here, just making a parallel on method:
trying
to write one size fits all code did not work there, where only the desktop
needs
were taken into account, nor here, where it seems particular applications
are
being affected by design decisions in array resizing.


>
>
>
>> For these kinds of decisions sometimes it's not possible to find a one
>> size that
>> fits all: it would be good if there was some way for the application to
>> plug-in their
>> own behavior, ideally with a Graphics2D rendering hint, less ideally with
>> a system
>> variable (a JVM can run multiple applications, not all might have the
>> same needs).
>>
>> Now, I understand that today (java 7 or java 8) one could plug-in their
>> own rasterizer,
>> yet writing a rasterizer from scratch is kind of a tall order.
>>
>
> The pluggable interface wasn't so that others could do it, it was just so
> that
> JDK could operate with either pisces or ductus.


That's a bummer, I was hoping to be able to do something about the poor
situation
in which all java based web map servers are into,
maybe trying to write a different rasterizer, because pisces is too slow
and sometimes
generate low quality output, and ductus does not scale up.

What is the suggested approach to address that? Trying to patch pisces
instead?
What if some performance decisions need to favour server side usage in
order to get
the desired results?

Cheers
Andrea

-- 
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------


From tim at peierls.net  Fri Mar 29 15:25:54 2013
From: tim at peierls.net (Tim Peierls)
Date: Fri, 29 Mar 2013 11:25:54 -0400
Subject: Spliterator flags as enum (was Initial java.util.Spliterator
	putback)
In-Reply-To: <5155AAF8.1050103@cs.oswego.edu>
References: 
	<51548FD8.7030103@cs.oswego.edu>
	
	<515494A9.30600@cs.oswego.edu>
	
	<5155AAF8.1050103@cs.oswego.edu>
Message-ID: 

On Fri, Mar 29, 2013 at 10:53 AM, Doug Lea 
 wrote:

> But really, the painfulness quotient is equally important.
> We'd need to create immutableEnumSet class, and another class
> that can arbitrarily extend the Spliterator's enums with
> other control flags, all for the sake of arriving at an API
> that seems less clear and less easy to use than what we have.


That API doesn't exist, so it's not really fair to say that it seems less
clear and easy to use. As far as I can see in the common discussions, no
one has seriously explored any alternatives.

The presence of such flags in a Java 8 API would (and should) raise a lot
of eyebrows, because it goes against what people have been told for well
over a decade. If it's adopted as is, there had better be a good
explanation for doc readers of why alternatives were rejected. "We were
comfortable with int flags and nothing else significantly better suggested
itself" won't cut it. "We know int flags aren't great for an API, but we
tried very hard to find better alternatives, to no avail" would (if it were
true).

--tim


From bourges.laurent at gmail.com  Sat Mar 30 12:38:32 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Sat, 30 Mar 2013 13:38:32 +0100
Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
In-Reply-To: <51563427.1030206@oracle.com>
References: 
	
	<51506136.4020909@oracle.com> <51508139.9000507@oracle.com>
	
	<51549C3F.1020301@oracle.com>
	
	<51563427.1030206@oracle.com>
Message-ID: 

Jim,

There are finally only few growable arrays (edges, curves, rowAARLE) and
now I have a working Pisces code (J2DBench pass OK) that performs better
than current (2x - 3x faster on dasher or big shapes) using only few
megabytes (Xmx32m) ...

Moreover, these arrays could be created once per thread (thread local) to
avoid GC (low footprint) and enhance performance (no GC / array resizing or
coyping) with an initial size of 4K or 16K representing only 16 x 4 = 65Kb !

The only array that causes troubles is the growable
PiscesCache.rowAARLE[Y][tuples] which Y size depends on the shape / clip
bounds and tuples depend on the crossing numbers at the current row Y.

For now I am using int[2048][20] but it could be tuned ...

Finally, I figured out several hard-coded values relative to AA (3x3
samples, error level ...) that could be set as rendering hints. For example
I would like to tune the number of samples to 8x8 or 2x2 ... depending on
the use case.

I expect to send an alpha version of my patch to illustrate my talks.

2013/3/30 Jim Graham 

> Other thoughts - using chained buckets of edges instead of one single long
> list.  It would be easier to keep a pool of buckets (each holding, say, 256
> edges?) than a "one-size-fits-all" pool of arrays.  Then all you have to do
> is keep high water marks on the number of simultaneously used buckets in
> order to tune the cache for a given application.
>
> It would make the code that manages "pointers" to edges a little more
> complicated, though...
>

Good idea, but maybe difficult for me to implement. As I said, this array
may be less a problem than rowAARLE.

Of course, I need some "real life" tests to be able to perform better
diagnostics: maybe I could add some "instrumentations" / statistics to
gather while running in order to tune Pisces automatically depending on the
user work load.

Regards,
Laurent

On 3/29/2013 6:53 AM, Laurent Bourg?s wrote:

> Phil,
>
> I agree it is a complex issue to improve memory usage while maintaining
> performance at the JDK level: applications can use java2d pisces in very
> different contexts: Swing app (client with only EDT thread), server-side
> application (multi thread headless) ...
>
> For the moment, I spent a lot of my time understanding the different
> classes in java2d.pisces and analyzing memory usage / performance ... using
> J2DBench (all graphics tests).
>
> In my Swing application, pisces produces a lot of waste (GC) but on server
> side, the GC overhead can be more important if several threads use pisces.
>
> Pisces uses memory differently:
> - fixed arrays (dasher, stroker)
> - dynamic arrays (edges ...) rowAARLE (very big one for big shapes)
>
> For the moment I am trying to avoid memory waste (pooling or kept
> reference) without any memory constraint (no eviction) but I agree it is an
> important aspect for server-side applications.
>
> To avoid concurrency issues, I use a ThreadLocal context named
> RendererContext to keep few temporary arrays (float6 and a BIG rowAARLE
> instance) but there is also dynamic IntArrayCache et FloatArrayCache which
> have several pools divided in buckets (256, 1024, 4096, 16384, 32768)
> containing only few instances.
>
> To have best performance, I studied pisces code to clear only the used
> array parts when recycling or using dirty arrays (only clear
> rowAARLE[...][1]).
>
> I think Andrea's proposal is interesting to maybe put some system
> properties to give hints (low memory footprint, use cache or not ...).
>
> 2013/3/28 Phil Race 
>
>  Maintaining a pool of objects might be an appropriate thing for an
>> applications,
>> but its a lot trickier for the platform as the application's usage pattern
>> or intent
>> is largely unknown. Weak references or soft references might be of use but
>> weak references usually go away even at the next incremental GC and soft
>> references tend to not go away at all until you run out of heap.
>>
>>
> Agreed; for the moment, pool eviction policy is not implemented but kept in
> mind.
> FYI: each RendererContext (per thread) has its own array pools (not shared)
> that could have different caching policies:
> For instance, AWT / EDT (repaint) could use a large cache although other
> threads do not use array caching at all.
>
>
>  You may well be right that always doubling the array size may be too
>> simplistic,
>> but it would need some analysis of the code and its usage to see how much
>> better we can do.
>>
>
>
> There is two part:
> - initial array size for dynamic arrays: difficult to estimate but for now
> set to very low capacity (8 / 50 ...) to avoid memory waste for rectangle /
> line shapes. In my patch, I have defined MIN_ARRAY_SIZE = 128 (array pool)
> to avoid too much resizing as I am doing array recycling.
> - grow: I use x4 instead of x2 to avoid array copies.
>
> Laurent
>
>
>
> 2013/3/28 Phil Race 
>
>  Maintaining a pool of objects might be an appropriate thing for an
>> applications,
>> but its a lot trickier for the platform as the application's usage pattern
>> or intent
>> is largely unknown. Weak references or soft references might be of use but
>> weak references usually go away even at the next incremental GC and soft
>> references tend to not go away at all until you run out of heap.
>>
>> You may well be right that always doubling the array size may be too
>> simplistic,
>> but it would need some analysis of the code and its usage to see how much
>> better we can do.
>>
>>
>>  Apparently, Arrays.fill is always faster (size in 10 ... 10 000) !
>>> I suspect hotspot to optimize its code and use native functions, isn't
>>>
>> it ???
>>
>> I suppose there is some hotspot magic involved to recognise and intrinsify
>> this
>> method, since the source code looks like a plain old for loop.
>>
>> -phil.
>>
>>
>>
>> On 3/26/2013 4:00 AM, Laurent Bourg?s wrote:
>>
>>  Dear all,
>>>
>>> First I joined recently the openJDK contributors, and I plan to fix
>>> java2D pisces code in my spare time.
>>>
>>> I have a full time job on Aspro2: http://www.jmmc.fr/aspro; it is an
>>> application to prepare astronomical observations at VLTI / CHARA and is
>>> very used in our community (200 users): it provides scientific
>>> computations
>>> (observability, model images using complex numbers ...) and zoomable
>>> plots
>>> thanks to jFreeChart.
>>>
>>> Aspro2 is known to be very efficient (computation parallelization) and I
>>> am often doing profiling using netbeans profiler or visualVM.
>>>
>>> To fix huge memory usages by java2d.pisces, I started implementing an
>>> efficient ArrayCache (int[] and float[]) (in thread local to concurrency
>>> problems):
>>> - arrays in sizes between 10 and 10000 (more small arrays used than big
>>> ones)
>>> - resizing support (Arrays.copyOf) without wasting arrays
>>> - reentrance i.e. many arrays are used at the same time (java2D Pisces
>>> stroke / dash creates many segments to render)
>>> - GC / Heap friendly ie support cache eviction and avoid consuming too
>>> much memory
>>>
>>> I know object pooling is known to be not efficient with recent VM (GC is
>>> better) but I think it is counter productive to create so many int[]
>>> arrays
>>> in java2d.pisces and let the GC remove such wasted memory.
>>>
>>> Does someone have implemented such (open source) array cache (core-libs)
>>> ?
>>> Opinions are welcome (but avoid "trolls").
>>>
>>>
>>>
>>>


From bourges.laurent at gmail.com  Sat Mar 30 13:01:50 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Sat, 30 Mar 2013 14:01:50 +0100
Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
In-Reply-To: 
References: 
	
	<51506136.4020909@oracle.com> <51508139.9000507@oracle.com>
	
	<51549C3F.1020301@oracle.com>
	
	<5154ACCD.5090105@oracle.com>
	
	
	
Message-ID: 

Andrea,

thanks for these estimates / stats.

I think such use case could benefit a lot from my patch (low memory
footprint) but thread-safe cached / reused arrays/ LineIteratorData /
StrokerData / DasherData.

As I said to Jim, there are two sort of problems:
- memory handling (growable arrays) has to be smart (auto - tune)
- clipping issues (dasher, stroker) and spatial resolution (no cpu/memory
waste)


2013/3/30 Andrea Aime 

> On Fri, Mar 29, 2013 at 3:16 PM, Laurent Bourg?s <
> bourges.laurent at gmail.com> wrote:
>
>> Andrea,
>>
>> It could be very interesting if you could provide some concrete example
>> about your map server: typical image height / width, shape complexity
>> (number, size, path sizes ...).
>>
>
> It's all over the place. Image size: from 256x256 to 10000x10000, number
> of shapes, from a few hundreds to a few millions, path sizes, from say 10
> points
> to thousands (the code already makes sure there are no two consequent
> points sitting in the same pixel before trying to draw them),
> stroke wise it can be simple or using dasharrays.
>
>
>>
>> Ideally if you could write a test class (sample) computing a single image
>> it would be very helpful for me to compare my patched pisces vs current one.
>>
>
> I don't have anything ready, the existing code loads data from spatial
> database, sets up styles from XML descriptions, turns each spatial db
> geomety in java shapes
> and so on. But I guess I could concoct something close enough.
> I'm writing some code to gather statistics about the shapes that are
> actually painted (scrolling over the path iterators) and then I'll try to
> make a randomized
> shape painter that gets close to those stats.
>

Great news ! I am waiting your test code to perform few benchmarks.

I am using J2DBench but it does not perform such complex drawing (complex
shapes ...) or multi threading tests (parallel drawings on buffered images)

Laurent


From Alan.Bateman at oracle.com  Sat Mar 30 17:23:37 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 30 Mar 2013 17:23:37 +0000
Subject: Review JDK-8010837 - TEST_BUG:
	java/io/FileInputStream/LargeFileAvailable.java fails intermittently
In-Reply-To: <5151F719.6030503@oracle.com>
References: <5151F719.6030503@oracle.com>
Message-ID: <51571F99.8000103@oracle.com>

On 26/03/2013 19:29, Dan Xu wrote:
> Hi All,
>
> In the old JVM function, os::available, it could return negative 
> values because lseek() allows the file offset to be set beyond the end 
> of a file. In the previous change of removing jvm functions, I wasn't 
> aware of that and regardnegative values as invalid and return 0, which 
> causes this test failed if it handles negative values. This 
> fixaddressedthis problem and added a new testcase to ensure the 
> correctbehaviour when available() encounters negative values.
>
> Webrev: http://cr.openjdk.java.net/~dxu/8010837/webrev/
>
> Thanks,
>
> -Dan
I see this has already been pushed but I think it requires further 
discussion. I think it would be surprising if available() returned 
anything other than 0 for this case. You can't read a negative number of 
bytes, and with a normal InputStream then a negative skip is a no-op. So 
minimally we will need a spec clarification to make it clear how 
available() should behave when the file position is beyond the current 
file size. I just checked Channels.newInputStream and it does return 0 
for this case. I also checked the FileInputStream.skip method and it 
seems to differ from its spec in that it allows a negative skip if the 
resulting file position is >= 0. I'll create bugs for these issues 
(assuming there aren't existing bugs on these topics area).

-Alan.


From dan.xu at oracle.com  Sat Mar 30 17:56:34 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Sat, 30 Mar 2013 10:56:34 -0700
Subject: Review JDK-8010837 - TEST_BUG:
	java/io/FileInputStream/LargeFileAvailable.java fails intermittently
In-Reply-To: <51571F99.8000103@oracle.com>
References: <5151F719.6030503@oracle.com> <51571F99.8000103@oracle.com>
Message-ID: <51572752.8000208@oracle.com>

I see. So we will need clarify the spec and make corresponding changes. 
I think as long as we don't trigger exceptions and just return 0 will be 
backward-compatible, right?

-Dan


On 03/30/2013 10:23 AM, Alan Bateman wrote:
> On 26/03/2013 19:29, Dan Xu wrote:
>> Hi All,
>>
>> In the old JVM function, os::available, it could return negative 
>> values because lseek() allows the file offset to be set beyond the 
>> end of a file. In the previous change of removing jvm functions, I 
>> wasn't aware of that and regardnegative values as invalid and return 
>> 0, which causes this test failed if it handles negative values. This 
>> fixaddressedthis problem and added a new testcase to ensure the 
>> correctbehaviour when available() encounters negative values.
>>
>> Webrev: http://cr.openjdk.java.net/~dxu/8010837/webrev/
>>
>> Thanks,
>>
>> -Dan
> I see this has already been pushed but I think it requires further 
> discussion. I think it would be surprising if available() returned 
> anything other than 0 for this case. You can't read a negative number 
> of bytes, and with a normal InputStream then a negative skip is a 
> no-op. So minimally we will need a spec clarification to make it clear 
> how available() should behave when the file position is beyond the 
> current file size. I just checked Channels.newInputStream and it does 
> return 0 for this case. I also checked the FileInputStream.skip method 
> and it seems to differ from its spec in that it allows a negative skip 
> if the resulting file position is >= 0. I'll create bugs for these 
> issues (assuming there aren't existing bugs on these topics area).
>
> -Alan.



From Alan.Bateman at oracle.com  Sun Mar 31 19:32:17 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 31 Mar 2013 20:32:17 +0100
Subject: hg: jdk8/tl/jdk: 8010846: Update the corresponding test in
	test/vm/verifier/TestStaticIF.java
In-Reply-To: <20130327175853.38B7248427@hg.openjdk.java.net>
References: <20130327175853.38B7248427@hg.openjdk.java.net>
Message-ID: <51588F41.5060305@oracle.com>

On 27/03/2013 17:58, karen.kinnear at oracle.com wrote:
> Changeset: d254a5f9b93f
> Author:    acorn
> Date:      2013-03-27 13:40 -0400
> URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d254a5f9b93f
>
> 8010846: Update the corresponding test in test/vm/verifier/TestStaticIF.java
> Summary: Remove test flag -XX:-UseSplitVerifier, not supported classfile 52
> Reviewed-by: acorn, hseigel
>
> ! test/vm/verifier/TestStaticIF.java
>
Karen - just to note that test is currently excluded 
(jdk/test/ProblemList.txt) so it will need to be removed from the list 
to have it run again.

-Alan


From james.graham at oracle.com  Sat Mar 30 00:39:03 2013
From: james.graham at oracle.com (Jim Graham)
Date: Fri, 29 Mar 2013 17:39:03 -0700
Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
In-Reply-To: 
References: 
	
	<51506136.4020909@oracle.com> <51508139.9000507@oracle.com>
	
	<51549C3F.1020301@oracle.com>
	
Message-ID: <51563427.1030206@oracle.com>

Other thoughts - using chained buckets of edges instead of one single long list.  It would be easier to keep a pool of buckets (each holding, say, 256 edges?) than a "one-size-fits-all" pool of arrays.  Then all you have to do is keep high water marks on the number of simultaneously used buckets in order to tune the cache for a given application.

It would make the code that manages "pointers" to edges a little more complicated, though...

			...jim

On 3/29/2013 6:53 AM, Laurent Bourg?s wrote:
> Phil,
>
> I agree it is a complex issue to improve memory usage while maintaining
> performance at the JDK level: applications can use java2d pisces in very
> different contexts: Swing app (client with only EDT thread), server-side
> application (multi thread headless) ...
>
> For the moment, I spent a lot of my time understanding the different
> classes in java2d.pisces and analyzing memory usage / performance ... using
> J2DBench (all graphics tests).
>
> In my Swing application, pisces produces a lot of waste (GC) but on server
> side, the GC overhead can be more important if several threads use pisces.
>
> Pisces uses memory differently:
> - fixed arrays (dasher, stroker)
> - dynamic arrays (edges ...) rowAARLE (very big one for big shapes)
>
> For the moment I am trying to avoid memory waste (pooling or kept
> reference) without any memory constraint (no eviction) but I agree it is an
> important aspect for server-side applications.
>
> To avoid concurrency issues, I use a ThreadLocal context named
> RendererContext to keep few temporary arrays (float6 and a BIG rowAARLE
> instance) but there is also dynamic IntArrayCache et FloatArrayCache which
> have several pools divided in buckets (256, 1024, 4096, 16384, 32768)
> containing only few instances.
>
> To have best performance, I studied pisces code to clear only the used
> array parts when recycling or using dirty arrays (only clear
> rowAARLE[...][1]).
>
> I think Andrea's proposal is interesting to maybe put some system
> properties to give hints (low memory footprint, use cache or not ...).
>
> 2013/3/28 Phil Race 
>
>> Maintaining a pool of objects might be an appropriate thing for an
>> applications,
>> but its a lot trickier for the platform as the application's usage pattern
>> or intent
>> is largely unknown. Weak references or soft references might be of use but
>> weak references usually go away even at the next incremental GC and soft
>> references tend to not go away at all until you run out of heap.
>>
>
> Agreed; for the moment, pool eviction policy is not implemented but kept in
> mind.
> FYI: each RendererContext (per thread) has its own array pools (not shared)
> that could have different caching policies:
> For instance, AWT / EDT (repaint) could use a large cache although other
> threads do not use array caching at all.
>
>
>> You may well be right that always doubling the array size may be too
>> simplistic,
>> but it would need some analysis of the code and its usage to see how much
>> better we can do.
>
>
> There is two part:
> - initial array size for dynamic arrays: difficult to estimate but for now
> set to very low capacity (8 / 50 ...) to avoid memory waste for rectangle /
> line shapes. In my patch, I have defined MIN_ARRAY_SIZE = 128 (array pool)
> to avoid too much resizing as I am doing array recycling.
> - grow: I use x4 instead of x2 to avoid array copies.
>
> Laurent
>
>
>
> 2013/3/28 Phil Race 
>
>> Maintaining a pool of objects might be an appropriate thing for an
>> applications,
>> but its a lot trickier for the platform as the application's usage pattern
>> or intent
>> is largely unknown. Weak references or soft references might be of use but
>> weak references usually go away even at the next incremental GC and soft
>> references tend to not go away at all until you run out of heap.
>>
>> You may well be right that always doubling the array size may be too
>> simplistic,
>> but it would need some analysis of the code and its usage to see how much
>> better we can do.
>>
>>
>>> Apparently, Arrays.fill is always faster (size in 10 ... 10 000) !
>>> I suspect hotspot to optimize its code and use native functions, isn't
>> it ???
>>
>> I suppose there is some hotspot magic involved to recognise and intrinsify
>> this
>> method, since the source code looks like a plain old for loop.
>>
>> -phil.
>>
>>
>>
>> On 3/26/2013 4:00 AM, Laurent Bourg?s wrote:
>>
>>> Dear all,
>>>
>>> First I joined recently the openJDK contributors, and I plan to fix
>>> java2D pisces code in my spare time.
>>>
>>> I have a full time job on Aspro2: http://www.jmmc.fr/aspro; it is an
>>> application to prepare astronomical observations at VLTI / CHARA and is
>>> very used in our community (200 users): it provides scientific computations
>>> (observability, model images using complex numbers ...) and zoomable plots
>>> thanks to jFreeChart.
>>>
>>> Aspro2 is known to be very efficient (computation parallelization) and I
>>> am often doing profiling using netbeans profiler or visualVM.
>>>
>>> To fix huge memory usages by java2d.pisces, I started implementing an
>>> efficient ArrayCache (int[] and float[]) (in thread local to concurrency
>>> problems):
>>> - arrays in sizes between 10 and 10000 (more small arrays used than big
>>> ones)
>>> - resizing support (Arrays.copyOf) without wasting arrays
>>> - reentrance i.e. many arrays are used at the same time (java2D Pisces
>>> stroke / dash creates many segments to render)
>>> - GC / Heap friendly ie support cache eviction and avoid consuming too
>>> much memory
>>>
>>> I know object pooling is known to be not efficient with recent VM (GC is
>>> better) but I think it is counter productive to create so many int[] arrays
>>> in java2d.pisces and let the GC remove such wasted memory.
>>>
>>> Does someone have implemented such (open source) array cache (core-libs) ?
>>> Opinions are welcome (but avoid "trolls").
>>>
>>> Moreover, sun.java2d.pisces.Helpers.**widenArray() performs a lot of
>>> array resizing / copy (Arrays.copyOf) that I want to avoid mostly:
>>>      // These use a hardcoded factor of 2 for increasing sizes. Perhaps
>>> this
>>>      // should be provided as an argument.
>>>      static float[] widenArray(float[] in, final int cursize, final int
>>> numToAdd) {
>>>          if (in.length >= cursize + numToAdd) {
>>>              return in;
>>>          }
>>>          return Arrays.copyOf(in, 2 * (cursize + numToAdd));
>>>      }
>>>
>>>      static int[] widenArray(int[] in, final int cursize, final int
>>> numToAdd) {
>>>          if (in.length >= cursize + numToAdd) {
>>>              return in;
>>>          }
>>>          return Arrays.copyOf(in, 2 * (cursize + numToAdd));
>>>      }
>>>
>>> Thanks to Peter Levart, I use its microbench tool (
>>> https://github.com/plevart/**micro-bench/tree/v2)
>>> to benchmark ArrayCache operations... and J2DBench to test java2d
>>> performances
>>>
>>> What is the fastest way to clear an array (part) ie fill by 0:
>>> - public static void fill(int[] a, int fromIndex, int toIndex, int val)
>>> - public static native void arraycopy(Object src,  int  srcPos, Object
>>> dest, int destPos, int length);
>>> - unsafe.setMemory(array, Unsafe.ARRAY_INT_BASE_OFFSET, 512 * SIZEOF_INT,
>>> (byte) 0)
>>>
>>> Apparently, Arrays.fill is always faster (size in 10 ... 10 000) !
>>> I suspect hotspot to optimize its code and use native functions, isn't it
>>> ???
>>>
>>> Benchmarks results:
>>>>> JVM START: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>> Testing arrays: int[1]...
>>> #
>>> # ZeroFill: run duration:  5 000 ms, #of logical CPUS: 4
>>> #
>>> # Warm up:
>>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =      4,47 ns/op (? =   0,00 ns/op) [
>>> 4,47]
>>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =      4,40 ns/op (? =   0,00 ns/op) [
>>> 4,40]
>>> # Measure:
>>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =      4,43 ns/op (? =   0,00 ns/op) [
>>> 4,43]
>>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             2 threads, Tavg =      5,55 ns/op (? =   0,16 ns/op) [
>>> 5,40,      5,72]
>>>
>>> #
>>> # FillArraySystemCopy: run duration:  5 000 ms, #of logical CPUS: 4
>>> #
>>> # Warm up:
>>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =      6,47 ns/op (? =   0,00 ns/op) [
>>> 6,47]
>>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =      6,21 ns/op (? =   0,00 ns/op) [
>>> 6,21]
>>> # Measure:
>>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =      6,19 ns/op (? =   0,00 ns/op) [
>>> 6,19]
>>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             2 threads, Tavg =      7,80 ns/op (? =   0,10 ns/op) [
>>> 7,90,      7,71]
>>>
>>> #
>>> # FillArrayUnsafe: run duration:  5 000 ms, #of logical CPUS: 4
>>> #
>>> # Warm up:
>>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =     26,82 ns/op (? =   0,00 ns/op) [
>>>   26,82]
>>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =     23,48 ns/op (? =   0,00 ns/op) [
>>>   23,48]
>>> # Measure:
>>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =     22,42 ns/op (? =   0,00 ns/op) [
>>>   22,42]
>>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             2 threads, Tavg =     28,21 ns/op (? =   0,88 ns/op) [
>>>   29,11,     27,36]
>>>
>>> Testing arrays: int[100]...
>>> #
>>> # ZeroFill: run duration:  5 000 ms, #of logical CPUS: 4
>>> #
>>> # Warm up:
>>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =     16,49 ns/op (? =   0,00 ns/op) [
>>>   16,49]
>>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =     15,97 ns/op (? =   0,00 ns/op) [
>>>   15,97]
>>> # Measure:
>>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =     16,03 ns/op (? =   0,00 ns/op) [
>>>   16,03]
>>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             2 threads, Tavg =     19,32 ns/op (? =   0,46 ns/op) [
>>>   18,87,     19,80]
>>>
>>> #
>>> # FillArraySystemCopy: run duration:  5 000 ms, #of logical CPUS: 4
>>> #
>>> # Warm up:
>>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =     14,51 ns/op (? =   0,00 ns/op) [
>>>   14,51]
>>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =     14,17 ns/op (? =   0,00 ns/op) [
>>>   14,17]
>>> # Measure:
>>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =     14,09 ns/op (? =   0,00 ns/op) [
>>>   14,09]
>>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             2 threads, Tavg =     31,15 ns/op (? =   4,04 ns/op) [
>>>   27,65,     35,67]
>>>
>>> #
>>> # FillArrayUnsafe: run duration:  5 000 ms, #of logical CPUS: 4
>>> #
>>> # Warm up:
>>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =     52,32 ns/op (? =   0,00 ns/op) [
>>>   52,32]
>>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =     52,82 ns/op (? =   0,00 ns/op) [
>>>   52,82]
>>> # Measure:
>>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =     52,19 ns/op (? =   0,00 ns/op) [
>>>   52,19]
>>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             2 threads, Tavg =     70,87 ns/op (? =   0,71 ns/op) [
>>>   70,17,     71,59]
>>>
>>> Testing arrays: int[10000]...
>>> #
>>> # ZeroFill: run duration:  5 000 ms, #of logical CPUS: 4
>>> #
>>> # Warm up:
>>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =  1 208,64 ns/op (? =   0,00 ns/op) [ 1
>>> 208,64]
>>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =  1 238,01 ns/op (? =   0,00 ns/op) [ 1
>>> 238,01]
>>> # Measure:
>>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =  1 235,81 ns/op (? =   0,00 ns/op) [ 1
>>> 235,81]
>>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             2 threads, Tavg =  1 325,11 ns/op (? =   7,01 ns/op) [ 1
>>> 332,16,  1 318,14]
>>>
>>> #
>>> # FillArraySystemCopy: run duration:  5 000 ms, #of logical CPUS: 4
>>> #
>>> # Warm up:
>>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =  1 930,93 ns/op (? =   0,00 ns/op) [ 1
>>> 930,93]
>>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =  2 060,80 ns/op (? =   0,00 ns/op) [ 2
>>> 060,80]
>>> # Measure:
>>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =  2 105,21 ns/op (? =   0,00 ns/op) [ 2
>>> 105,21]
>>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             2 threads, Tavg =  2 160,33 ns/op (? =  13,74 ns/op) [ 2
>>> 146,68,  2 174,15]
>>>
>>> #
>>> # FillArrayUnsafe: run duration:  5 000 ms, #of logical CPUS: 4
>>> #
>>> # Warm up:
>>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =  3 099,50 ns/op (? =   0,00 ns/op) [ 3
>>> 099,50]
>>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =  3 041,81 ns/op (? =   0,00 ns/op) [ 3
>>> 041,81]
>>> # Measure:
>>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =  3 068,34 ns/op (? =   0,00 ns/op) [ 3
>>> 068,34]
>>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             2 threads, Tavg =  3 296,13 ns/op (? =  34,97 ns/op) [ 3
>>> 331,47,  3 261,53]
>>>
>>>
>>> PS: java.awt.geom.Path2D has also memory allocation issues:
>>>          void needRoom(boolean needMove, int newCoords) {
>>>              if (needMove && numTypes == 0) {
>>> throw new IllegalPathStateException("**missing initial moveto "+
>>> "in path definition");
>>>              }
>>>              int size = pointTypes.length;
>>>              if (numTypes >= size) {
>>> int grow = size;
>>>                  if (grow > EXPAND_MAX) {
>>> grow = EXPAND_MAX;
>>>                  }
>>> pointTypes = Arrays.copyOf(pointTypes, size+grow);
>>>              }
>>>              size = floatCoords.length;
>>>              if (numCoords + newCoords > size) {
>>> int grow = size;
>>>                  if (grow > EXPAND_MAX * 2) {
>>> grow = EXPAND_MAX * 2;
>>>                  }
>>>                  if (grow < newCoords) {
>>> grow = newCoords;
>>>                  }
>>> floatCoords = Arrays.copyOf(floatCoords, size+grow);
>>>              }
>>>          }
>>>
>>> Best regards,
>>> Laurent
>>>
>>
>>


From andrea.aime at geo-solutions.it  Sat Mar 30 10:45:29 2013
From: andrea.aime at geo-solutions.it (Andrea Aime)
Date: Sat, 30 Mar 2013 11:45:29 +0100
Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
In-Reply-To: 
References: 
	
	<51506136.4020909@oracle.com> <51508139.9000507@oracle.com>
	
	<51549C3F.1020301@oracle.com>
	
	<5154ACCD.5090105@oracle.com>
	
	
Message-ID: 

On Fri, Mar 29, 2013 at 3:16 PM, Laurent Bourg?s
wrote:

> Andrea,
>
> It could be very interesting if you could provide some concrete example
> about your map server: typical image height / width, shape complexity
> (number, size, path sizes ...).
>

It's all over the place. Image size: from 256x256 to 10000x10000, number of
shapes, from a few hundreds to a few millions, path sizes, from say 10
points
to thousands (the code already makes sure there are no two consequent
points sitting in the same pixel before trying to draw them),
stroke wise it can be simple or using dasharrays.


>
> Ideally if you could write a test class (sample) computing a single image
> it would be very helpful for me to compare my patched pisces vs current one.
>

I don't have anything ready, the existing code loads data from spatial
database, sets up styles from XML descriptions, turns each spatial db
geomety in java shapes
and so on. But I guess I could concoct something close enough.
I'm writing some code to gather statistics about the shapes that are
actually painted (scrolling over the path iterators) and then I'll try to
make a randomized
shape painter that gets close to those stats.

Cheers
Andrea

-- 
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------


From vladimir.voskresensky at oracle.com  Sat Mar 30 11:03:51 2013
From: vladimir.voskresensky at oracle.com (Vladimir Voskresensky)
Date: Sat, 30 Mar 2013 15:03:51 +0400
Subject: RFR: Project files for Solaris Studio / NetBeans
In-Reply-To: <51531883.7070903@oracle.com>
References: <51507B60.6030809@oracle.com> <51531883.7070903@oracle.com>
Message-ID: <5156C697.8060003@oracle.com>

Jesper,

It looks good and works for me on Linux_64.

Some comments for others:
before running IDE specify IDE_JAVAPATH env variable if want to navigate 
into some java/include files (value is the same as previously was known 
as ALT_BOOTDIR):
#export IDE_JAVAPATH=/opt/jdk/latest7
after opening project, make sure you are switched to Linux configuration

Thanks!
Vladimir.

On 03/27/2013 08:04 PM, Jesper Wilhelmsson wrote:
> Hi,
>
> A new webrev is now available. The issues reported from the first 
> review should be fixed and the project now contains configurations for 
> both Linux_64 and Mac_64.
>
> To select configuration there is a dropdown menu next to the build 
> button.
>
> http://cr.openjdk.java.net/~jwilhelm/7074926/webrev.2/
>
> Thanks,
> /Jesper
>
>
> Jesper Wilhelmsson skrev 25/3/13 5:29 PM:
>> Hi,
>>
>> Sorry for cross posting, but I think this could be useful for several 
>> areas.
>>
>> I would like to add Solaris Studio / NetBeans project files for the 
>> entire
>> OpenJDK project. To clarify: One project that contains the entire 
>> OpenJDK.
>>
>>
>> With the new build infrastructure in JDK 8 building the entire 
>> OpenJDK is fairly
>> fast and even though I personally mostly work in the HotSpot tree, I 
>> tend to
>> always clone and build the entire JDK forest. I find this to have 
>> several benefits.
>>
>> Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/
>>
>> The configuration in this project is currently Mac only. Linux and 
>> Solaris
>> configurations are also planned.
>>
>> The webrev is made from the jdk8/build repository which is where I 
>> think a
>> change like this should go in. Let me know if you think something else.
>>
>>
>>
>> To use this project (once pushed):
>>
>> 1. Clone your favorite repository
>>     hg clone http://hg.openjdk.java.net/hsx/hotspot-gc
>>
>> 2. Get the whole forest
>>     cd hotspot-gc
>>     sh get_source.sh
>>
>> 3. Configure
>>     sh configure
>>
>> 4. Open Solaris studio / NetBeans and load the project.
>>     The project in located in the common directory.
>>
>>
>> Thanks,
>> /Jesper



From andrea.aime at geo-solutions.it  Sat Mar 30 19:23:40 2013
From: andrea.aime at geo-solutions.it (Andrea Aime)
Date: Sat, 30 Mar 2013 20:23:40 +0100
Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
In-Reply-To: 
References: 
	
	<51506136.4020909@oracle.com> <51508139.9000507@oracle.com>
	
	<51549C3F.1020301@oracle.com>
	
	<5154ACCD.5090105@oracle.com>
	
	
	
	
Message-ID: 

On Sat, Mar 30, 2013 at 2:01 PM, Laurent Bourg?s
wrote:

> - clipping issues (dasher, stroker) and spatial resolution (no cpu/memory
> waste)
>

I see, yes. Indeed in the GeoServer code we already work around some of
those issues by
clipping the geometries read from the database to the graphics2d viewport
before giving them
to the renderer, we had to do that both for performance issues and to avoid
OOM errors
when basic stroke with dasharray is used against a line that is many times
longer than the
current display area


> I don't have anything ready, the existing code loads data from spatial
>> database, sets up styles from XML descriptions, turns each spatial db
>> geomety in java shapes
>> and so on. But I guess I could concoct something close enough.
>> I'm writing some code to gather statistics about the shapes that are
>> actually painted (scrolling over the path iterators) and then I'll try to
>> make a randomized
>> shape painter that gets close to those stats.
>>
>
> Great news ! I am waiting your test code to perform few benchmarks.
>
> I am using J2DBench but it does not perform such complex drawing (complex
> shapes ...) or multi threading tests (parallel drawings on buffered images)
>

Ok, I've created a "MapBench" by serializing shapes, strokes and fills from
a real GeoServer instance to disk, and have them
play in a simple multithreaded test harness.
What you get in the output is not exactly the maps generated by GeoServer
since we use a number of tricks to speed up rendering,
including painting over multiple drawing surfaces (the serializer only
handles one), also, some maps have text showing up because
in order to pain "labels along a line" we actually turn the chars into
shapes and place them along the line, but those labels that we
can predict are "straight" are painted with drawGlyphVector so they won't
show up (haven't built a serialization for that case).

Regardless, the test should be good enough to test both performance and
scalability.
Here is the package: http://demo.geo-solutions.it/share/mapbench.zip

It contains:
* ShapeDumpingGraphics2D, a Graphics2D wrapper writing on disk all
draw(Shape) and
  fill(Shape) commands issued to it
* A bunch of *.ser files, that are the serialized drawing command sequences
* A bunch of *.png files, which are the rendered versions of the .ser files
(for reference)
* MapDisplay, which reads all *.ser files from a directory and displays
them in JFrame and
   generates the .png files as well
* MapBench, which reads all *.ser files from a directory and repeatedly
paints them in a loop
  with a growing number of threads
* Two txt files with the timings of the benchmarks on my machine for Oracle
JDK 7 and
   OpenJDK 7, here is an example comparison:

OpenJDK7:
Testing file /tmp/dc_boulder_2013-13-30-06-13-17.ser
1 threads and 20 loops per thread, time: 3340 ms
2 threads and 20 loops per thread, time: 3688 ms
4 threads and 20 loops per thread, time: 4665 ms
8 threads and 20 loops per thread, time: 7343 ms

Oracle JDK 7:
Warm up took 29516 ms
Testing file /tmp/dc_boulder_2013-13-30-06-13-17.ser
1 threads and 20 loops per thread, time: 1754 ms
2 threads and 20 loops per thread, time: 2878 ms
4 threads and 20 loops per thread, time: 6792 ms
8 threads and 20 loops per thread, time: 14275 ms

As you can see ductus is significantly faster than pisces, but it has
serious scalability
issues, while pisces scales up a lot better.

The code has been put together in a haste, sorry for the lack of comments,
hopefully it is
simple enough that it's usable anyways.

Cheers
Andrea


-- 
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------