From martinrb at google.com Fri Feb 1 02:23:08 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 31 Jan 2013 18:23:08 -0800 Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code In-Reply-To: <510ACEFC.2060607@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> Message-ID: You could operate in paranoid mode and do *both* : use O_CLOEXEC and use fcntl to set the bit after creating it, perhaps after verifying via fcntl whether the bit was successfully set by open. Martin On Thu, Jan 31, 2013 at 12:07 PM, Dan Xu wrote: > Hi Karen, > > In my opinion, it is recommemded to use O_CLOEXEC flag directly in open() > function than setting it later via fcntl(). And according to the man page > on Solaris and Mac, open() behaves the same on those platforms. > > I only find the support platform list for jdk7 at http://www.oracle.com/** > technetwork/java/javase/**config-417990.html. > Because Linux 2.6.23 was released long ago on Oct 9, 2007, most platforms > should already have the support to O_CLOEXEC flag. > > Thanks, > > -Dan > > > > On 01/31/2013 07:30 AM, Karen Kinnear wrote: > >> Dan, >> >> I had a question on this comment. >> >> Should we fix this in hotspot? >> >> So you mention recent Linux open() documentation. >> How does this behave on Solaris and Mac? I assume the library code is >> shared code across platforms. >> Also - what is the oldest Linux we support for JDK8? >> >> thanks, >> Karen >> >> On Jan 29, 2013, at 6:55 AM, Alan Bateman wrote: >> >> >>> >>>> >>>>> - I don't think the O_CLOEXEC code is needed in handleOpen, was this >>>>> copied from HotSpot? >>>>> >>>> In the original hotspot code, it has one section to enable the >>>> close-on-exec flag for the new file descriptor as the following. >>>> >>>> #ifdef FD_CLOEXEC >>>> { >>>> int flags = ::fcntl(fd, F_GETFD); >>>> if (flags != -1) >>>> ::fcntl(fd, F_SETFD, flags | FD_CLOEXEC); >>>> } >>>> #endif >>>> >>>> According to the comment, "All file descriptors that are opened in the >>>> JVM and not specifically destined for a subprocess should have the >>>> close-on-exec flag set. If we don't set it, then careless 3rd party native >>>> code might fork and exec without closing all appropriate file descriptors >>>> (e.g. as we do in closeDescriptors in UNIXProcess.c), and this in turn >>>> might: >>>> - cause end-of-file to fail to be detected on some file >>>> descriptors, resulting in mysterious hangs, or >>>> - might cause an fopen in the subprocess to fail on a system >>>> suffering from bug 1085341." >>>> >>>> And the recent open() function (since Linux 2.6.23) already has >>>> O_CLOSEXEC flag to enable this flag by default. And it is a preferred way >>>> according to the man page, " Specifying this flag permits a program to >>>> avoid additional fcntl(2) F_SETFD operations to set the FD_CLOEXEC flag. >>>> Addi-tionally, use of this flag is essential in some multithreaded >>>> programs since using a separate fcntl(2) F_SETFD operation to set the >>>> FD_CLOEXEC flag does not suffice to avoid race conditions where one thread >>>> opens a file descriptor at the same time as another thread does a >>>> fork(2) plus execve(2). >>>> Additionally, if O_CLOEXEC is not supported, F_DUPFD_CLOEXEC is >>>> preferred than FD_CLOEXEC, which is what hotspot is using right now. >>>> >>> I don't think we need this because the file descriptor will be closed at >>> exec time anyway (there is logic in Runtime.exec to iterate over the file >>> descriptors and close them). Also we don't do this in other areas of the >>> platform where we use open directly. >>> >>> >>>> >> > From joe.darcy at oracle.com Fri Feb 1 02:58:28 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 01 Feb 2013 02:58:28 +0000 Subject: hg: jdk8/tl/langtools: 8007351: Malformed copyright statements in typeAnnotations test directory Message-ID: <20130201025835.C022847725@hg.openjdk.java.net> Changeset: bec996065c45 Author: darcy Date: 2013-01-31 18:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bec996065c45 8007351: Malformed copyright statements in typeAnnotations test directory Reviewed-by: jjg ! test/tools/javac/annotations/typeAnnotations/TargetTypes.java ! test/tools/javac/annotations/typeAnnotations/TypeProcOnly.java ! test/tools/javac/annotations/typeAnnotations/api/AnnotatedArrayOrder.java ! test/tools/javac/annotations/typeAnnotations/api/ArrayCreationTree.java ! test/tools/javac/annotations/typeAnnotations/api/ArrayPositionConsistency.java ! test/tools/javac/annotations/typeAnnotations/classfile/ClassfileTestHelper.java ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest1.java ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java ! test/tools/javac/annotations/typeAnnotations/classfile/NewTypeArguments.java ! test/tools/javac/annotations/typeAnnotations/classfile/NoTargetAnnotations.java ! test/tools/javac/annotations/typeAnnotations/classfile/TypeCasts.java ! test/tools/javac/annotations/typeAnnotations/classfile/Wildcards.java ! test/tools/javac/annotations/typeAnnotations/failures/target/DotClass.java ! test/tools/javac/annotations/typeAnnotations/newlocations/Varargs.java ! test/tools/javac/annotations/typeAnnotations/packageanno/PackageProcessor.java ! test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/Anno.java ! test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/MyClass.java ! test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/package-info.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/ClassExtends.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/ClassTypeParam.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Constructors.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Driver.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/ExceptionParameters.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Fields.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/FromSpecification.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodParameters.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodReceivers.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodReturns.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodThrows.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodTypeParam.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MultiCatch.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/NestedTypes.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/NewObjects.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/ReferenceInfoUtil.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/RepeatingTypeAnnotations.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/TypeCasts.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/TypeTests.java From jonathan.gibbons at oracle.com Fri Feb 1 03:19:45 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 01 Feb 2013 03:19:45 +0000 Subject: hg: jdk8/tl/langtools: 8007329: minor issues in impl class hierarchry for DCTree.* classes Message-ID: <20130201031952.A6EA947727@hg.openjdk.java.net> Changeset: 3ab64e4293a1 Author: jjg Date: 2013-01-31 19:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3ab64e4293a1 8007329: minor issues in impl class hierarchry for DCTree.* classes Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/tree/DCTree.java From joe.darcy at oracle.com Fri Feb 1 03:21:47 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 31 Jan 2013 19:21:47 -0800 Subject: Code review request for 8007113 Upgrade AnnotatedElement.isAnnotionPresent to be a default method Message-ID: <510B34CB.5070009@oracle.com> Hello, I'd like to upgrade the existing AnnotatedElement.isAnnotationPresent interface method to a default method: 8007113 Upgrade AnnotatedElement.isAnnotionPresent to be a default method http://cr.openjdk.java.net/~darcy/8007113.0/ This ends up removing several copies of the same logic in the JDK; all reflection and annotations regression test pass with this change. Thanks, -Joe From kumar.x.srinivasan at oracle.com Fri Feb 1 03:32:46 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 31 Jan 2013 19:32:46 -0800 Subject: RFR: 8006536: [launcher] removes trailing slashes on arguments Message-ID: <510B375E.9010701@oracle.com> Hi Akhil, Jayashree, Please verify, I have modified the tests. http://cr.openjdk.java.net/~ksrini/8006536/webrev.0/ Thanks Kumar From jonathan.gibbons at oracle.com Fri Feb 1 03:32:09 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 01 Feb 2013 03:32:09 +0000 Subject: hg: jdk8/tl/langtools: 8004353: Generated html is wrong for overview.html; content has incorrect css footer class Message-ID: <20130201033217.1C1094772D@hg.openjdk.java.net> Changeset: 3d97a9a7a82b Author: jjg Date: 2013-01-31 19:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3d97a9a7a82b 8004353: Generated html is wrong for overview.html; content has incorrect css footer class Reviewed-by: jjg Contributed-by: roger.riggs at oracle.com ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java From david.holmes at oracle.com Fri Feb 1 04:01:27 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 01 Feb 2013 14:01:27 +1000 Subject: WITHDRAWN Re: Proposal: Fully Concurrent ClassLoading In-Reply-To: <510A6C8B.60701@gmail.com> References: <50BF371A.1060604@oracle.com> <510A38BB.3090103@oracle.com> <510A6C8B.60701@gmail.com> Message-ID: <510B3E17.3050104@oracle.com> Hi Peter, On 31/01/2013 11:07 PM, Peter Levart wrote: > Hi David, > > Could the parallel classloading be at least space optimized somehow in > the JDK8 timeframe if there was a solution ready? If there is something that does not impact any of the existing specified semantics regarding the classloader lock object then it may be possible to work it into an 8 update if not 8 itself. But all the suggestions I've seen for reducing the memory usage also alter the semantics in someway. However, a key part of the concurrent classloader proposal was that it didn't change the behaviour of any existing classloaders outside the core JDK. Anything that changes existing behaviour has a much higher compatibility bar to get over. David ----- > Regards, Peter > > On 01/31/2013 10:26 AM, David Holmes wrote: >> Regretfully this proposal has to be withdrawn from Java 8. The VM >> facilities that this depends upon have not been specified formally and >> so an update to the Java Virtual Machine Specification (JVMS) and >> further updates to the ClassLoader.defineClass method are required. >> There was simply no time to get this work specified and completed >> before the M6 milestone - taking into account other constraints (ie >> people and time). Further, testing has indicated that there may be >> some further issues to work out in the VM's "parallel defineClass" path. >> >> I plan to submit a new JEP for this and work on it for Java 9. >> >> David Holmes >> ------------ >> >> On 5/12/2012 9:59 PM, David Holmes wrote: >>> Java 7 introduced support for parallel classloading by adding to each >>> class loader a ConcurrentHashMap, referenced through a new field, >>> parallelLockMap. This contains a mapping from class names to Objects to >>> use as a classloading lock for that class name. This scheme has a number >>> of inefficiencies. To address this we propose for Java 8 the notion of a >>> fully concurrent classloader ... >>> >>> This is a fairly simple proposal that I've written up as a blog entry: >>> >>> https://blogs.oracle.com/dholmes/entry/parallel_classloading_revisited_fully_concurrent >>> >>> >>> >>> Please discuss this proposal here. >>> >>> Thanks, >>> David Holmes >>> > From akhil.arora at oracle.com Fri Feb 1 04:57:14 2013 From: akhil.arora at oracle.com (Akhil Arora) Date: Thu, 31 Jan 2013 20:57:14 -0800 Subject: RFR: 8006536: [launcher] removes trailing slashes on arguments In-Reply-To: <510B375E.9010701@oracle.com> References: <510B375E.9010701@oracle.com> Message-ID: <510B4B2A.5040602@oracle.com> looks good On 01/31/2013 07:32 PM, Kumar Srinivasan wrote: > Hi Akhil, Jayashree, > > Please verify, I have modified the tests. > > http://cr.openjdk.java.net/~ksrini/8006536/webrev.0/ > > > Thanks > Kumar From jviswana at linux.vnet.ibm.com Fri Feb 1 05:41:12 2013 From: jviswana at linux.vnet.ibm.com (jayashree viswanathan) Date: Fri, 01 Feb 2013 11:11:12 +0530 Subject: RFR: 8006536: [launcher] removes trailing slashes on arguments In-Reply-To: <510B4B2A.5040602@oracle.com> References: <510B375E.9010701@oracle.com> <510B4B2A.5040602@oracle.com> Message-ID: <510B5578.5030809@linux.vnet.ibm.com> On 01-02-2013 10:27 AM, Akhil Arora wrote: > looks good > > On 01/31/2013 07:32 PM, Kumar Srinivasan wrote: >> Hi Akhil, Jayashree, >> >> Please verify, I have modified the tests. >> >> http://cr.openjdk.java.net/~ksrini/8006536/webrev.0/ >> >> >> Thanks >> Kumar > Hi Kumar, The change looks good . Thanks a lot for picking up the fix and making the additional test changes . On a side note , It would still be helpful to know how the C test is being run,Can you please let me know is there any specific C test infrastructure ? Regards, Jayashree viswanathan From chris.hegarty at oracle.com Fri Feb 1 06:53:50 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 01 Feb 2013 06:53:50 +0000 Subject: hg: jdk8/tl/jdk: 8006395: Race in async socket close on Linux Message-ID: <20130201065420.448C84773A@hg.openjdk.java.net> Changeset: 17b643956999 Author: chegar Date: 2013-02-01 06:51 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/17b643956999 8006395: Race in async socket close on Linux Reviewed-by: alanb, dsamersoff ! src/solaris/native/java/net/linux_close.c + test/java/net/Socket/asyncClose/Race.java From chris.hegarty at oracle.com Fri Feb 1 07:08:48 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 01 Feb 2013 07:08:48 +0000 Subject: Code review request for 8007113 Upgrade AnnotatedElement.isAnnotionPresent to be a default method In-Reply-To: <510B34CB.5070009@oracle.com> References: <510B34CB.5070009@oracle.com> Message-ID: <510B6A00.9070309@oracle.com> Joe, This looks good to me Joe, and I like that the default method spells out its implementation. Out of curiosity, strictly speaking is this considered a specification change? Since the public override methods no longer exist in the concrete classes. -Chris. On 02/01/2013 03:21 AM, Joe Darcy wrote: > Hello, > > I'd like to upgrade the existing AnnotatedElement.isAnnotationPresent > interface method to a default method: > > 8007113 Upgrade AnnotatedElement.isAnnotionPresent to be a default > method > http://cr.openjdk.java.net/~darcy/8007113.0/ > > This ends up removing several copies of the same logic in the JDK; all > reflection and annotations regression test pass with this change. > > Thanks, > > -Joe From joe.darcy at oracle.com Fri Feb 1 07:18:35 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 31 Jan 2013 23:18:35 -0800 Subject: Code review request for 8007113 Upgrade AnnotatedElement.isAnnotionPresent to be a default method In-Reply-To: <510B6A00.9070309@oracle.com> References: <510B34CB.5070009@oracle.com> <510B6A00.9070309@oracle.com> Message-ID: <510B6C4B.9060607@oracle.com> Hi Chris, On 01/31/2013 11:08 PM, Chris Hegarty wrote: > Joe, > > This looks good to me Joe, and I like that the default method spells > out its implementation. > > Out of curiosity, strictly speaking is this considered a specification > change? Since the public override methods no longer exist in the > concrete classes. The specification change here is the default-ness of the isAnnotationPresent method in AnnotatedElement; that delta will be covered by JCK signature tests. Putting aside how the classes implementing AnnotatedElement look via core reflection, the set of methods in the implementations of AnnotatedElement and their behavior at runtime will be unchanged so that aspects of the fix is not a specification change. Preserving the details of the core reflection view is generally outside of our compatibility contract for java SE; this change should be fully source and binary compatible. Thanks for the review, -Joe > > -Chris. > > On 02/01/2013 03:21 AM, Joe Darcy wrote: >> Hello, >> >> I'd like to upgrade the existing AnnotatedElement.isAnnotationPresent >> interface method to a default method: >> >> 8007113 Upgrade AnnotatedElement.isAnnotionPresent to be a default >> method >> http://cr.openjdk.java.net/~darcy/8007113.0/ >> >> This ends up removing several copies of the same logic in the JDK; all >> reflection and annotations regression test pass with this change. >> >> Thanks, >> >> -Joe From xueming.shen at oracle.com Fri Feb 1 07:37:59 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 31 Jan 2013 23:37:59 -0800 Subject: [Base64] Codereview request for 8006315 8006530 Message-ID: <510B70D7.2040702@oracle.com> Hi, This is the webrev for 8006530: Base64.getMimeDecoder().decode() throws exception for non-base64 character after adding = 8006315: Base64.Decoder decoding methods are not consistent in treating non-padded data http://cr.openjdk.java.net/~sherman/8006315_8006530/webrev The change is to (1) explicitly specify line feed is not added to the end of mime encoded output (no surprise) (2) mime decoder now ignores any non-base64 character after padding = (same as it ignores those non-base64 character within the data (mime base64 spec). Convenient for use case like a padding \n at the end of any input data from the file and, as suggested from real base64 use case. (3) explicitly specify padding character at the end of the base64 encoded data is optional when DECODING (encoder always adds padding character = when necessary). The "decoding" part of the RFC really does not make it a MUST, so be liberal. (4) update the decoder inputstream to behave the same way other decoders do, to accept AA and AAA same as AA== AAA=. Please help review. -Sherman From chris.hegarty at oracle.com Fri Feb 1 09:30:41 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 01 Feb 2013 09:30:41 +0000 Subject: [Base64] Codereview request for 8006315 8006530 In-Reply-To: <510B70D7.2040702@oracle.com> References: <510B70D7.2040702@oracle.com> Message-ID: <510B8B41.4010505@oracle.com> The spec clarifications look good to me, and will be much more user friendly. Trivially, this is the first mention of padding in the API, "Base64 padding character", should this be qualified as '='? Or maybe, this is just another case of deferring to the "The Base64 Alphabet" in the rfc. The test seems inconsistent with the spec clarification, "The Base64 padding character is accepted and interpreted as the end of the encoded byte data" + checkEqual(decM.decode(encoded), src[i], "Non-base64 char is not ignored"); + try { + dec.decode(encoded); + throw new RuntimeException("No IAE for non-base64 char"); + } catch (IllegalArgumentException iae) {} Why, in the case of src input "A" would you expect the mime decoder to ignore the trailing character, and not the Basic decoder? -Chris. On 01/02/2013 07:37, Xueming Shen wrote: > Hi, > > This is the webrev for > > 8006530: Base64.getMimeDecoder().decode() throws exception for > non-base64 character after adding = > 8006315: Base64.Decoder decoding methods are not consistent in treating > non-padded data > > http://cr.openjdk.java.net/~sherman/8006315_8006530/webrev > > The change is to > > (1) explicitly specify line feed is not added to the end of mime encoded > output (no surprise) > > (2) mime decoder now ignores any non-base64 character after padding = > (same as it > ignores those non-base64 character within the data (mime base64 spec). > Convenient > for use case like a padding \n at the end of any input data from the > file and, as suggested > from real base64 use case. > > (3) explicitly specify padding character at the end of the base64 > encoded data is > optional when DECODING (encoder always adds padding character = when > necessary). > The "decoding" part of the RFC really does not make it a MUST, so be > liberal. > > (4) update the decoder inputstream to behave the same way other decoders > do, to > accept AA and AAA same as AA== AAA=. > > Please help review. > > -Sherman From chris.hegarty at oracle.com Fri Feb 1 09:33:13 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 01 Feb 2013 09:33:13 +0000 Subject: Code review request for 8007113 Upgrade AnnotatedElement.isAnnotionPresent to be a default method In-Reply-To: <510B6C4B.9060607@oracle.com> References: <510B34CB.5070009@oracle.com> <510B6A00.9070309@oracle.com> <510B6C4B.9060607@oracle.com> Message-ID: <510B8BD9.80009@oracle.com> On 01/02/2013 07:18, Joe Darcy wrote: > Hi Chris, > > On 01/31/2013 11:08 PM, Chris Hegarty wrote: >> Joe, >> >> This looks good to me Joe, and I like that the default method spells >> out its implementation. >> >> Out of curiosity, strictly speaking is this considered a specification >> change? Since the public override methods no longer exist in the >> concrete classes. > > The specification change here is the default-ness of the > isAnnotationPresent method in AnnotatedElement; that delta will be > covered by JCK signature tests. Putting aside how the classes > implementing AnnotatedElement look via core reflection, the set of > methods in the implementations of AnnotatedElement and their behavior at > runtime will be unchanged so that aspects of the fix is not a > specification change. Preserving the details of the core reflection view > is generally outside of our compatibility contract for java SE; Ah ha, thank you for the explanation. Makes sense. -Chris. > this change should be fully source and binary compatible. > > Thanks for the review, > > -Joe > >> >> -Chris. >> >> On 02/01/2013 03:21 AM, Joe Darcy wrote: >>> Hello, >>> >>> I'd like to upgrade the existing AnnotatedElement.isAnnotationPresent >>> interface method to a default method: >>> >>> 8007113 Upgrade AnnotatedElement.isAnnotionPresent to be a default >>> method >>> http://cr.openjdk.java.net/~darcy/8007113.0/ >>> >>> This ends up removing several copies of the same logic in the JDK; all >>> reflection and annotations regression test pass with this change. >>> >>> Thanks, >>> >>> -Joe > From Alan.Bateman at oracle.com Fri Feb 1 09:34:53 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 01 Feb 2013 09:34:53 +0000 Subject: Codereview request for 8006295: Base64.Decoder.wrap(java.io.InputStream) returns InputStream which throws unspecified IOException on attempt to decode invalid Base64 byte stream In-Reply-To: <510AECEE.7060908@oracle.com> References: <510AECEE.7060908@oracle.com> Message-ID: <510B8C3D.2070306@oracle.com> On 31/01/2013 22:15, Xueming Shen wrote: > Hi, > > Obviously ioe is not an appropriate exception for invalid base64 bytes, > and it's inconsistent with the rest of decode methods, as the submitter > suggested. > The change is to explicitly specify (as other decoding methods do) that > IAE will be thrown if the input stream contains invalid base64 bytes. The > impl is also updated according. > > Please help review. > > http://cr.openjdk.java.net/~sherman/8006295/webrev/ I don't think IAE is right here as the problem is not with the argument passed to the InputStream read method. The simplest thing is probably to just make it clear in the wrap's javadoc that the reading from the InputStream will throw IOException if bytes, that are not in a valid base64 scheme, are encountered. This would be consistent with say, reading from a BufferedReader where malformed or unmappable characters are encountered (assuming it is created with a charset decoder that is configured to report errors of course). -Alan From Alan.Bateman at oracle.com Fri Feb 1 09:43:00 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 01 Feb 2013 09:43:00 +0000 Subject: Codereview request for 8006295: Base64.Decoder.wrap(java.io.InputStream) returns InputStream which throws unspecified IOException on attempt to decode invalid Base64 byte stream In-Reply-To: <510AFC41.3000209@oracle.com> References: <510AECEE.7060908@oracle.com> <0E058F43-187E-4AD0-B28C-815565584B72@oracle.com> <510AF656.5040800@oracle.com> <510AFC41.3000209@oracle.com> Message-ID: <510B8E24.1030105@oracle.com> On 31/01/2013 23:20, Xueming Shen wrote: > > Any opinion of an ioe based specific InvalidedBase64BytesException > is more appropriate/preferred/desired in this kinda of situation? The > argument against the IAE is probably that an IAE may be a surprise > for someone working on inputstream.read(). > > -Sherman I just replied to your original mail, as IAE doesn't make sense here. I guess the question on whether you need a specialized exception comes down to whether it would be useful to take recovery action that would be different to other I/O exceptions that might happen. If we don't have good use-cases then it's probably not worth doing it now, it is always something that could be added later if really needed (as it shouldn't break anyone to throw a more specific exception in the future). -Alan From edvard.wendelin at oracle.com Fri Feb 1 09:43:43 2013 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Fri, 1 Feb 2013 10:43:43 +0100 Subject: Request for review: 8006757: Refactor Socket and File I/O tracing In-Reply-To: <51013915.5080305@oracle.com> References: <51013915.5080305@oracle.com> Message-ID: <84744621-EE79-4F20-954D-D8ECE8C93BA1@oracle.com> Approved, given that Alan reviewed it on the core-libs alias. /Edvard On Jan 24, 2013, at 2:37 PM, Claes Redestad wrote: > Hi all, > > this is a refactoring of the I/O trace instrumentation that's going into JDK > 7u14. The fix is only applicable to jdk7 since the corresponding code does not yet > exist in jdk8. > > Bug: 8006757: Refactor Socket and File I/O tracing > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006757 > > Description: By moving all parameters to the xxEnd-methods in IoTrace, we can defer > evaluation/object allocations until we know events will be written, which may reduce > the overhead of enabling these events. > > Webrev: > http://cr.openjdk.java.net/~sla/clredest/8006757/ > > Thanks! > > /Claes > From joel.franck at oracle.com Fri Feb 1 09:47:04 2013 From: joel.franck at oracle.com (=?ISO-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Fri, 01 Feb 2013 10:47:04 +0100 Subject: Code review request for 8007113 Upgrade AnnotatedElement.isAnnotionPresent to be a default method In-Reply-To: <510B34CB.5070009@oracle.com> References: <510B34CB.5070009@oracle.com> Message-ID: <510B8F18.3010905@oracle.com> Hi Joe, On 02/01/2013 04:21 AM, Joe Darcy wrote: > Hello, > > I'd like to upgrade the existing AnnotatedElement.isAnnotationPresent > interface method to a default method: > > 8007113 Upgrade AnnotatedElement.isAnnotionPresent to be a default method > http://cr.openjdk.java.net/~darcy/8007113.0/ > How about sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java ? It looks like I forgot to update that one when I did the type annotations changes :) cheers /Joel From Alan.Bateman at oracle.com Fri Feb 1 09:51:07 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 01 Feb 2013 09:51:07 +0000 Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code In-Reply-To: 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> Message-ID: <510B900B.1030406@oracle.com> On 01/02/2013 02:23, Martin Buchholz wrote: > You could operate in paranoid mode and do *both* : use O_CLOEXEC and use > fcntl to set the bit after creating it, perhaps after verifying via fcntl > whether the bit was successfully set by open. > > Martin > > Alternatively, just leave this code out. We open sockets and files in many other places in the libraries and don't explicitly enable the close-on-exec flag (we do set the inheritance flag on Windows so I guess we do have an inconsistency). Anyway, my point is that the Process code already handles this and closes the file descriptors in the child so I assume it doesn't matter if we have enabled the close-on-exec flag or not. There might of course be applications or other libraries that use fork+exec or variants directly, in which case there will be an issue if they expect all file descriptors to have the close-on-exec flag set. However, I assume we have this issue already as we just enable it consistently. -Alan. From pdoubleya at gmail.com Fri Feb 1 10:14:22 2013 From: pdoubleya at gmail.com (Patrick Wright) Date: Fri, 1 Feb 2013 11:14:22 +0100 Subject: Codereview request for 8006295: Base64.Decoder.wrap(java.io.InputStream) returns InputStream which throws unspecified IOException on attempt to decode invalid Base64 byte stream In-Reply-To: <510B8E24.1030105@oracle.com> References: <510AECEE.7060908@oracle.com> <0E058F43-187E-4AD0-B28C-815565584B72@oracle.com> <510AF656.5040800@oracle.com> <510AFC41.3000209@oracle.com> <510B8E24.1030105@oracle.com> Message-ID: Would it be appropriate to have a "format" exception extending RuntimeException? That could then be documented in the API, but optional to catch explicitly. "Format exceptions", as a name, are already used for converting numbers and dates, for example. It could be "upgraded" to a checked exception in a later release, it people found it useful. A nice thing about a format exception is you could (possibly) include more detail about where the conversion failed, and why, via fields/getters on the exception. Regards, Patrick On Fri, Feb 1, 2013 at 10:43 AM, Alan Bateman wrote: > On 31/01/2013 23:20, Xueming Shen wrote: > >> >> Any opinion of an ioe based specific InvalidedBase64BytesException >> is more appropriate/preferred/desired in this kinda of situation? The >> argument against the IAE is probably that an IAE may be a surprise >> for someone working on inputstream.read(). >> >> -Sherman >> > I just replied to your original mail, as IAE doesn't make sense here. > > I guess the question on whether you need a specialized exception comes > down to whether it would be useful to take recovery action that would be > different to other I/O exceptions that might happen. If we don't have good > use-cases then it's probably not worth doing it now, it is always something > that could be added later if really needed (as it shouldn't break anyone to > throw a more specific exception in the future). > > -Alan > > From Alan.Bateman at oracle.com Fri Feb 1 11:40:36 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 01 Feb 2013 11:40:36 +0000 Subject: Codereview request for 8006295: Base64.Decoder.wrap(java.io.InputStream) returns InputStream which throws unspecified IOException on attempt to decode invalid Base64 byte stream In-Reply-To: References: <510AECEE.7060908@oracle.com> <0E058F43-187E-4AD0-B28C-815565584B72@oracle.com> <510AF656.5040800@oracle.com> <510AFC41.3000209@oracle.com> <510B8E24.1030105@oracle.com> Message-ID: <510BA9B4.3050405@oracle.com> On 01/02/2013 10:14, Patrick Wright wrote: > Would it be appropriate to have a "format" exception extending > RuntimeException? That could then be documented in the API, but > optional to catch explicitly. "Format exceptions", as a name, are > already used for converting numbers and dates, for example. It could > be "upgraded" to a checked exception in a later release, it people > found it useful. A nice thing about a format exception is you could > (possibly) include more detail about where the conversion failed, and > why, via fields/getters on the exception. This is an InputStream and so will be used with libraries and code that will rightly expect it to behave as an InputStream. So I think it would be better to keep it as an IOException (whether a specialized IOException is needed is debatable). That would be consistent with how we handle malformed and unmappable input in other areas. -Alan. From yekaterina.kantserova at oracle.com Fri Feb 1 12:12:28 2013 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Fri, 01 Feb 2013 13:12:28 +0100 Subject: RFR (S) 8007142: Add utility classes for writing better multiprocess tests in jtreg Message-ID: <510BB12C.2030802@oracle.com> Hi everyone, Here comes a http://cr.openjdk.java.net/~ykantser/8007142/webrev.01/ with following fixes compared to .00: * new line is added at the end of** the StreamPumper.java * is changed to {@code in the StreamPumper.java * JDKToolFinder.java will use the system property "java.home" instead of "test.jdk" (thus -compilejdk problem is solved) @Max Yes, the library can launch a Java process, wait for it to finish, and collect all the output (stdout and stderr). There is no client/server solution yet, but as soon as we have testlibrary a lot of good utility classes can be put there. This solution's use case is writing simple tests in jtreg without using shell scripts. JcmdBase.java is an example of how it works. class MyTest extends JcmdBase { ... public void verify() { OutputAnalyzer output = jcmd("VM.version"); output.shouldContain("Java HotSpot"); } ... } As I've mentioned before it's almost a copy of http://cr.openjdk.java.net/~ctornqvi/webrev/8006413/webrev.03/ which has been reviewed and approved and on the way in into hotspot/test. Thanks, Katja From Alan.Bateman at oracle.com Fri Feb 1 12:32:12 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 01 Feb 2013 12:32:12 +0000 Subject: RFR (S) 8007142: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <510BB12C.2030802@oracle.com> References: <510BB12C.2030802@oracle.com> Message-ID: <510BB5CC.6050604@oracle.com> On 01/02/2013 12:12, Yekaterina Kantserova wrote: > Hi everyone, > > Here comes a http://cr.openjdk.java.net/~ykantser/8007142/webrev.01/ > with following fixes compared to .00: > > * new line is added at the end of the StreamPumper.java > * is changed to {@code in the StreamPumper.java > * JDKToolFinder.java will use the system property "java.home" instead > of "test.jdk" (thus -compilejdk problem is solved) I see you've changed the package to jdk.testlibrary - thanks for doing that. On JDKToolFinder and finding the path to jcmd or other tools used by the test then it really depends what you are testing. What you have is fine when testing a JDK but it's not going to work when testing a JRE (runtime only, no tools). When testing a runtime then jtreg needs to invoked the -jdk and -compilejdk options (the latter being the JDK to use to compile the tests). So I think the right answer for JDKToolFinder is to use "compile.jdk". That will work when testing a JDK too as "compile.jdk" and "test.jdk" are set to the same value for that case. -Alan From yekaterina.kantserova at oracle.com Fri Feb 1 13:32:16 2013 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Fri, 01 Feb 2013 14:32:16 +0100 Subject: RFR (S) 8007142: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <510BB5CC.6050604@oracle.com> References: <510BB12C.2030802@oracle.com> <510BB5CC.6050604@oracle.com> Message-ID: <510BC3E0.6020107@oracle.com> On 02/01/2013 01:32 PM, Alan Bateman wrote: > On 01/02/2013 12:12, Yekaterina Kantserova wrote: >> Hi everyone, >> >> Here comes a http://cr.openjdk.java.net/~ykantser/8007142/webrev.01/ >> with following fixes compared to .00: >> >> * new line is added at the end of the StreamPumper.java >> * is changed to {@code in the StreamPumper.java >> * JDKToolFinder.java will use the system property "java.home" instead >> of "test.jdk" (thus -compilejdk problem is solved) > I see you've changed the package to jdk.testlibrary - thanks for doing > that. > Ops, I've forgotten to mention it. Thanks for pointing on it. > On JDKToolFinder and finding the path to jcmd or other tools used by > the test then it really depends what you are testing. What you have is > fine when testing a JDK but it's not going to work when testing a JRE > (runtime only, no tools). When testing a runtime then jtreg needs to > invoked the -jdk and -compilejdk options (the latter being the JDK to > use to compile the tests). So I think the right answer for > JDKToolFinder is to use "compile.jdk". That will work when testing a > JDK too as "compile.jdk" and "test.jdk" are set to the same value for > that case. I've done some testing before I've changed JDKToolFinder. Bellow are 2 cases: 1) *compile.jdk != test.jdk* ./build/linux-amd64/j2sdk-image/bin/java -jar jtreg.jar -compilejdk /localhome/java/jdk1.7.0_09 test.java test.jdk=../build/linux-amd64/j2sdk-image/jre compile.jdk=/localhome/java/jdk1.7.0_09 java.home=../build/linux-amd64/j2sdk-image/jre 2) *compile.jdk == test.jdk* ./build/linux-amd64/j2sdk-image/bin/java -jar jtreg.jar -jdk|-testjdk /localhome/java/jdk1.7.0_09 test.java test.jdk /localhome/java/jdk1.7.0_09 compile.jdk /localhome/java/jdk1.7.0_09 java.home /localhome/java/jdk1.7.0_09/jre It seems like test.jdk is always equal to java.home (besides /jre part). Are there some rules how -jdk and -compilejdk should be used? > > -Alan Thanks, Katja From Alan.Bateman at oracle.com Fri Feb 1 14:20:11 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 01 Feb 2013 14:20:11 +0000 Subject: RFR (S) 8007142: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <510BC3E0.6020107@oracle.com> References: <510BB12C.2030802@oracle.com> <510BB5CC.6050604@oracle.com> <510BC3E0.6020107@oracle.com> Message-ID: <510BCF1B.3010704@oracle.com> On 01/02/2013 13:32, Yekaterina Kantserova wrote: > > I've done some testing before I've changed JDKToolFinder. Bellow are 2 > cases: > > 1) *compile.jdk != test.jdk* > ./build/linux-amd64/j2sdk-image/bin/java -jar jtreg.jar -compilejdk > /localhome/java/jdk1.7.0_09 test.java > > test.jdk=../build/linux-amd64/j2sdk-image/jre > compile.jdk=/localhome/java/jdk1.7.0_09 > java.home=../build/linux-amd64/j2sdk-image/jre > > 2) *compile.jdk == test.jdk* > ./build/linux-amd64/j2sdk-image/bin/java -jar jtreg.jar -jdk|-testjdk > /localhome/java/jdk1.7.0_09 test.java > > test.jdk /localhome/java/jdk1.7.0_09 > compile.jdk /localhome/java/jdk1.7.0_09 > java.home /localhome/java/jdk1.7.0_09/jre > > It seems like test.jdk is always equal to java.home (besides /jre > part). Are there some rules how -jdk and -compilejdk should be used? Normally you specify the JDK/JRE to test via the -jdk option. When you only specify -jdk then you will see that test.jdk and compile.jdk have the same value. When testing a JRE then you need to specify both -jdk and -compilejdk, the latter being the JDK to use to compile the tests. In that scenario you will see that test.jdk and compile.jdk are different (as expected). -Alan. From mark.sheppard at oracle.com Fri Feb 1 14:35:10 2013 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Fri, 01 Feb 2013 14:35:10 +0000 Subject: Codereview request for 8006295: Base64.Decoder.wrap(java.io.InputStream) returns InputStream which throws unspecified IOException on attempt to decode invalid Base64 byte stream In-Reply-To: <510BA9B4.3050405@oracle.com> References: <510AECEE.7060908@oracle.com> <0E058F43-187E-4AD0-B28C-815565584B72@oracle.com> <510AF656.5040800@oracle.com> <510AFC41.3000209@oracle.com> <510B8E24.1030105@oracle.com> <510BA9B4.3050405@oracle.com> Message-ID: <510BD29E.6080203@oracle.com> Hi Alan, I think it would be useful to convey some additional information relating the cause of the problem, even for diagnostic purposes. So analogous to CharacterEncodingException which exists for Charsets, providing a Base64EncodingException and Baes64DecodingException as derived from IOException, (as alluded to previously by Sherman,) could/would be useful. However, as the underlying encapsulating InputStream/FilterOutputStream is no exposed, and hence the overridden read/write methods publicly defined, how would such exceptions be reconciled against the generalized Output/InputStream returned by wrap()? Alternatively, perhaps throwing an IOException with an embedded Base64Encoding/DecodingException could also be used ? regards Mark On 01/02/2013 11:40, Alan Bateman wrote: > On 01/02/2013 10:14, Patrick Wright wrote: >> Would it be appropriate to have a "format" exception extending >> RuntimeException? That could then be documented in the API, but >> optional to catch explicitly. "Format exceptions", as a name, are >> already used for converting numbers and dates, for example. It could >> be "upgraded" to a checked exception in a later release, it people >> found it useful. A nice thing about a format exception is you could >> (possibly) include more detail about where the conversion failed, and >> why, via fields/getters on the exception. > This is an InputStream and so will be used with libraries and code > that will rightly expect it to behave as an InputStream. So I think it > would be better to keep it as an IOException (whether a specialized > IOException is needed is debatable). That would be consistent with how > we handle malformed and unmappable input in other areas. > > -Alan. > From chris.hegarty at oracle.com Fri Feb 1 14:40:38 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 01 Feb 2013 14:40:38 +0000 Subject: RFR: race with nested repos in hgforest.sh Message-ID: <510BD3E6.1090103@oracle.com> [ to build-dev and core-libs-dev, expect reviewer from either, but will integrate through jdk8/tl ] This issue is mainly of interest to Oracle engineers, but it effects the public hgforest script. When hgforest.sh is run with an addition argument to specify a closed server, there is a problem/race between the creation of the directories to hold nested repositories and the clone itself. These directories need to be created before the clone command is executed, otherwise it will fail, as below. The trivial fix is to back off these nested repos until their containing directory exists. Webrev: http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed hotspot/test/closed deploy install sponsors pubs Waiting 5 secs before spawning next background command. Waiting 5 secs before spawning next background command. Waiting 5 secs before spawning next background command. jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u /java/devtools/sparc/mercurial/latest/bin/hg clone http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed jdk/src/closed: abort: No such file or directory: jdk/src/closed jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u /java/devtools/sparc/mercurial/latest/bin/hg clone http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed jdk/make/closed: abort: No such file or directory: jdk/make/closed Waiting 5 secs before spawning next background command. .... -Chris. From chris.hegarty at oracle.com Fri Feb 1 14:48:21 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 01 Feb 2013 14:48:21 +0000 Subject: Codereview request for 8006295: Base64.Decoder.wrap(java.io.InputStream) returns InputStream which throws unspecified IOException on attempt to decode invalid Base64 byte stream In-Reply-To: <510BD29E.6080203@oracle.com> References: <510AECEE.7060908@oracle.com> <0E058F43-187E-4AD0-B28C-815565584B72@oracle.com> <510AF656.5040800@oracle.com> <510AFC41.3000209@oracle.com> <510B8E24.1030105@oracle.com> <510BA9B4.3050405@oracle.com> <510BD29E.6080203@oracle.com> Message-ID: <510BD5B5.8010507@oracle.com> On 01/02/2013 14:35, Mark Sheppard wrote: > > Hi Alan, > > I think it would be useful to convey some additional information > relating the cause of the problem, even for diagnostic purposes. > > So analogous to CharacterEncodingException which exists for Charsets, > providing a Base64EncodingException > and Baes64DecodingException as derived from IOException, (as alluded to > previously by Sherman,) could/would be useful. > However, as the underlying encapsulating InputStream/FilterOutputStream > is no exposed, and hence the overridden > read/write methods publicly defined, how would such exceptions be > reconciled against the generalized Output/InputStream returned by wrap()? It could simply be in the method description for warp, but I think as Alan said, there doesn't seem to be a clear need for such a public exception type. -Chris > > Alternatively, perhaps throwing an IOException with an embedded > Base64Encoding/DecodingException could also be used ? > > regards > Mark > > On 01/02/2013 11:40, Alan Bateman wrote: >> On 01/02/2013 10:14, Patrick Wright wrote: >>> Would it be appropriate to have a "format" exception extending >>> RuntimeException? That could then be documented in the API, but >>> optional to catch explicitly. "Format exceptions", as a name, are >>> already used for converting numbers and dates, for example. It could >>> be "upgraded" to a checked exception in a later release, it people >>> found it useful. A nice thing about a format exception is you could >>> (possibly) include more detail about where the conversion failed, and >>> why, via fields/getters on the exception. >> This is an InputStream and so will be used with libraries and code >> that will rightly expect it to behave as an InputStream. So I think it >> would be better to keep it as an IOException (whether a specialized >> IOException is needed is debatable). That would be consistent with how >> we handle malformed and unmappable input in other areas. >> >> -Alan. >> From Alan.Bateman at oracle.com Fri Feb 1 14:59:13 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 01 Feb 2013 14:59:13 +0000 Subject: Codereview request for 8006295: Base64.Decoder.wrap(java.io.InputStream) returns InputStream which throws unspecified IOException on attempt to decode invalid Base64 byte stream In-Reply-To: <510BD29E.6080203@oracle.com> References: <510AECEE.7060908@oracle.com> <0E058F43-187E-4AD0-B28C-815565584B72@oracle.com> <510AF656.5040800@oracle.com> <510AFC41.3000209@oracle.com> <510B8E24.1030105@oracle.com> <510BA9B4.3050405@oracle.com> <510BD29E.6080203@oracle.com> Message-ID: <510BD841.2090704@oracle.com> On 01/02/2013 14:35, Mark Sheppard wrote: > > Hi Alan, > > I think it would be useful to convey some additional information > relating the cause of the problem, even for diagnostic purposes. > > So analogous to CharacterEncodingException which exists for Charsets, > providing a Base64EncodingException > and Baes64DecodingException as derived from IOException, (as alluded > to previously by Sherman,) could/would be useful. > However, as the underlying encapsulating > InputStream/FilterOutputStream is no exposed, and hence the overridden > read/write methods publicly defined, how would such exceptions be > reconciled against the generalized Output/InputStream returned by wrap()? > > Alternatively, perhaps throwing an IOException with an embedded > Base64Encoding/DecodingException could also be used ? The exception message is detailed/useful already, it's just whether this needs a specialized IOException or an appropriate cause. If there are good reasons to recover differently to other I/O exceptions then it may make sense. The other useful thing about a specialized exception is that it could carry more context, like the line or position where the stream is corrupted. -Alan. From yekaterina.kantserova at oracle.com Fri Feb 1 15:06:23 2013 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Fri, 01 Feb 2013 16:06:23 +0100 Subject: RFR (S) 8007142: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <510BCF1B.3010704@oracle.com> References: <510BB12C.2030802@oracle.com> <510BB5CC.6050604@oracle.com> <510BC3E0.6020107@oracle.com> <510BCF1B.3010704@oracle.com> Message-ID: <510BD9EF.1050202@oracle.com> On 02/01/2013 03:20 PM, Alan Bateman wrote: > On 01/02/2013 13:32, Yekaterina Kantserova wrote: >> >> I've done some testing before I've changed JDKToolFinder. Bellow are >> 2 cases: >> >> 1) *compile.jdk != test.jdk* >> ./build/linux-amd64/j2sdk-image/bin/java -jar jtreg.jar -compilejdk >> /localhome/java/jdk1.7.0_09 test.java >> >> test.jdk=../build/linux-amd64/j2sdk-image/jre >> compile.jdk=/localhome/java/jdk1.7.0_09 >> java.home=../build/linux-amd64/j2sdk-image/jre >> >> 2) *compile.jdk == test.jdk* >> ./build/linux-amd64/j2sdk-image/bin/java -jar jtreg.jar -jdk|-testjdk >> /localhome/java/jdk1.7.0_09 test.java >> >> test.jdk /localhome/java/jdk1.7.0_09 >> compile.jdk /localhome/java/jdk1.7.0_09 >> java.home /localhome/java/jdk1.7.0_09/jre >> >> It seems like test.jdk is always equal to java.home (besides /jre >> part). Are there some rules how -jdk and -compilejdk should be used? > Normally you specify the JDK/JRE to test via the -jdk option. When you > only specify -jdk then you will see that test.jdk and compile.jdk have > the same value. > > When testing a JRE then you need to specify both -jdk and -compilejdk, > the latter being the JDK to use to compile the tests. In that scenario > you will see that test.jdk and compile.jdk are different (as expected). > Thanks for explanation! But I'm still confused. In my use case I need to test /_the tool_/ I'll find with JDKToolFinder. It will work if just -jdk will be specified. But if -compilejdk happens to be specified the results of my tests will be useless. Furthermore, it would be hard to detect. Do you think there is a solution that covers all use cases? // Katja > -Alan. From Alan.Bateman at oracle.com Fri Feb 1 15:18:02 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 01 Feb 2013 15:18:02 +0000 Subject: RFR (S) 8007142: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <510BD9EF.1050202@oracle.com> References: <510BB12C.2030802@oracle.com> <510BB5CC.6050604@oracle.com> <510BC3E0.6020107@oracle.com> <510BCF1B.3010704@oracle.com> <510BD9EF.1050202@oracle.com> Message-ID: <510BDCAA.1080909@oracle.com> On 01/02/2013 15:06, Yekaterina Kantserova wrote: > > Thanks for explanation! But I'm still confused. > > In my use case I need to test /_the tool_/ I'll find with > JDKToolFinder. It will work if just -jdk will be specified. But if > -compilejdk happens to be specified the results of my tests will be > useless. Furthermore, it would be hard to detect. Do you think there > is a solution that covers all use cases? I don't think it make sense to specify -compilejdk and not -jdk. Does that help? -Alan From kumar.x.srinivasan at oracle.com Fri Feb 1 15:29:14 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Fri, 01 Feb 2013 15:29:14 +0000 Subject: hg: jdk8/tl/jdk: 8006536: [launcher] removes trailing slashes on arguments Message-ID: <20130201152946.9565E47755@hg.openjdk.java.net> Changeset: ea8f3ca83501 Author: ksrini Date: 2013-02-01 07:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ea8f3ca83501 8006536: [launcher] removes trailing slashes on arguments Reviewed-by: ksrini, akhil Contributed-by: jviswana at linux.vnet.ibm.com ! src/windows/bin/cmdtoargs.c ! test/tools/launcher/Arrrghs.java From xueming.shen at oracle.com Fri Feb 1 16:29:23 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 01 Feb 2013 08:29:23 -0800 Subject: [Base64] Codereview request for 8006315 8006530 In-Reply-To: <510B8B41.4010505@oracle.com> References: <510B70D7.2040702@oracle.com> <510B8B41.4010505@oracle.com> Message-ID: <510BED63.5050704@oracle.com> On 2/1/13 1:30 AM, Chris Hegarty wrote: > The spec clarifications look good to me, and will be much more user > friendly. > > Trivially, this is the first mention of padding in the API, "Base64 > padding character", should this be qualified as '='? Or maybe, this is > just another case of deferring to the "The Base64 Alphabet" in the rfc. > > The test seems inconsistent with the spec clarification, "The Base64 > padding character is accepted and interpreted as the end of the > encoded byte data" > > + checkEqual(decM.decode(encoded), src[i], "Non-base64 char is not > ignored"); > + try { > + dec.decode(encoded); > + throw new RuntimeException("No IAE for non-base64 > char"); > + } catch (IllegalArgumentException iae) {} > > Why, in the case of src input "A" would you expect the mime decoder to > ignore the trailing character, and not the Basic decoder? The current spec and implementation expect everything passed in (byte array/ String/ByteBuffer) are acceptable valid base64 data, if there is anything (trailing bytes) left can't be handled by the decoder, it's an "error". In case of MIME, the spec explicitly specifies any non-bsae64 character are ignored, so even they are not valid base64 bits, but they should be accepted and ignored, as part of the valid base64 data, not the "trailing" stuff (the mime decoder skips those bytes in the middle of data, it would be consistent to also skip at the end) -Sherman > > -Chris. > > On 01/02/2013 07:37, Xueming Shen wrote: >> Hi, >> >> This is the webrev for >> >> 8006530: Base64.getMimeDecoder().decode() throws exception for >> non-base64 character after adding = >> 8006315: Base64.Decoder decoding methods are not consistent in treating >> non-padded data >> >> http://cr.openjdk.java.net/~sherman/8006315_8006530/webrev >> >> The change is to >> >> (1) explicitly specify line feed is not added to the end of mime encoded >> output (no surprise) >> >> (2) mime decoder now ignores any non-base64 character after padding = >> (same as it >> ignores those non-base64 character within the data (mime base64 spec). >> Convenient >> for use case like a padding \n at the end of any input data from the >> file and, as suggested >> from real base64 use case. >> >> (3) explicitly specify padding character at the end of the base64 >> encoded data is >> optional when DECODING (encoder always adds padding character = when >> necessary). >> The "decoding" part of the RFC really does not make it a MUST, so be >> liberal. >> >> (4) update the decoder inputstream to behave the same way other decoders >> do, to >> accept AA and AAA same as AA== AAA=. >> >> Please help review. >> >> -Sherman From jonathan.gibbons at oracle.com Fri Feb 1 16:34:22 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 01 Feb 2013 16:34:22 +0000 Subject: hg: jdk8/tl/langtools: 8007306: DPrinter: improve display of impl-class, internal tag/kind, and external tag/kind Message-ID: <20130201163425.41E2E4775A@hg.openjdk.java.net> Changeset: 8590c20af3ce Author: jjg Date: 2013-02-01 08:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8590c20af3ce 8007306: DPrinter: improve display of impl-class, internal tag/kind, and external tag/kind Reviewed-by: mcimadamore ! test/tools/javac/lib/DPrinter.java From jonathan.gibbons at oracle.com Fri Feb 1 16:36:26 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 01 Feb 2013 16:36:26 +0000 Subject: hg: jdk8/tl/langtools: 8007305: DPrinter: provide better usage message Message-ID: <20130201163629.5A50D4775B@hg.openjdk.java.net> Changeset: 6df931ce1a81 Author: jjg Date: 2013-02-01 08:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6df931ce1a81 8007305: DPrinter: provide better usage message Reviewed-by: mcimadamore ! test/tools/javac/lib/DPrinter.java From chris.hegarty at oracle.com Fri Feb 1 16:40:32 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 01 Feb 2013 16:40:32 +0000 Subject: [Base64] Codereview request for 8006315 8006530 In-Reply-To: <510BED63.5050704@oracle.com> References: <510B70D7.2040702@oracle.com> <510B8B41.4010505@oracle.com> <510BED63.5050704@oracle.com> Message-ID: <510BF000.9080705@oracle.com> > The current spec and implementation expect everything passed in (byte > array/ > String/ByteBuffer) are acceptable valid base64 data, if there is > anything (trailing > bytes) left can't be handled by the decoder, it's an "error". > In case of MIME, the spec explicitly specifies any non-bsae64 character are > ignored, so even they are not valid base64 bits, but they should be > accepted > and ignored, as part of the valid base64 data, not the "trailing" stuff > (the mime > decoder skips those bytes in the middle of data, it would be consistent to > also skip at the end) OK, I think I got it now. -Chris. From eric.mccorkle at oracle.com Fri Feb 1 16:45:21 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Fri, 01 Feb 2013 11:45:21 -0500 Subject: Review Request for JDK-8007389: Remove uses of _ as identifier in jaxp Message-ID: <510BF121.30105@oracle.com> Hello, Please review this trivial patch which removes uses of _ as an identifier in the jaxp API. The webrev is here: http://cr.openjdk.java.net/~emc/8007389/ The bug should be here, but does not seem to be showing up yet: http://bugs.sun.com/view_bug.do?bug_id=8007389 From xueming.shen at oracle.com Fri Feb 1 16:55:58 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 01 Feb 2013 08:55:58 -0800 Subject: [Base64] Codereview request for 8006315 8006530 AND 8006295 In-Reply-To: <510B70D7.2040702@oracle.com> References: <510B70D7.2040702@oracle.com> Message-ID: <510BF39E.3020302@oracle.com> Hi, For 8006295 it appears the more reasonable approach is to continue throw IOE but document this behavior clearly at the wrap(is) API. So the change is joined with these two. 8006295: Base64.Decoder.wrap(java.io.InputStream) returns InputStream which throws unspecified IOException on attempt to decode invalid Base64 byte stream http://cr.openjdk.java.net/~sherman/8006295_8006315_8006530/webrev/ Thanks! -Sherman On 1/31/13 11:37 PM, Xueming Shen wrote: > Hi, > > This is the webrev for > > 8006530: Base64.getMimeDecoder().decode() throws exception for > non-base64 character after adding = > 8006315: Base64.Decoder decoding methods are not consistent in > treating non-padded data > > http://cr.openjdk.java.net/~sherman/8006315_8006530/webrev > > The change is to > > (1) explicitly specify line feed is not added to the end of mime > encoded output (no surprise) > > (2) mime decoder now ignores any non-base64 character after padding = > (same as it > ignores those non-base64 character within the data (mime base64 spec). > Convenient > for use case like a padding \n at the end of any input data from the > file and, as suggested > from real base64 use case. > > (3) explicitly specify padding character at the end of the base64 > encoded data is > optional when DECODING (encoder always adds padding character = when > necessary). > The "decoding" part of the RFC really does not make it a MUST, so be > liberal. > > (4) update the decoder inputstream to behave the same way other > decoders do, to > accept AA and AAA same as AA== AAA=. > > Please help review. > > -Sherman From Lance.Andersen at oracle.com Fri Feb 1 17:04:04 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 1 Feb 2013 12:04:04 -0500 Subject: Review Request for JDK-8007389: Remove uses of _ as identifier in jaxp In-Reply-To: <510BF121.30105@oracle.com> References: <510BF121.30105@oracle.com> Message-ID: <654238BD-516E-4AFD-8C01-C64AAC2ADF50@oracle.com> Its OK. Not sure I would have replaced it with 'unused' but not a big deal as it is just a personal preference. On Feb 1, 2013, at 11:45 AM, Eric McCorkle wrote: > Hello, > > Please review this trivial patch which removes uses of _ as an > identifier in the jaxp API. > > The webrev is here: > http://cr.openjdk.java.net/~emc/8007389/ > > The bug should be here, but does not seem to be showing up yet: > http://bugs.sun.com/view_bug.do?bug_id=8007389 -------------- 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 martinrb at google.com Fri Feb 1 17:45:24 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 1 Feb 2013 09:45:24 -0800 Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code In-Reply-To: <510B900B.1030406@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> Message-ID: Yes, the current Process code deals fairly well with other people's file descriptors that are not close-on-exec. But this code is brittle, and long-term it would be cleaner for all open's in the jdk to use O_CLOEXEC by default. We can probably never remove the Process code that closes all file descriptors, because native user code could also create file descriptors. In the near term, until all the posixoid systems we (might) run on support O_CLOEXEC, it seems better to leave this code as is. Or for general cleanliness, add O_CLOEXEC by reflex whenever opening a file, without expectation that users will ever see the benefit, unless they roll their own fork-exec. On Fri, Feb 1, 2013 at 1:51 AM, Alan Bateman wrote: > On 01/02/2013 02:23, Martin Buchholz wrote: > >> You could operate in paranoid mode and do *both* : use O_CLOEXEC and use >> fcntl to set the bit after creating it, perhaps after verifying via fcntl >> whether the bit was successfully set by open. >> >> Martin >> >> >> Alternatively, just leave this code out. We open sockets and files in > many other places in the libraries and don't explicitly enable the > close-on-exec flag (we do set the inheritance flag on Windows so I guess we > do have an inconsistency). Anyway, my point is that the Process code > already handles this and closes the file descriptors in the child so I > assume it doesn't matter if we have enabled the close-on-exec flag or not. > There might of course be applications or other libraries that use fork+exec > or variants directly, in which case there will be an issue if they expect > all file descriptors to have the close-on-exec flag set. However, I assume > we have this issue already as we just enable it consistently. > > -Alan. > From Alan.Bateman at oracle.com Fri Feb 1 17:51:06 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 01 Feb 2013 17:51:06 +0000 Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code In-Reply-To: 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> Message-ID: <510C008A.2000107@oracle.com> On 01/02/2013 17:45, Martin Buchholz wrote: > Yes, the current Process code deals fairly well with other people's > file descriptors that are not close-on-exec. But this code is > brittle, and long-term it would be cleaner for all open's in the jdk > to use O_CLOEXEC by default. We can probably never remove the Process > code that closes all file descriptors, because native user code could > also create file descriptors. In the near term, until all the > posixoid systems we (might) run on support O_CLOEXEC, it seems better > to leave this code as is. Or for general cleanliness, add O_CLOEXEC > by reflex whenever opening a file, without expectation that users will > ever see the benefit, unless they roll their own fork-exec. There are lots of places in the JDK that open files or sockets, java.io is just one. It may be better if we separate this from Dan's clean-up and decide (as part of a separate piece of work) whether we want everywhere to enable close-on-exec on its file descriptors or just leave it to Process.exec as we do now. -Alan From martinrb at google.com Fri Feb 1 18:12:39 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 1 Feb 2013 10:12:39 -0800 Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code In-Reply-To: <510C008A.2000107@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> Message-ID: On Fri, Feb 1, 2013 at 9:51 AM, Alan Bateman wrote: > There are lots of places in the JDK that open files or sockets, java.iois just one. It may be better if we separate this from Dan's clean-up and > decide (as part of a separate piece of work) whether we want everywhere to > enable close-on-exec on its file descriptors or just leave it to > Process.exec as we do now. > 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? From stevenschlansker at gmail.com Fri Feb 1 18:13:01 2013 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Fri, 1 Feb 2013 10:13:01 -0800 Subject: RFR (S) CR 8006627: Improving performance and reducing object allocations of java.util.UUID to/from string In-Reply-To: <84A32ABE-B1E7-4E03-9843-DDFE20897B77@oracle.com> References: <84A32ABE-B1E7-4E03-9843-DDFE20897B77@oracle.com> Message-ID: <0EC036A3-3D11-4F56-B3FD-403CCC610347@gmail.com> On Jan 30, 2013, at 11:42 AM, Mike Duigou wrote: > Good work Steven! Thanks for the review :) > > Some initial comments; > > - The changes to Long should be in a separate issue. It's generally encouraged for changesets to focus on only one change. Sorry, yes, it's additional overhead. That's unfortunate. I don't have the ability / know how to file a second, separate issue, and I've already spent a lot more time trying to get this small change through than I'd expected on overhead. Will it be preferable to have someone open a second issue, make two web revs, and code review both, or should I just abandon the attempt at code-sharing between UUID and Long? In the original patch that Aleksey reviewed I had not attempted this; I did it on his suggestion. > > - I would like to see if performed of toString() can be improved further by using String(char[] value, boolean share) constructor via a sun.miscSharedSecret.JavaLangAccesss method to construct the string directly from the character array. You could test to see if this has positive benefit by temporarily using a static char array. I will incorporate this into my next revision > > - public static String toString(long msb, long lsb) should be private. There's no compelling reason to add this to the API. > I can remove this. I added it on the theory that if you wish to ship UUIDs around as two longs, it may be useful to omit UUID object instantiation just to format as a string. Maybe this is too far out there to make another public method acceptable. > - Have you run this code against any of the existing regression tests? Yes, I ran the jtreg UUID and Long tests, all pass. I ran the Apache Harmony UUID test cases against the pre-integrated version of the code. (There should only have been minor modifications since then, variable renamings, whatnot?) > > Mike > > On Jan 28 2013, at 19:23 , Steven Schlansker wrote: > >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006627 >> >> I have created a patch that dramatically improves UUID to/from string performance. >> Please find below a webrev with my proposed changes. >> >> Thanks in advance for any feedback on the contents. >> I do not believe I have a committer lined up yet. >> My company has a signed OCA on file, "Ness Computing". >> >> http://dl.dropbox.com/u/1422321/uuid_webrev/index.html >> http://dl.dropbox.com/u/1422321/uuid_webrev.zip >> > From brian.burkhalter at oracle.com Fri Feb 1 18:59:47 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 1 Feb 2013 10:59:47 -0800 Subject: RFR: 5035569: assertion error in Formatter Message-ID: Hello, The assertion is due to a condition occurring which is contrary to the specification. The specification is accurate but insufficiently forthcoming that the %a conversion is unsupported for BigDecimal. This change clarifies the situation by updating the conversion table which occurs earlier in the class comments. diff -r d2495b9984fa -r 4770eaa01d38 src/share/classes/java/util/Formatter.java --- a/src/share/classes/java/util/Formatter.java Fri Feb 01 07:39:41 2013 +0800 +++ b/src/share/classes/java/util/Formatter.java Fri Feb 01 10:46:23 2013 -0800 @@ -351,7 +351,9 @@ * {@code 'a'}, {@code 'A'} * floating point * The result is formatted as a hexadecimal floating-point number with - * a significand and an exponent + * a significand and an exponent. This conversion is not supported + * for the {@code BigDecimal} type despite the latter's being in the + * floating point argument category. * * {@code 't'}, {@code 'T'} * date/time Thanks, Brian From joe.darcy at oracle.com Fri Feb 1 19:06:11 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 01 Feb 2013 11:06:11 -0800 Subject: RFR: 5035569: assertion error in Formatter In-Reply-To: References: Message-ID: <510C1223.2030204@oracle.com> Hi Brian, Looks fine; cheers, -Joe On 2/1/2013 10:59 AM, Brian Burkhalter wrote: > Hello, > > The assertion is due to a condition occurring which is contrary to the specification. The specification is accurate but insufficiently forthcoming that the %a conversion is unsupported for BigDecimal. This change clarifies the situation by updating the conversion table which occurs earlier in the class comments. > > diff -r d2495b9984fa -r 4770eaa01d38 src/share/classes/java/util/Formatter.java > --- a/src/share/classes/java/util/Formatter.java Fri Feb 01 07:39:41 2013 +0800 > +++ b/src/share/classes/java/util/Formatter.java Fri Feb 01 10:46:23 2013 -0800 > @@ -351,7 +351,9 @@ > * {@code 'a'}, {@code 'A'} > * floating point > * The result is formatted as a hexadecimal floating-point number with > - * a significand and an exponent > + * a significand and an exponent. This conversion is not supported > + * for the {@code BigDecimal} type despite the latter's being in the > + * floating point argument category. > * > * {@code 't'}, {@code 'T'} > * date/time > > Thanks, > > Brian From joe.darcy at oracle.com Fri Feb 1 19:16:11 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 01 Feb 2013 11:16:11 -0800 Subject: Code review request for 8007113 Upgrade AnnotatedElement.isAnnotionPresent to be a default method In-Reply-To: <510B8F18.3010905@oracle.com> References: <510B34CB.5070009@oracle.com> <510B8F18.3010905@oracle.com> Message-ID: <510C147B.7060103@oracle.com> Hi Joel, On 2/1/2013 1:47 AM, Joel Borggr?n-Franck wrote: > Hi Joe, > > On 02/01/2013 04:21 AM, Joe Darcy wrote: >> Hello, >> >> I'd like to upgrade the existing AnnotatedElement.isAnnotationPresent >> interface method to a default method: >> >> 8007113 Upgrade AnnotatedElement.isAnnotionPresent to be a >> default method >> http://cr.openjdk.java.net/~darcy/8007113.0/ >> > > How about sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java ? > > It looks like I forgot to update that one when I did the type > annotations changes :) I did notice TypeVariableImpl as one of the implementers of AnnotatedElement, but since it was defined to just return false, I skipped it. However, since getAnnotation now works for type variables, that behavior is incorrect. I'll update the webrev to cover TypeVariableImpl too. Thanks, -Joe From mike.duigou at oracle.com Fri Feb 1 19:42:29 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 1 Feb 2013 11:42:29 -0800 Subject: RFR (S) CR 8006627: Improving performance and reducing object allocations of java.util.UUID to/from string In-Reply-To: <0EC036A3-3D11-4F56-B3FD-403CCC610347@gmail.com> References: <84A32ABE-B1E7-4E03-9843-DDFE20897B77@oracle.com> <0EC036A3-3D11-4F56-B3FD-403CCC610347@gmail.com> Message-ID: On Feb 1 2013, at 10:13 , Steven Schlansker wrote: > > On Jan 30, 2013, at 11:42 AM, Mike Duigou wrote: > >> Good work Steven! > > Thanks for the review :) >> >> Some initial comments; >> >> - The changes to Long should be in a separate issue. It's generally encouraged for changesets to focus on only one change. Sorry, yes, it's additional overhead. > > That's unfortunate. I don't have the ability / know how to file a second, separate issue, and I've already spent a lot more time trying to get this small change through than I'd expected on overhead. Will it be preferable to have someone open a second issue, make two web revs, and code review both, or should I just abandon the attempt at code-sharing between UUID and Long? In the original patch that Aleksey reviewed I had not attempted this; I did it on his suggestion. I have created another issue 8007398 for the changes to Long. We can even test and push the two issues at the same time. Separating them into two changesets makes the intent easier to follow for future maintainers. We can use the same webrev. There's no need to create another. >> - I would like to see if performed of toString() can be improved further by using String(char[] value, boolean share) constructor via a sun.miscSharedSecret.JavaLangAccesss method to construct the string directly from the character array. You could test to see if this has positive benefit by temporarily using a static char array. > > I will incorporate this into my next revision > >> >> - public static String toString(long msb, long lsb) should be private. There's no compelling reason to add this to the API. >> > > I can remove this. I added it on the theory that if you wish to ship UUIDs around as two longs, it may be useful to omit UUID object instantiation just to format as a string. Maybe this is too far out there to make another public method acceptable. > >> - Have you run this code against any of the existing regression tests? > > Yes, I ran the jtreg UUID and Long tests, all pass. I ran the Apache Harmony UUID test cases against the pre-integrated version of the code. (There should only have been minor modifications since then, variable renamings, whatnot?) OK, once we have a final webrev then I will run final tests and push this! Mike > >> >> Mike >> >> On Jan 28 2013, at 19:23 , Steven Schlansker wrote: >> >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006627 >>> >>> I have created a patch that dramatically improves UUID to/from string performance. >>> Please find below a webrev with my proposed changes. >>> >>> Thanks in advance for any feedback on the contents. >>> I do not believe I have a committer lined up yet. >>> My company has a signed OCA on file, "Ness Computing". >>> >>> http://dl.dropbox.com/u/1422321/uuid_webrev/index.html >>> http://dl.dropbox.com/u/1422321/uuid_webrev.zip >>> >> > From jonathan.gibbons at oracle.com Fri Feb 1 20:01:28 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 01 Feb 2013 20:01:28 +0000 Subject: hg: jdk8/tl/langtools: 8007344: javac may not make tree end positions and/or doc comments available to processors and listeners Message-ID: <20130201200134.8D09947773@hg.openjdk.java.net> Changeset: 0b1c88705568 Author: jjg Date: 2013-02-01 12:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0b1c88705568 8007344: javac may not make tree end positions and/or doc comments available to processors and listeners Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java + test/tools/javac/api/8007344/Test.java From joe.darcy at oracle.com Fri Feb 1 21:01:38 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 01 Feb 2013 21:01:38 +0000 Subject: hg: jdk8/tl/langtools: 8001614: Include annotation type to documented supported-ness Message-ID: <20130201210141.910004777E@hg.openjdk.java.net> Changeset: 55cca2f38ee6 Author: darcy Date: 2013-02-01 13:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/55cca2f38ee6 8001614: Include annotation type to documented supported-ness Reviewed-by: alanb, jjg, tbell ! make/Makefile-classic ! make/build.properties + src/share/classes/jdk/Supported.java From alan.bateman at oracle.com Fri Feb 1 21:03:41 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 01 Feb 2013 21:03:41 +0000 Subject: hg: jdk8/tl/jdk: 5035569: Formatter should document that %a conversion unsupported for BigDecimal args Message-ID: <20130201210353.A3A914777F@hg.openjdk.java.net> Changeset: 5e47ee4d7196 Author: alanb Date: 2013-02-01 21:01 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e47ee4d7196 5035569: Formatter should document that %a conversion unsupported for BigDecimal args Reviewed-by: darcy Contributed-by: brian.burkhalter at oracle.com ! src/share/classes/java/util/Formatter.java From Alan.Bateman at oracle.com Fri Feb 1 21:25:38 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 01 Feb 2013 21:25:38 +0000 Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code In-Reply-To: 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> Message-ID: <510C32D2.2080508@oracle.com> 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 joe.darcy at oracle.com Fri Feb 1 21:28:16 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 01 Feb 2013 13:28:16 -0800 Subject: Code review request for 8007113 Upgrade AnnotatedElement.isAnnotionPresent to be a default method In-Reply-To: <510C147B.7060103@oracle.com> References: <510B34CB.5070009@oracle.com> <510B8F18.3010905@oracle.com> <510C147B.7060103@oracle.com> Message-ID: <510C3370.7010501@oracle.com> On 02/01/2013 11:16 AM, Joe Darcy wrote: > Hi Joel, > > On 2/1/2013 1:47 AM, Joel Borggr?n-Franck wrote: >> Hi Joe, >> >> On 02/01/2013 04:21 AM, Joe Darcy wrote: >>> Hello, >>> >>> I'd like to upgrade the existing AnnotatedElement.isAnnotationPresent >>> interface method to a default method: >>> >>> 8007113 Upgrade AnnotatedElement.isAnnotionPresent to be a >>> default method >>> http://cr.openjdk.java.net/~darcy/8007113.0/ >>> >> >> How about sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java ? >> >> It looks like I forgot to update that one when I did the type >> annotations changes :) > > I did notice TypeVariableImpl as one of the implementers of > AnnotatedElement, but since it was defined to just return false, I > skipped it. However, since getAnnotation now works for type > variables, that behavior is incorrect. > > I'll update the webrev to cover TypeVariableImpl too. > > Thanks, > New webrev posted with a typo fix and TypeVariableImpl covered: http://cr.openjdk.java.net/~darcy/8007113.1/ Thanks, -Joe From joe.darcy at oracle.com Fri Feb 1 21:39:40 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 01 Feb 2013 13:39:40 -0800 Subject: JDK 8 code review request for 6964528: Double.toHexString(double d) String manipulation with + in an append of StringBuilder Message-ID: <510C361C.7060806@oracle.com> Hello, Please review a simple refactoring fix in Double.toHexString 6964528: Double.toHexString(double d) String manipulation with + in an append of StringBuilder http://cr.openjdk.java.net/~darcy/6964528.0/ Patch below. Thanks, -Joe --- old/src/share/classes/java/lang/Double.java 2013-02-01 13:36:33.000000000 -0800 +++ new/src/share/classes/java/lang/Double.java 2013-02-01 13:36:33.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1994, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1994, 2013, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -289,7 +289,7 @@ return Double.toString(d); else { // Initialized to maximum size of output. - StringBuffer answer = new StringBuffer(24); + StringBuilder answer = new StringBuilder(24); if (Math.copySign(1.0, d) == -1.0) // value is negative, answer.append("-"); // so append sign info @@ -300,8 +300,7 @@ if(d == 0.0) { answer.append("0.0p0"); - } - else { + } else { boolean subnormal = (d < DoubleConsts.MIN_NORMAL); // Isolate significand bits and OR in a high-order bit @@ -324,13 +323,14 @@ "0": signif.replaceFirst("0{1,12}$", "")); + answer.append("p"); // If the value is subnormal, use the E_min exponent // value for double; otherwise, extract and report d's // exponent (the representation of a subnormal uses // E_min -1). - answer.append("p" + (subnormal ? - DoubleConsts.MIN_EXPONENT: - Math.getExponent(d) )); + answer.append(subnormal ? + DoubleConsts.MIN_EXPONENT: + Math.getExponent(d)); } return answer.toString(); } From lowasser at google.com Fri Feb 1 21:41:31 2013 From: lowasser at google.com (Louis Wasserman) Date: Fri, 1 Feb 2013 13:41:31 -0800 Subject: JDK 8 code review request for 6964528: Double.toHexString(double d) String manipulation with + in an append of StringBuilder In-Reply-To: <510C361C.7060806@oracle.com> References: <510C361C.7060806@oracle.com> Message-ID: Would appending the character 'p' instead of the string "p" make any difference? On Fri, Feb 1, 2013 at 1:39 PM, Joe Darcy wrote: > Hello, > > Please review a simple refactoring fix in Double.toHexString > > 6964528: Double.toHexString(double d) String manipulation with + in an > append of StringBuilder > http://cr.openjdk.java.net/~**darcy/6964528.0/ > > Patch below. > > Thanks, > > -Joe > > --- old/src/share/classes/java/**lang/Double.java 2013-02-01 > 13:36:33.000000000 -0800 > +++ new/src/share/classes/java/**lang/Double.java 2013-02-01 > 13:36:33.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1994, 2012, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1994, 2013, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -289,7 +289,7 @@ > return Double.toString(d); > else { > // Initialized to maximum size of output. > - StringBuffer answer = new StringBuffer(24); > + StringBuilder answer = new StringBuilder(24); > > if (Math.copySign(1.0, d) == -1.0) // value is negative, > answer.append("-"); // so append sign > info > @@ -300,8 +300,7 @@ > > if(d == 0.0) { > answer.append("0.0p0"); > - } > - else { > + } else { > boolean subnormal = (d < DoubleConsts.MIN_NORMAL); > > // Isolate significand bits and OR in a high-order bit > @@ -324,13 +323,14 @@ > "0": > signif.replaceFirst("0{1,12}$"**, "")); > > + answer.append("p"); > // If the value is subnormal, use the E_min exponent > // value for double; otherwise, extract and report d's > // exponent (the representation of a subnormal uses > // E_min -1). > - answer.append("p" + (subnormal ? > - DoubleConsts.MIN_EXPONENT: > - Math.getExponent(d) )); > + answer.append(subnormal ? > + DoubleConsts.MIN_EXPONENT: > + Math.getExponent(d)); > } > return answer.toString(); > } > > -- Louis Wasserman From joe.darcy at oracle.com Fri Feb 1 21:45:18 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 01 Feb 2013 13:45:18 -0800 Subject: JDK 8 code review request for 6964528: Double.toHexString(double d) String manipulation with + in an append of StringBuilder In-Reply-To: References: <510C361C.7060806@oracle.com> Message-ID: <510C376E.5000302@oracle.com> On 02/01/2013 01:41 PM, Louis Wasserman wrote: > Would appending the character 'p' instead of the string "p" make any > difference? Not a big enough one for me to feel compelled to look into it ;-) -Joe > > > On Fri, Feb 1, 2013 at 1:39 PM, Joe Darcy > wrote: > > Hello, > > Please review a simple refactoring fix in Double.toHexString > > 6964528: Double.toHexString(double d) String manipulation with > + in an append of StringBuilder > http://cr.openjdk.java.net/~darcy/6964528.0/ > > > Patch below. > > Thanks, > > -Joe > > --- old/src/share/classes/java/lang/Double.java 2013-02-01 > 13:36:33.000000000 -0800 > +++ new/src/share/classes/java/lang/Double.java 2013-02-01 > 13:36:33.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1994, 2012, Oracle and/or its affiliates. All > rights reserved. > + * Copyright (c) 1994, 2013, Oracle and/or its affiliates. All > rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or > modify it > @@ -289,7 +289,7 @@ > return Double.toString(d); > else { > // Initialized to maximum size of output. > - StringBuffer answer = new StringBuffer(24); > + StringBuilder answer = new StringBuilder(24); > > if (Math.copySign(1.0, d) == -1.0) // value is > negative, > answer.append("-"); // so append > sign info > @@ -300,8 +300,7 @@ > > if(d == 0.0) { > answer.append("0.0p0"); > - } > - else { > + } else { > boolean subnormal = (d < DoubleConsts.MIN_NORMAL); > > // Isolate significand bits and OR in a > high-order bit > @@ -324,13 +323,14 @@ > "0": > signif.replaceFirst("0{1,12}$", "")); > > + answer.append("p"); > // If the value is subnormal, use the E_min exponent > // value for double; otherwise, extract and > report d's > // exponent (the representation of a subnormal uses > // E_min -1). > - answer.append("p" + (subnormal ? > - DoubleConsts.MIN_EXPONENT: > - Math.getExponent(d) )); > + answer.append(subnormal ? > + DoubleConsts.MIN_EXPONENT: > + Math.getExponent(d)); > } > return answer.toString(); > } > > > > > -- > Louis Wasserman From vitalyd at gmail.com Fri Feb 1 22:07:35 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 1 Feb 2013 17:07:35 -0500 Subject: JDK 8 code review request for 6964528: Double.toHexString(double d) String manipulation with + in an append of StringBuilder In-Reply-To: <510C376E.5000302@oracle.com> References: <510C361C.7060806@oracle.com> <510C376E.5000302@oracle.com> Message-ID: I'm with Louis on this one. Since you're changing this code anyway, I don't see any reason to use string here. Sent from my phone On Feb 1, 2013 4:45 PM, "Joe Darcy" wrote: > On 02/01/2013 01:41 PM, Louis Wasserman wrote: > >> Would appending the character 'p' instead of the string "p" make any >> difference? >> > > Not a big enough one for me to feel compelled to look into it ;-) > > -Joe > > >> >> On Fri, Feb 1, 2013 at 1:39 PM, Joe Darcy > joe.darcy at oracle.com>> wrote: >> >> Hello, >> >> Please review a simple refactoring fix in Double.toHexString >> >> 6964528: Double.toHexString(double d) String manipulation with >> + in an append of StringBuilder >> http://cr.openjdk.java.net/~**darcy/6964528.0/ >> >> > >> >> Patch below. >> >> Thanks, >> >> -Joe >> >> --- old/src/share/classes/java/**lang/Double.java 2013-02-01 >> 13:36:33.000000000 -0800 >> +++ new/src/share/classes/java/**lang/Double.java 2013-02-01 >> 13:36:33.000000000 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1994, 2012, Oracle and/or its affiliates. All >> rights reserved. >> + * Copyright (c) 1994, 2013, Oracle and/or its affiliates. All >> rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or >> modify it >> @@ -289,7 +289,7 @@ >> return Double.toString(d); >> else { >> // Initialized to maximum size of output. >> - StringBuffer answer = new StringBuffer(24); >> + StringBuilder answer = new StringBuilder(24); >> >> if (Math.copySign(1.0, d) == -1.0) // value is >> negative, >> answer.append("-"); // so append >> sign info >> @@ -300,8 +300,7 @@ >> >> if(d == 0.0) { >> answer.append("0.0p0"); >> - } >> - else { >> + } else { >> boolean subnormal = (d < DoubleConsts.MIN_NORMAL); >> >> // Isolate significand bits and OR in a >> high-order bit >> @@ -324,13 +323,14 @@ >> "0": >> signif.replaceFirst("0{1,12}$"**, "")); >> >> + answer.append("p"); >> // If the value is subnormal, use the E_min exponent >> // value for double; otherwise, extract and >> report d's >> // exponent (the representation of a subnormal uses >> // E_min -1). >> - answer.append("p" + (subnormal ? >> - DoubleConsts.MIN_EXPONENT: >> - Math.getExponent(d) )); >> + answer.append(subnormal ? >> + DoubleConsts.MIN_EXPONENT: >> + Math.getExponent(d)); >> } >> return answer.toString(); >> } >> >> >> >> >> -- >> Louis Wasserman >> > > From aleksey.shipilev at oracle.com Fri Feb 1 22:10:38 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Sat, 2 Feb 2013 02:10:38 +0400 Subject: JDK 8 code review request for 6964528: Double.toHexString(double d) String manipulation with + in an append of StringBuilder In-Reply-To: References: <510C361C.7060806@oracle.com> <510C376E.5000302@oracle.com> Message-ID: +1. Appending char is marginally faster as well. -Aleksey. On 02.02.2013, at 2:07, Vitaly Davidovich wrote: > I'm with Louis on this one. Since you're changing this code anyway, I > don't see any reason to use string here. > > Sent from my phone > On Feb 1, 2013 4:45 PM, "Joe Darcy" wrote: > >> On 02/01/2013 01:41 PM, Louis Wasserman wrote: >> >>> Would appending the character 'p' instead of the string "p" make any >>> difference? >> >> Not a big enough one for me to feel compelled to look into it ;-) >> >> -Joe >> >> >>> >>> On Fri, Feb 1, 2013 at 1:39 PM, Joe Darcy >> joe.darcy at oracle.com>> wrote: >>> >>> Hello, >>> >>> Please review a simple refactoring fix in Double.toHexString >>> >>> 6964528: Double.toHexString(double d) String manipulation with >>> + in an append of StringBuilder >>> http://cr.openjdk.java.net/~**darcy/6964528.0/ >>> >>> >>> Patch below. >>> >>> Thanks, >>> >>> -Joe >>> >>> --- old/src/share/classes/java/**lang/Double.java 2013-02-01 >>> 13:36:33.000000000 -0800 >>> +++ new/src/share/classes/java/**lang/Double.java 2013-02-01 >>> 13:36:33.000000000 -0800 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 1994, 2012, Oracle and/or its affiliates. All >>> rights reserved. >>> + * Copyright (c) 1994, 2013, Oracle and/or its affiliates. All >>> rights reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> * >>> * This code is free software; you can redistribute it and/or >>> modify it >>> @@ -289,7 +289,7 @@ >>> return Double.toString(d); >>> else { >>> // Initialized to maximum size of output. >>> - StringBuffer answer = new StringBuffer(24); >>> + StringBuilder answer = new StringBuilder(24); >>> >>> if (Math.copySign(1.0, d) == -1.0) // value is >>> negative, >>> answer.append("-"); // so append >>> sign info >>> @@ -300,8 +300,7 @@ >>> >>> if(d == 0.0) { >>> answer.append("0.0p0"); >>> - } >>> - else { >>> + } else { >>> boolean subnormal = (d < DoubleConsts.MIN_NORMAL); >>> >>> // Isolate significand bits and OR in a >>> high-order bit >>> @@ -324,13 +323,14 @@ >>> "0": >>> signif.replaceFirst("0{1,12}$"**, "")); >>> >>> + answer.append("p"); >>> // If the value is subnormal, use the E_min exponent >>> // value for double; otherwise, extract and >>> report d's >>> // exponent (the representation of a subnormal uses >>> // E_min -1). >>> - answer.append("p" + (subnormal ? >>> - DoubleConsts.MIN_EXPONENT: >>> - Math.getExponent(d) )); >>> + answer.append(subnormal ? >>> + DoubleConsts.MIN_EXPONENT: >>> + Math.getExponent(d)); >>> } >>> return answer.toString(); >>> } >>> >>> >>> >>> >>> -- >>> Louis Wasserman >> >> From joe.darcy at oracle.com Fri Feb 1 22:16:34 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 01 Feb 2013 14:16:34 -0800 Subject: JDK 8 code review request for 6964528: Double.toHexString(double d) String manipulation with + in an append of StringBuilder In-Reply-To: References: <510C361C.7060806@oracle.com> <510C376E.5000302@oracle.com> Message-ID: <510C3EC2.3070400@oracle.com> Okay; I concede -- webrev with 'p' rather than "p" uploaded: http://cr.openjdk.java.net/~darcy/6964528.1 Thanks, -Joe On 02/01/2013 02:10 PM, Aleksey Shipilev wrote: > +1. Appending char is marginally faster as well. > > -Aleksey. > > On 02.02.2013, at 2:07, Vitaly Davidovich wrote: > >> I'm with Louis on this one. Since you're changing this code anyway, I >> don't see any reason to use string here. >> >> Sent from my phone >> On Feb 1, 2013 4:45 PM, "Joe Darcy" wrote: >> >>> On 02/01/2013 01:41 PM, Louis Wasserman wrote: >>> >>>> Would appending the character 'p' instead of the string "p" make any >>>> difference? >>> Not a big enough one for me to feel compelled to look into it ;-) >>> >>> -Joe >>> >>> >>>> On Fri, Feb 1, 2013 at 1:39 PM, Joe Darcy >>> joe.darcy at oracle.com>> wrote: >>>> >>>> Hello, >>>> >>>> Please review a simple refactoring fix in Double.toHexString >>>> >>>> 6964528: Double.toHexString(double d) String manipulation with >>>> + in an append of StringBuilder >>>> http://cr.openjdk.java.net/~**darcy/6964528.0/ >>>> >>>> >>>> Patch below. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> --- old/src/share/classes/java/**lang/Double.java 2013-02-01 >>>> 13:36:33.000000000 -0800 >>>> +++ new/src/share/classes/java/**lang/Double.java 2013-02-01 >>>> 13:36:33.000000000 -0800 >>>> @@ -1,5 +1,5 @@ >>>> /* >>>> - * Copyright (c) 1994, 2012, Oracle and/or its affiliates. All >>>> rights reserved. >>>> + * Copyright (c) 1994, 2013, Oracle and/or its affiliates. All >>>> rights reserved. >>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>> * >>>> * This code is free software; you can redistribute it and/or >>>> modify it >>>> @@ -289,7 +289,7 @@ >>>> return Double.toString(d); >>>> else { >>>> // Initialized to maximum size of output. >>>> - StringBuffer answer = new StringBuffer(24); >>>> + StringBuilder answer = new StringBuilder(24); >>>> >>>> if (Math.copySign(1.0, d) == -1.0) // value is >>>> negative, >>>> answer.append("-"); // so append >>>> sign info >>>> @@ -300,8 +300,7 @@ >>>> >>>> if(d == 0.0) { >>>> answer.append("0.0p0"); >>>> - } >>>> - else { >>>> + } else { >>>> boolean subnormal = (d < DoubleConsts.MIN_NORMAL); >>>> >>>> // Isolate significand bits and OR in a >>>> high-order bit >>>> @@ -324,13 +323,14 @@ >>>> "0": >>>> signif.replaceFirst("0{1,12}$"**, "")); >>>> >>>> + answer.append("p"); >>>> // If the value is subnormal, use the E_min exponent >>>> // value for double; otherwise, extract and >>>> report d's >>>> // exponent (the representation of a subnormal uses >>>> // E_min -1). >>>> - answer.append("p" + (subnormal ? >>>> - DoubleConsts.MIN_EXPONENT: >>>> - Math.getExponent(d) )); >>>> + answer.append(subnormal ? >>>> + DoubleConsts.MIN_EXPONENT: >>>> + Math.getExponent(d)); >>>> } >>>> return answer.toString(); >>>> } >>>> >>>> >>>> >>>> >>>> -- >>>> Louis Wasserman >>> From peter.levart at gmail.com Fri Feb 1 22:23:01 2013 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 01 Feb 2013 23:23:01 +0100 Subject: AnnotationType alternative patch Message-ID: <510C4045.7000206@gmail.com> Hello Joel and the list, While revisiting the patch that I proposed a couple of months ago: http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-December/012630.html ...and which also includes some other things besides the main fix for scalability and dead-locks, I tried to see what It would take to modify the annotation parsing logic in a way that would make construction of AnnotationType instance infinite-recursion-free without resorting to publishing the reference to the instance in the middle of the constructor. As it turns out the changes are quite simple: http://freeweb.t-2.net/peter_levart/jdk8-tl/AnnotationType/webrev.01/index.html I added an overloaded method to AnnotationParser which only parses select annotations (quickly skipping the rest of raw annotation bytes) and implicitly considers those annotations as having RUNTIME retention. This method is used inside the constructor of AnnotationType just for parsing the @Retention and @Inherited meta annotations for annotation class. This way the infinite recursion is broken and there's no need to publish the half-constructed instance just to prevent it. Everything else is easy: the AnnotationType class is now immutable (all fields final) and can be published to other threads via data race (removed synchronized from AnnotationType.getInstance()). Scalability is infinite and dead-locks are eliminated. This patch also fixes inconsistent behavior when we have two mutually recursive RUNTIME annotations and one's scope is changed to CLASS and separately compiled - the situation that I described in above-mentioned message. Regards, Peter From joel.franck at oracle.com Fri Feb 1 22:30:47 2013 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Fri, 1 Feb 2013 23:30:47 +0100 Subject: Code review request for 8007113 Upgrade AnnotatedElement.isAnnotionPresent to be a default method In-Reply-To: <510C3370.7010501@oracle.com> References: <510B34CB.5070009@oracle.com> <510B8F18.3010905@oracle.com> <510C147B.7060103@oracle.com> <510C3370.7010501@oracle.com> Message-ID: Looks good (but I'm not a reviewer-kind of reviewer). cheers /Joel On Feb 1, 2013, at 10:28 PM, Joe Darcy wrote: > On 02/01/2013 11:16 AM, Joe Darcy wrote: >> Hi Joel, >> >> On 2/1/2013 1:47 AM, Joel Borggr?n-Franck wrote: >>> Hi Joe, >>> >>> On 02/01/2013 04:21 AM, Joe Darcy wrote: >>>> Hello, >>>> >>>> I'd like to upgrade the existing AnnotatedElement.isAnnotationPresent >>>> interface method to a default method: >>>> >>>> 8007113 Upgrade AnnotatedElement.isAnnotionPresent to be a default method >>>> http://cr.openjdk.java.net/~darcy/8007113.0/ >>>> >>> >>> How about sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java ? >>> >>> It looks like I forgot to update that one when I did the type annotations changes :) >> >> I did notice TypeVariableImpl as one of the implementers of AnnotatedElement, but since it was defined to just return false, I skipped it. However, since getAnnotation now works for type variables, that behavior is incorrect. >> >> I'll update the webrev to cover TypeVariableImpl too. >> >> Thanks, >> > > New webrev posted with a typo fix and TypeVariableImpl covered: > > http://cr.openjdk.java.net/~darcy/8007113.1/ > > Thanks, > > -Joe > From david.holmes at oracle.com Fri Feb 1 22:37:28 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 02 Feb 2013 08:37:28 +1000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <510BD3E6.1090103@oracle.com> References: <510BD3E6.1090103@oracle.com> Message-ID: <510C43A8.7040805@oracle.com> Hi Chris, On 2/02/2013 12:40 AM, Chris Hegarty wrote: > [ to build-dev and core-libs-dev, expect reviewer from either, but will > integrate through jdk8/tl ] > > This issue is mainly of interest to Oracle engineers, but it effects the > public hgforest script. > > When hgforest.sh is run with an addition argument to specify a closed > server, there is a problem/race between the creation of the directories > to hold nested repositories and the clone itself. These directories need > to be created before the clone command is executed, otherwise it will > fail, as below. I think I reported this myself just last week - probably internally to build or build-infra. The weird thing is that based on the list of repos it shouldn't be grabbing the closed one yet. > The trivial fix is to back off these nested repos until their containing > directory exists. That seems to assume/require that the nested repo will always be later in the list. They happen to be but .... Workaround is to run get_source.sh twice first without the "extra base" then with it. David ----- > > Webrev: > http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ > > sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log > # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed > jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed > hotspot/test/closed deploy install sponsors pubs > > Waiting 5 secs before spawning next background command. > Waiting 5 secs before spawning next background command. > Waiting 5 secs before spawning next background command. > jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u > /java/devtools/sparc/mercurial/latest/bin/hg clone > http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed > jdk/src/closed: abort: No such file or directory: jdk/src/closed > jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u > /java/devtools/sparc/mercurial/latest/bin/hg clone > http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed > jdk/make/closed: abort: No such file or directory: jdk/make/closed > Waiting 5 secs before spawning next background command. > .... > > > -Chris. From chris.hegarty at oracle.com Fri Feb 1 23:06:32 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 1 Feb 2013 23:06:32 +0000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <510C43A8.7040805@oracle.com> References: <510BD3E6.1090103@oracle.com> <510C43A8.7040805@oracle.com> Message-ID: On 1 Feb 2013, at 22:37, David Holmes wrote: > Hi Chris, > > On 2/02/2013 12:40 AM, Chris Hegarty wrote: >> [ to build-dev and core-libs-dev, expect reviewer from either, but will >> integrate through jdk8/tl ] >> >> This issue is mainly of interest to Oracle engineers, but it effects the >> public hgforest script. >> >> When hgforest.sh is run with an addition argument to specify a closed >> server, there is a problem/race between the creation of the directories >> to hold nested repositories and the clone itself. These directories need >> to be created before the clone command is executed, otherwise it will >> fail, as below. > > I think I reported this myself just last week - probably internally to build or build-infra. Ah, I missed that. > The weird thing is that based on the list of repos it shouldn't be grabbing the closed one yet. In my remote/slow environment I end up with all clones running concurrently. > >> The trivial fix is to back off these nested repos until their containing >> directory exists. > > That seems to assume/require that the nested repo will always be later in the list. They happen to be but .... No so. It will just wait for the process to clone the outer repo to start. > > Workaround is to run get_source.sh twice first without the "extra base" then with it. Good suggestion. -Chris > > David > ----- > >> >> Webrev: >> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >> >> sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log >> # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed >> jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed >> hotspot/test/closed deploy install sponsors pubs >> >> Waiting 5 secs before spawning next background command. >> Waiting 5 secs before spawning next background command. >> Waiting 5 secs before spawning next background command. >> jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >> /java/devtools/sparc/mercurial/latest/bin/hg clone >> http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed >> jdk/src/closed: abort: No such file or directory: jdk/src/closed >> jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >> /java/devtools/sparc/mercurial/latest/bin/hg clone >> http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed >> jdk/make/closed: abort: No such file or directory: jdk/make/closed >> Waiting 5 secs before spawning next background command. >> .... >> >> >> -Chris. From eric.mccorkle at oracle.com Fri Feb 1 23:19:25 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Fri, 01 Feb 2013 18:19:25 -0500 Subject: Review Request for JDK-8007389: Remove uses of _ as identifier in jaxp In-Reply-To: <654238BD-516E-4AFD-8C01-C64AAC2ADF50@oracle.com> References: <510BF121.30105@oracle.com> <654238BD-516E-4AFD-8C01-C64AAC2ADF50@oracle.com> Message-ID: <510C4D7D.8010205@oracle.com> Thanks. Do I have a second? On 02/01/13 12:04, Lance Andersen - Oracle wrote: > Its OK. > > Not sure I would have replaced it with 'unused' but not a big deal as it is just a personal preference. > > > On Feb 1, 2013, at 11:45 AM, Eric McCorkle wrote: > >> Hello, >> >> Please review this trivial patch which removes uses of _ as an >> identifier in the jaxp API. >> >> The webrev is here: >> http://cr.openjdk.java.net/~emc/8007389/ >> >> The bug should be here, but does not seem to be showing up yet: >> http://bugs.sun.com/view_bug.do?bug_id=8007389 > > > > > 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 Sat Feb 2 00:37:45 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 02 Feb 2013 10:37:45 +1000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: References: <510BD3E6.1090103@oracle.com> <510C43A8.7040805@oracle.com> Message-ID: <510C5FD9.902@oracle.com> On 2/02/2013 9:06 AM, Chris Hegarty wrote: > > On 1 Feb 2013, at 22:37, David Holmes wrote: > >> Hi Chris, >> >> On 2/02/2013 12:40 AM, Chris Hegarty wrote: >>> [ to build-dev and core-libs-dev, expect reviewer from either, but will >>> integrate through jdk8/tl ] >>> >>> This issue is mainly of interest to Oracle engineers, but it effects the >>> public hgforest script. >>> >>> When hgforest.sh is run with an addition argument to specify a closed >>> server, there is a problem/race between the creation of the directories >>> to hold nested repositories and the clone itself. These directories need >>> to be created before the clone command is executed, otherwise it will >>> fail, as below. >> >> I think I reported this myself just last week - probably internally to build or build-infra. > > Ah, I missed that. > >> The weird thing is that based on the list of repos it shouldn't be grabbing the closed one yet. > > In my remote/slow environment I end up with all clones running concurrently. I can see that happening if the sleeps are too short. But what I noticed from the logging was that the closed repos were being processed before the open ones - which shouldn't happen. >> >>> The trivial fix is to back off these nested repos until their containing >>> directory exists. >> >> That seems to assume/require that the nested repo will always be later in the list. They happen to be but .... > > No so. It will just wait for the process to clone the outer repo to start. Ok. Some clone will make progress and so we should ultimately get to start the outer repo. Thanks, David >> >> Workaround is to run get_source.sh twice first without the "extra base" then with it. > > Good suggestion. > > -Chris > >> >> David >> ----- >> >>> >>> Webrev: >>> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >>> >>> sh ./get_source.sh http://xxx.yyy.oracle.com |& tee clone.log >>> # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed >>> jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed >>> hotspot/test/closed deploy install sponsors pubs >>> >>> Waiting 5 secs before spawning next background command. >>> Waiting 5 secs before spawning next background command. >>> Waiting 5 secs before spawning next background command. >>> jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed >>> jdk/src/closed: abort: No such file or directory: jdk/src/closed >>> jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed >>> jdk/make/closed: abort: No such file or directory: jdk/make/closed >>> Waiting 5 secs before spawning next background command. >>> .... >>> >>> >>> -Chris. From kumar.x.srinivasan at oracle.com Sat Feb 2 00:49:24 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 01 Feb 2013 16:49:24 -0800 Subject: Please review JDK-8007428: [launcher] add tools/launcher/FXLauncherTest.java to ProblemList.txt Message-ID: <510C6294.702@oracle.com> Hi, Simple fix to disable this launcher test with FX, apparently a FX bug. Thanks Kumar diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -327,6 +327,9 @@ # 7150569 tools/launcher/UnicodeTest.java macosx-all +# 8007410 +tools/launcher/FXLauncherTest.java linux-all + ############################################################################ # jdk_jdi From mandy.chung at oracle.com Sat Feb 2 00:54:52 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 01 Feb 2013 16:54:52 -0800 Subject: Please review JDK-8007428: [launcher] add tools/launcher/FXLauncherTest.java to ProblemList.txt In-Reply-To: <510C6294.702@oracle.com> References: <510C6294.702@oracle.com> Message-ID: <510C63DC.3030801@oracle.com> On 2/1/2013 4:49 PM, Kumar Srinivasan wrote: > Hi, > > Simple fix to disable this launcher test with FX, apparently > a FX bug. > Thumbs up. I didn't check the test logs - just to confirm - this test passes on other platforms except linux? Mandy > Thanks > Kumar > > > diff --git a/test/ProblemList.txt b/test/ProblemList.txt > --- a/test/ProblemList.txt > +++ b/test/ProblemList.txt > @@ -327,6 +327,9 @@ > # 7150569 > tools/launcher/UnicodeTest.java macosx-all > > +# 8007410 > +tools/launcher/FXLauncherTest.java linux-all > + > ############################################################################ > > > # jdk_jdi > From kumar.x.srinivasan at oracle.com Sat Feb 2 01:12:33 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 01 Feb 2013 17:12:33 -0800 Subject: Please review JDK-8007428: [launcher] add tools/launcher/FXLauncherTest.java to ProblemList.txt In-Reply-To: <510C63DC.3030801@oracle.com> References: <510C6294.702@oracle.com> <510C63DC.3030801@oracle.com> Message-ID: <510C6801.9040405@oracle.com> On 2/1/2013 4:54 PM, Mandy Chung wrote: > > > On 2/1/2013 4:49 PM, Kumar Srinivasan wrote: >> Hi, >> >> Simple fix to disable this launcher test with FX, apparently >> a FX bug. >> > > Thumbs up. I didn't check the test logs - just to confirm - this test > passes on other platforms except linux? yes, apparently FX/graphics/libglass.so linkage issue. Kumar > > Mandy > >> Thanks >> Kumar >> >> >> diff --git a/test/ProblemList.txt b/test/ProblemList.txt >> --- a/test/ProblemList.txt >> +++ b/test/ProblemList.txt >> @@ -327,6 +327,9 @@ >> # 7150569 >> tools/launcher/UnicodeTest.java macosx-all >> >> +# 8007410 >> +tools/launcher/FXLauncherTest.java linux-all >> + >> ############################################################################ >> >> >> # jdk_jdi >> From mandy.chung at oracle.com Sat Feb 2 01:18:06 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 01 Feb 2013 17:18:06 -0800 Subject: Please review JDK-8007428: [launcher] add tools/launcher/FXLauncherTest.java to ProblemList.txt In-Reply-To: <510C6801.9040405@oracle.com> References: <510C6294.702@oracle.com> <510C63DC.3030801@oracle.com> <510C6801.9040405@oracle.com> Message-ID: <510C694E.4080009@oracle.com> On 2/1/2013 5:12 PM, Kumar Srinivasan wrote: > On 2/1/2013 4:54 PM, Mandy Chung wrote: >> >> Thumbs up. I didn't check the test logs - just to confirm - this >> test passes on other platforms except linux? > > yes, apparently FX/graphics/libglass.so linkage issue. > thanks. approved. Mandy From brian.burkhalter at oracle.com Sat Feb 2 01:19:43 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 1 Feb 2013 17:19:43 -0800 Subject: Math.round(...) and bug 6430675 In-Reply-To: <1359667580.92728.YahooMailNeo@web132106.mail.ird.yahoo.com> References: <1359667580.92728.YahooMailNeo@web132106.mail.ird.yahoo.com> Message-ID: <97FBDF44-F141-4158-B16F-0C4BFA9330EF@oracle.com> Hi Jeff, Based on my tests it looks as if you are correct about the behavior. Would you mind filing an issue so that this may be tracked? Thanks, Brian On Jan 31, 2013, at 1:26 PM, Jeff Hain wrote: > Hi. > > Since 6430675 fix, Math.round(float) and Math.round(double) > specs no longer specify rounding by adding 0.5 and then using floor, > and let the user believe that they "now round up properly". > > However playing with fresh JDK 7 and 8 versions I saw that > these methods still exhibit some suprising results coming > from adding 0.5 and then using floor. > For example, for odd values in [8388609.0f,16777215.0f] or > [-16777215.0f,-8388609.0f], which are mathematical integers, > Math.round(float) returns value+1. > > Shouldn't the references to floor(value+0.5(f/d)) be restored > in the specs, or the implementations having a work-around for > these cases? > > -Jeff From joe.darcy at oracle.com Sat Feb 2 03:30:18 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Sat, 02 Feb 2013 03:30:18 +0000 Subject: hg: jdk8/tl/jdk: 6964528: Double.toHexString(double d) String manipulation with + in an append of StringBuilder Message-ID: <20130202033040.8FE714779B@hg.openjdk.java.net> Changeset: cba578db5f39 Author: darcy Date: 2013-02-01 19:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cba578db5f39 6964528: Double.toHexString(double d) String manipulation with + in an append of StringBuilder Reviewed-by: shade ! src/share/classes/java/lang/Double.java From kumar.x.srinivasan at oracle.com Sat Feb 2 06:14:53 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Sat, 02 Feb 2013 06:14:53 +0000 Subject: hg: jdk8/tl/jdk: 8003549: (pack200) assertion errors when processing lambda class files with IMethods Message-ID: <20130202061505.74629477A0@hg.openjdk.java.net> Changeset: c1aaa8451547 Author: ksrini Date: 2013-02-01 22:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1aaa8451547 8003549: (pack200) assertion errors when processing lambda class files with IMethods Summary: add more check for opcode, sketch provided by jrose Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! 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/Instruction.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java ! src/share/classes/com/sun/java/util/jar/pack/PropMap.java ! src/share/classes/com/sun/java/util/jar/pack/Utils.java ! test/ProblemList.txt + test/tools/pack200/InstructionTests.java ! test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java From kumar.x.srinivasan at oracle.com Sat Feb 2 06:19:32 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Sat, 02 Feb 2013 06:19:32 +0000 Subject: hg: jdk8/tl/jdk: 8007428: [launcher] add tools/launcher/FXLauncherTest.java to ProblemList.txt Message-ID: <20130202061944.78EC3477A1@hg.openjdk.java.net> Changeset: 6c88a12ea834 Author: ksrini Date: 2013-02-01 22:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6c88a12ea834 8007428: [launcher] add tools/launcher/FXLauncherTest.java to ProblemList.txt Reviewed-by: mchung ! test/ProblemList.txt From chris.hegarty at oracle.com Sat Feb 2 07:58:42 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 02 Feb 2013 07:58:42 +0000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <510C5FD9.902@oracle.com> References: <510BD3E6.1090103@oracle.com> <510C43A8.7040805@oracle.com> <510C5FD9.902@oracle.com> Message-ID: <510CC732.1070607@oracle.com> On 02/02/2013 12:37 AM, David Holmes wrote: > ... > > I can see that happening if the sleeps are too short. But what I noticed > from the logging was that the closed repos were being processed before > the open ones - which shouldn't happen. I believe the output is misleading. I think the output from the subprocesses, doing the clones, is being buffered and not quickly echoed by the parent process. This then gives the perception that they are executing first, when they are not. -Chris. From jeffhain at rocketmail.com Sat Feb 2 09:40:58 2013 From: jeffhain at rocketmail.com (Jeff Hain) Date: Sat, 2 Feb 2013 09:40:58 +0000 (GMT) Subject: Math.round(...) and bug 6430675 In-Reply-To: <97FBDF44-F141-4158-B16F-0C4BFA9330EF@oracle.com> References: <1359667580.92728.YahooMailNeo@web132106.mail.ird.yahoo.com> <97FBDF44-F141-4158-B16F-0C4BFA9330EF@oracle.com> Message-ID: <1359798058.38334.YahooMailNeo@web132106.mail.ird.yahoo.com> >Would you mind filing an issue so that this may be tracked? Done: "Math.round has surprising behavior for odd values of ulp 1" -Jeff From chris.hegarty at oracle.com Sat Feb 2 17:17:54 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sat, 02 Feb 2013 17:17:54 +0000 Subject: hg: jdk8/tl/jdk: 8007322: untangle ftp protocol from general networking URL tests Message-ID: <20130202171835.0C9F0477AA@hg.openjdk.java.net> Changeset: ee83319029a5 Author: chegar Date: 2013-02-02 17:15 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ee83319029a5 8007322: untangle ftp protocol from general networking URL tests Reviewed-by: alanb ! test/java/net/URL/Constructor.java ! test/java/net/URL/HandlerLoop.java ! test/java/net/URL/Test.java ! test/java/net/URL/URIToURLTest.java - test/java/net/URL/abnormal_http_urls - test/java/net/URL/ftp_urls - test/java/net/URL/jar_urls - test/java/net/URL/normal_http_urls - test/java/net/URL/runconstructor.sh - test/java/net/URL/share_file_urls - test/java/net/URL/win32_file_urls ! test/java/net/URLConnection/RequestProperties.java ! test/java/net/URLConnection/RequestPropertyValues.java + test/sun/net/ftp/EncDec.doc + test/sun/net/ftp/MarkResetTest.java + test/sun/net/ftp/MarkResetTest.sh - test/sun/net/www/EncDec.doc - test/sun/net/www/MarkResetTest.java - test/sun/net/www/MarkResetTest.sh ! test/sun/net/www/http/HttpClient/ProxyTest.java From kumar.x.srinivasan at oracle.com Sat Feb 2 20:04:16 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Sat, 02 Feb 2013 12:04:16 -0800 Subject: Please review simple change: 8007135: tools/launcher/VersionCheck.java failing with new tool jabswitch Message-ID: <510D7140.8070102@oracle.com> Hi, Webrev here: http://cr.openjdk.java.net/~ksrini/8007135/webrev/ Contributed-by: Ragin from the awt team. Thanks Kumar From kumar.x.srinivasan at oracle.com Sat Feb 2 20:09:37 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Sat, 02 Feb 2013 20:09:37 +0000 Subject: hg: jdk8/tl/jdk: 8007135: tools/launcher/VersionCheck.java failing with new tool jabswitch Message-ID: <20130202201002.9FBF7477B0@hg.openjdk.java.net> Changeset: 25831e7009c4 Author: ksrini Date: 2013-02-02 12:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/25831e7009c4 8007135: tools/launcher/VersionCheck.java failing with new tool jabswitch Reviewed-by: ksrini, mduigou Contributed-by: ragini.prasad at oracle.com ! test/tools/launcher/VersionCheck.java From mike.duigou at oracle.com Sat Feb 2 20:40:53 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Sat, 2 Feb 2013 12:40:53 -0800 Subject: RFR : 8006594/8006595 : Define jdk_core test set In-Reply-To: References: <216D5987-F917-473E-98EF-C84BAB302C53@oracle.com> <50FFF51B.1030809@oracle.com> Message-ID: <04B58247-CBCC-4825-8CC8-38236442E24A@oracle.com> I have updated both the jdk repo patch: 8006594: Add jdk_core target to jdk/test/Makefile http://cr.openjdk.java.net/~mduigou/JDK-8006594/1/webrev/ and the root repo patch: 8006595: Use jdk/test/Makefile targets in preference to local definitions http://cr.openjdk.java.net/~mduigou/JDK-8006595/1/webrev/ The primary difference between this version and the previous is the judicious use of "-k" option and silencing of command spew. A top-level make test TEST=jdk_core now succeeds even if sub-tests fail. I investigated changing the behaviour which determines the test output location so that all jdk_core output would be in a single directory. I have opted to not change it yet as I can't be certain what depends upon the current behaviour. I would like to change one additional aspect--currently the "prep" target forces the output dir to be wiped via a dependency on "clean". I would like to remove this dependency and not wipe the output dir with each run. For RE and JPRT uses they are likely to be running in fresh directories anyway so this change should only impact developers who likely wouldn't want the complete wipe anyway. There are some things about the jtreg_tests target which seem very specific to how JPRT uses this makefile. Not all of the behaviours, such as bundling of test output into zip files, make sense for all likely users of this makefile. I will work with Kelly to partition the JPRT functionality and better understand how this Makefile is used by JPRT for future patches. Mike On Jan 29 2013, at 11:31 , Mike Duigou wrote: > > On Jan 23 2013, at 06:35 , Alan Bateman wrote: > >> On 22/01/2013 21:15, Mike Duigou wrote: >>> Hello all; >>> >>> This is a two piece patch. >>> >>> 8006594: Add jdk_core target to jdk/test/Makefile >>> 8006595: Use jdk/test/Makefile targets in preference to local definitions >>> >>> I chose to do it as two patches because the changes are in different repos and the changes in 8006594 could be committed without the 8006595 changes. >>> >>> The webrevs are: >>> >>> http://cr.openjdk.java.net/~mduigou/8006594/0/webrev/ >> The changes in this one look okay to me but doesn't it mean that not all targets will be run if there is a test failure? > > I'm going to investigate calling make with the -k option as jon gibbons suggests. > >> For example, if a test in the jdk_lang target failures then I assume this will cause make to abort and none of the other test targets will run. >> >> The other thing that is that I assume this means the results are in scattered locations where I would think that anyone doing "make test TEST=jdk_core" would expect to get one set of results. > > My strategy for this is to use an explicit reporting stage to generate the jtreg report and not generate reports for each test target. I am still working on this piece. > >> As an aside, I personally prefer to run jtreg directly and I keep a "core.list" with the exploded list of directories that corresponds to jdk_core in this webrev. The nice thing about it is that it is one jtreg run so all the results in together and easily browsed. You mentioned that this is the in a series of patches so you might be looking into moving in that direction too. >>> >>> http://cr.openjdk.java.net/~mduigou/8006595/0/webrev/ >> The comment on L83 says "everything", maybe that should be updated (it was wrong before your change too). Otherwise I think this is okay. It's a pity that we have the list of targets in so many places, it's so easy to have mis-matches. > > I will try to remove the need to list the test targets in future patches. I will possibly just pass TEST to the jdk/test/Makefile. > >> >> You mentioned pushing this via jdk8/build but it's probably okay to push it via jdk8/tl because the build doesn't care about the test Makefiles. > > Noted. Removing build-dev. > > Mike From vicente.romero at oracle.com Sat Feb 2 21:50:03 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Sat, 02 Feb 2013 21:50:03 +0000 Subject: hg: jdk8/tl/langtools: 8005075: Pool.Method, and Pool.Variable redundant Symbol field should be removed Message-ID: <20130202215006.3A5B9477B4@hg.openjdk.java.net> Changeset: 4cc73ec94686 Author: vromero Date: 2013-02-02 21:04 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4cc73ec94686 8005075: Pool.Method, and Pool.Variable redundant Symbol field should be removed Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java From vicente.romero at oracle.com Sun Feb 3 02:33:08 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Sun, 03 Feb 2013 02:33:08 +0000 Subject: hg: jdk8/tl/langtools: 7199823: javac generates inner class that can't be verified Message-ID: <20130203023317.D15C2477B9@hg.openjdk.java.net> Changeset: a51a8dac0a2f Author: vromero Date: 2013-02-03 02:31 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a51a8dac0a2f 7199823: javac generates inner class that can't be verified Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/7199823/InnerClassCannotBeVerified.java From dmitry.degrave at oracle.com Sun Feb 3 14:21:53 2013 From: dmitry.degrave at oracle.com (dmitry.degrave at oracle.com) Date: Sun, 03 Feb 2013 14:21:53 +0000 Subject: hg: jdk8/tl/jdk: 6471906: java.lang.NegativeArraySizeException in tenToThe Message-ID: <20130203142216.7F1E2477BE@hg.openjdk.java.net> Changeset: 308d1362b60a Author: dmeetry Date: 2013-02-03 18:20 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/308d1362b60a 6471906: java.lang.NegativeArraySizeException in tenToThe Reviewed-by: darcy Contributed-by: brian.burkhalter at oracle.com ! src/share/classes/java/math/BigDecimal.java From dmitry.samersoff at oracle.com Sun Feb 3 17:40:26 2013 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Sun, 03 Feb 2013 17:40:26 +0000 Subject: hg: jdk8/tl/jdk: 8002048: Protocol to discovery of manageable Java processes on a network Message-ID: <20130203174102.567C3477C3@hg.openjdk.java.net> Changeset: 962d6612cace Author: dsamersoff Date: 2013-02-03 21:39 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/962d6612cace 8002048: Protocol to discovery of manageable Java processes on a network Summary: Introduce a protocol to discover manageble Java instances across a network subnet, JDP Reviewed-by: sla, dfuchs ! src/share/classes/sun/management/Agent.java + src/share/classes/sun/management/jdp/JdpBroadcaster.java + src/share/classes/sun/management/jdp/JdpController.java + src/share/classes/sun/management/jdp/JdpException.java + src/share/classes/sun/management/jdp/JdpGenericPacket.java + src/share/classes/sun/management/jdp/JdpJmxPacket.java + src/share/classes/sun/management/jdp/JdpPacket.java + src/share/classes/sun/management/jdp/JdpPacketReader.java + src/share/classes/sun/management/jdp/JdpPacketWriter.java + src/share/classes/sun/management/jdp/package-info.java + test/sun/management/jdp/JdpClient.java + test/sun/management/jdp/JdpDoSomething.java + test/sun/management/jdp/JdpTest.sh + test/sun/management/jdp/JdpUnitTest.java From stevenschlansker at gmail.com Mon Feb 4 05:26:38 2013 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Sun, 3 Feb 2013 21:26:38 -0800 Subject: RFR (S) CR 8006627: Improving performance and reducing object allocations of java.util.UUID to/from string In-Reply-To: References: <84A32ABE-B1E7-4E03-9843-DDFE20897B77@oracle.com> <0EC036A3-3D11-4F56-B3FD-403CCC610347@gmail.com> Message-ID: On Feb 1, 2013, at 11:42 AM, Mike Duigou wrote: > > I have created another issue 8007398 for the changes to Long. We can even test and push the two issues at the same time. Separating them into two changesets makes the intent easier to follow for future maintainers. > > We can use the same webrev. There's no need to create another. > >>> - I would like to see if performed of toString() can be improved further by using String(char[] value, boolean share) constructor via a sun.miscSharedSecret.JavaLangAccesss method to construct the string directly from the character array. You could test to see if this has positive benefit by temporarily using a static char array. >> >> I will incorporate this into my next revision >> >>> >>> - public static String toString(long msb, long lsb) should be private. There's no compelling reason to add this to the API. >> >>> - Have you run this code against any of the existing regression tests? >> >> Yes, I ran the jtreg UUID and Long tests, all pass. I ran the Apache Harmony UUID test cases against the pre-integrated version of the code. (There should only have been minor modifications since then, variable renamings, whatnot?) > > OK, once we have a final webrev then I will run final tests and push this! Hi, Here are the updates to the webrev. I hope the changes are in line with what you'd had in mind: http://dl.dropbox.com/u/1422321/uuid_webrev/index.html http://dl.dropbox.com/u/1422321/uuid_webrev.zip Please let me know if there are any further modifications I should make. Thanks! Steven From mike.duigou at oracle.com Mon Feb 4 05:39:52 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Sun, 3 Feb 2013 21:39:52 -0800 Subject: RFR (S) CR 8006627: Improving performance and reducing object allocations of java.util.UUID to/from string In-Reply-To: References: <84A32ABE-B1E7-4E03-9843-DDFE20897B77@oracle.com> <0EC036A3-3D11-4F56-B3FD-403CCC610347@gmail.com> Message-ID: <34E9C353-9C09-4B8E-B164-9008EB2F3A7B@oracle.com> This looks fairly much complete to me. I will run it through the some testing here and then push your patch. Great work and thank you! Mike On Feb 3 2013, at 21:26 , Steven Schlansker wrote: > > On Feb 1, 2013, at 11:42 AM, Mike Duigou wrote: >> >> I have created another issue 8007398 for the changes to Long. We can even test and push the two issues at the same time. Separating them into two changesets makes the intent easier to follow for future maintainers. >> >> We can use the same webrev. There's no need to create another. >> >>>> - I would like to see if performed of toString() can be improved further by using String(char[] value, boolean share) constructor via a sun.miscSharedSecret.JavaLangAccesss method to construct the string directly from the character array. You could test to see if this has positive benefit by temporarily using a static char array. >>> >>> I will incorporate this into my next revision >>> >>>> >>>> - public static String toString(long msb, long lsb) should be private. There's no compelling reason to add this to the API. >>> >>>> - Have you run this code against any of the existing regression tests? >>> >>> Yes, I ran the jtreg UUID and Long tests, all pass. I ran the Apache Harmony UUID test cases against the pre-integrated version of the code. (There should only have been minor modifications since then, variable renamings, whatnot?) >> >> OK, once we have a final webrev then I will run final tests and push this! > > Hi, > > Here are the updates to the webrev. I hope the changes are in line with what you'd had in mind: > http://dl.dropbox.com/u/1422321/uuid_webrev/index.html > http://dl.dropbox.com/u/1422321/uuid_webrev.zip > > Please let me know if there are any further modifications I should make. > > Thanks! > Steven > From weijun.wang at oracle.com Mon Feb 4 06:38:37 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 04 Feb 2013 14:38:37 +0800 Subject: geteuid(2) in java? Message-ID: <510F576D.6060805@oracle.com> Need an equivalence of the geteuid() function that returns the effective user ID of the calling process. Thanks Max From peter.levart at gmail.com Mon Feb 4 08:42:57 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 04 Feb 2013 09:42:57 +0100 Subject: Parallel ClassLoading space optimizations In-Reply-To: <510B3E17.3050104@oracle.com> References: <50BF371A.1060604@oracle.com> <510A38BB.3090103@oracle.com> <510A6C8B.60701@gmail.com> <510B3E17.3050104@oracle.com> Message-ID: <510F7491.1040505@gmail.com> Hi David, I might have something usable, but I just wanted to verify some things beforehand. What I investigated was a simple keeping a cache of locks in a map weekly referenced. In your blog: * https://blogs.oracle.com/dholmes/entry/parallel_classloading_revisited_fully_concurrent ...you describe this a a 3rd alternative: /3. Reduce the lifetime of lock objects so that entries are removed from the map when no longer needed (eg remove after loading,*use weak references* to the lock objects and cleanup the map periodically)./ ...but later you preclude this option: /Similarly we might reason that we can remove a mapping (and the lock object) because the class is already loaded, but this would again violate the specification because it can be reasoned that the following assertion should hold true: / | Object lock1 = loader.getClassLoadingLock(name); loader.loadClass(name); Object lock2 = loader.getClassLoadingLock(name); assert lock1 == lock2; | /Without modifying the specification, or at least doing some creative wordsmithing on it, options 1 and 3 are precluded. / When using WeakReferences to cache lock Objects, the above assertion would still hold true, wouldn't it? I can not think of any reasonable 3rd party ClassLoader code that would behave differently when having lock objects strongly referenced for the entire VM lifetime vs. having them temporarily weakly referenced and eventually recreated if needed. For example, only code that does the following things can see difference: * use .toString or .hashCode on lock object and keep it somewhere without also keeping the lock object itself to use it later * wrap a lock object into a WeakReference and observe reference being cleared or not Is that a reasonable assumption to continue in this direction? If the semantics are reasonably OK, then all the solution has to prove is (space and time) performance, right? Here's some preliminary illustration what can be achieved space-wise. This is a test that attempts to load all the classes from the rt.jar. The situation we have now (using -Xms256m -Xmx256m and 32bit addresses): ...At the beginning of main() Total memory: 257294336 bytes Free memory: 251920320 bytes Deep size of sun.misc.Launcher$ExtClassLoader at 3d4eac69: 7936 bytes Deep size of sun.misc.Launcher$AppClassLoader at 55f96302: 30848 bytes Deep size of both: 38784 bytes (reference) ...Attempted to load: 18558 classes in: 1964.55825 ms Total memory: 257294336 bytes Free memory: 227314112 bytes Deep size of sun.misc.Launcher$ExtClassLoader at 3d4eac69: 1162184 bytes Deep size of sun.misc.Launcher$AppClassLoader at 55f96302: 2215216 bytes Deep size of both: 3377400 bytes (difference to reference: 3338616 bytes) ...Performing gc() ...Loading class: test.TestClassLoader$Last (to trigger expunging) Total memory: 260440064 bytes Free memory: 193163368 bytes Deep size of sun.misc.Launcher$ExtClassLoader at 3d4eac69: 1162328 bytes Deep size of sun.misc.Launcher$AppClassLoader at 55f96302: 2215408 bytes Deep size of both: 3377736 bytes (difference to reference: 3338952 bytes) vs. having lock objects weekly referenced and doing expunging work at each request for a lock: ...At the beginning of main() Total memory: 257294336 bytes Free memory: 251920320 bytes Deep size of sun.misc.Launcher$ExtClassLoader at 75b84c92: 9584 bytes Deep size of sun.misc.Launcher$AppClassLoader at 42a57993: 33960 bytes Deep size of both: 43544 bytes (reference) Lock stats... create: 108 return old: 0 replace: 0 expunge: 0 ...Attempted to load: 18558 classes in: 2005.14628 ms Total memory: 257294336 bytes Free memory: 187198776 bytes Deep size of sun.misc.Launcher$ExtClassLoader at 75b84c92: 572768 bytes Deep size of sun.misc.Launcher$AppClassLoader at 42a57993: 1122976 bytes Deep size of both: 1695744 bytes (difference to reference: 1652200 bytes) Lock stats... create: 37302 return old: 201 replace: 0 expunge: 25893 ...Performing gc() ...Loading class: test.TestClassLoader$Last (to trigger expunging) Total memory: 257294336 bytes Free memory: 238693336 bytes Deep size of sun.misc.Launcher$ExtClassLoader at 75b84c92: 78944 bytes Deep size of sun.misc.Launcher$AppClassLoader at 42a57993: 168512 bytes Deep size of both: 247456 bytes (difference to reference: 203912 bytes) Lock stats... create: 2 return old: 0 replace: 0 expunge: 11517 ... as can be seen from this particular usecase, there's approx. 20% overhead of storage for locks because of WeakReference indirection (at the beginning of main() before any expunging kicks-in) and it seems there's a negligible overhead of about 2% in performance when considering total time of loading classes. After that we see that (since this is a single-threaded example) re-use of lock for a class that is already (being) loaded is rare (I assume only explicit requests like Class.forName trigger that event in this example). At the end, almost all locks are eventually released, which frees 3MB+ heap space. Here's a piece of code for obtaining locks (coded as a subclass of ConcurrentHashMap for performance reasons): public Object getOrCreate(K key) { // the most common situation is that the key is new, so optimize fast-path accordingly Object lock = new Object(); LockRef ref = new LockRef<>(key, lock, refQueue); expungeStaleEntries(); for (; ; ) { @SuppressWarnings("unchecked") LockRef oldRef = (LockRef) super.putIfAbsent(key, ref); if (oldRef == null) { if (keepStats) createCount.increment(); return lock; } else { Object oldLock = oldRef.get(); if (oldLock != null) { if (keepStats) returnOldCount.increment(); return oldLock; } else if (super.replace(key, oldRef, ref)) { if (keepStats) replaceCount.increment(); return lock; } } } } private void expungeStaleEntries() { LockRef ref; while ((ref = (LockRef) refQueue.poll()) != null) { super.remove(ref.key, ref); if (keepStats) expungeCount.increment(); } } Do you think this is something worth pursuing further? Regards, Peter On 02/01/2013 05:01 AM, David Holmes wrote: > Hi Peter, > > On 31/01/2013 11:07 PM, Peter Levart wrote: >> Hi David, >> >> Could the parallel classloading be at least space optimized somehow in >> the JDK8 timeframe if there was a solution ready? > > If there is something that does not impact any of the existing > specified semantics regarding the classloader lock object then it may > be possible to work it into an 8 update if not 8 itself. But all the > suggestions I've seen for reducing the memory usage also alter the > semantics in someway. > > However, a key part of the concurrent classloader proposal was that it > didn't change the behaviour of any existing classloaders outside the > core JDK. Anything that changes existing behaviour has a much higher > compatibility bar to get over. > > David > ----- From chris.hegarty at oracle.com Mon Feb 4 09:48:57 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 04 Feb 2013 09:48:57 +0000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <510BD3E6.1090103@oracle.com> References: <510BD3E6.1090103@oracle.com> Message-ID: <510F8409.6080202@oracle.com> There has been some discussion on this with David, but no other takers. Fredrik, am I right that you added the support for parallel clone/update? I believe the changes I have are correct, but maybe you had other ideas about how to solve this issue? -Chris. On 01/02/2013 14:40, Chris Hegarty wrote: > [ to build-dev and core-libs-dev, expect reviewer from either, but will > integrate through jdk8/tl ] > > This issue is mainly of interest to Oracle engineers, but it effects the > public hgforest script. > > When hgforest.sh is run with an addition argument to specify a closed > server, there is a problem/race between the creation of the directories > to hold nested repositories and the clone itself. These directories need > to be created before the clone command is executed, otherwise it will > fail, as below. > > The trivial fix is to back off these nested repos until their containing > directory exists. > > Webrev: > http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ > > sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log > # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed > jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed > hotspot/test/closed deploy install sponsors pubs > > Waiting 5 secs before spawning next background command. > Waiting 5 secs before spawning next background command. > Waiting 5 secs before spawning next background command. > jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u > /java/devtools/sparc/mercurial/latest/bin/hg clone > http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed > jdk/src/closed: abort: No such file or directory: jdk/src/closed > jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u > /java/devtools/sparc/mercurial/latest/bin/hg clone > http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed > jdk/make/closed: abort: No such file or directory: jdk/make/closed > Waiting 5 secs before spawning next background command. > .... > > > -Chris. From Alan.Bateman at oracle.com Mon Feb 4 09:51:28 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 04 Feb 2013 09:51:28 +0000 Subject: geteuid(2) in java? In-Reply-To: <510F576D.6060805@oracle.com> References: <510F576D.6060805@oracle.com> Message-ID: <510F84A0.1000903@oracle.com> On 04/02/2013 06:38, Weijun Wang wrote: > Need an equivalence of the geteuid() function that returns the > effective user ID of the calling process. There isn't an API for this. -Alan From fredrik.ohrstrom at oracle.com Mon Feb 4 10:04:27 2013 From: fredrik.ohrstrom at oracle.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Mon, 04 Feb 2013 11:04:27 +0100 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <510F8409.6080202@oracle.com> References: <510BD3E6.1090103@oracle.com> <510F8409.6080202@oracle.com> Message-ID: <510F87AB.3070705@oracle.com> 2013-02-04 10:48, Chris Hegarty skrev: > There has been some discussion on this with David, but no other takers. > > Fredrik, am I right that you added the support for parallel > clone/update? I believe the changes I have are correct, but maybe you > had other ideas about how to solve this issue? > > -Chris. I did not add the support for parallel clone/update. It was there already and causing problems. I added the functionality to interrupt the script using ctrl-c, which was impossible before, because of the parallel clone/update code. Your fix looks good and is simple enough. //Fredrik > > On 01/02/2013 14:40, Chris Hegarty wrote: >> [ to build-dev and core-libs-dev, expect reviewer from either, but will >> integrate through jdk8/tl ] >> >> This issue is mainly of interest to Oracle engineers, but it effects the >> public hgforest script. >> >> When hgforest.sh is run with an addition argument to specify a closed >> server, there is a problem/race between the creation of the directories >> to hold nested repositories and the clone itself. These directories need >> to be created before the clone command is executed, otherwise it will >> fail, as below. >> >> The trivial fix is to back off these nested repos until their containing >> directory exists. >> >> Webrev: >> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >> >> sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log >> # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed >> jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed >> hotspot/test/closed deploy install sponsors pubs >> >> Waiting 5 secs before spawning next background command. >> Waiting 5 secs before spawning next background command. >> Waiting 5 secs before spawning next background command. >> jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >> /java/devtools/sparc/mercurial/latest/bin/hg clone >> http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed >> jdk/src/closed: abort: No such file or directory: jdk/src/closed >> jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >> /java/devtools/sparc/mercurial/latest/bin/hg clone >> http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed >> jdk/make/closed: abort: No such file or directory: jdk/make/closed >> Waiting 5 secs before spawning next background command. >> .... >> >> >> -Chris. From chris.hegarty at oracle.com Mon Feb 4 10:23:36 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 04 Feb 2013 10:23:36 +0000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <510F87AB.3070705@oracle.com> References: <510BD3E6.1090103@oracle.com> <510F8409.6080202@oracle.com> <510F87AB.3070705@oracle.com> Message-ID: <510F8C28.9030204@oracle.com> On 04/02/2013 10:04, Fredrik ?hrstr?m wrote: > 2013-02-04 10:48, Chris Hegarty skrev: >> There has been some discussion on this with David, but no other takers. >> >> Fredrik, am I right that you added the support for parallel >> clone/update? I believe the changes I have are correct, but maybe you >> had other ideas about how to solve this issue? >> >> -Chris. > > I did not add the support for parallel clone/update. It was there > already and causing problems. Ah sorry Fredrik, I remember the ctrl-c stuff now. I didn't mean to implicate you, just thought you would be familiar with this area. > I added the functionality to interrupt the script using ctrl-c, which > was impossible before, because > of the parallel clone/update code. > > Your fix looks good and is simple enough. Thanks, -Chris. > > //Fredrik > >> >> On 01/02/2013 14:40, Chris Hegarty wrote: >>> [ to build-dev and core-libs-dev, expect reviewer from either, but will >>> integrate through jdk8/tl ] >>> >>> This issue is mainly of interest to Oracle engineers, but it effects the >>> public hgforest script. >>> >>> When hgforest.sh is run with an addition argument to specify a closed >>> server, there is a problem/race between the creation of the directories >>> to hold nested repositories and the clone itself. These directories need >>> to be created before the clone command is executed, otherwise it will >>> fail, as below. >>> >>> The trivial fix is to back off these nested repos until their containing >>> directory exists. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >>> >>> sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log >>> # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed >>> jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed >>> hotspot/test/closed deploy install sponsors pubs >>> >>> Waiting 5 secs before spawning next background command. >>> Waiting 5 secs before spawning next background command. >>> Waiting 5 secs before spawning next background command. >>> jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed >>> jdk/src/closed: abort: No such file or directory: jdk/src/closed >>> jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed >>> jdk/make/closed: abort: No such file or directory: jdk/make/closed >>> Waiting 5 secs before spawning next background command. >>> .... >>> >>> >>> -Chris. > From yekaterina.kantserova at oracle.com Mon Feb 4 10:33:16 2013 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Mon, 04 Feb 2013 11:33:16 +0100 Subject: RFR (S) 8007142: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <510BDCAA.1080909@oracle.com> References: <510BB12C.2030802@oracle.com> <510BB5CC.6050604@oracle.com> <510BC3E0.6020107@oracle.com> <510BCF1B.3010704@oracle.com> <510BD9EF.1050202@oracle.com> <510BDCAA.1080909@oracle.com> Message-ID: <510F8E6C.2090301@oracle.com> On 02/01/2013 04:18 PM, Alan Bateman wrote: > On 01/02/2013 15:06, Yekaterina Kantserova wrote: >> >> Thanks for explanation! But I'm still confused. >> >> In my use case I need to test /_the tool_/ I'll find with >> JDKToolFinder. It will work if just -jdk will be specified. But if >> -compilejdk happens to be specified the results of my tests will be >> useless. Furthermore, it would be hard to detect. Do you think there >> is a solution that covers all use cases? > I don't think it make sense to specify -compilejdk and not -jdk. Does > that help? > > -Alan No, it was a bad example. Let's take another one: /java -jar jtreg.jar -jdk MONKEY -compilejdk LION test.java/ In this case JDKToolFinder.getJDKTool("jcmd") will return LION/bin/jcmd, but I need to test MONKEY/bin/jcmd. There is an example in ProcessTools.java: ... /** * Create ProcessBuilder using *the java launcher from the jdk to be tested* * and with any platform specific arguments prepended */ public static ProcessBuilder createJavaProcessBuilder(String... command) throws Exception { String javapath = JDKToolFinder.getJDKTool("java"); ArrayList args = new ArrayList<>(); args.add(javapath); Collections.addAll(args, getPlatformSpecificVMArgs()); Collections.addAll(args, command); return new ProcessBuilder(args.toArray(new String[args.size()])); } ... May be we need another solution for testing a JRE? JREToolFinder for example, which can be implemented later? Thanks, Katja From Alan.Bateman at oracle.com Mon Feb 4 10:55:15 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 04 Feb 2013 10:55:15 +0000 Subject: RFR (S) 8007142: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <510F8E6C.2090301@oracle.com> References: <510BB12C.2030802@oracle.com> <510BB5CC.6050604@oracle.com> <510BC3E0.6020107@oracle.com> <510BCF1B.3010704@oracle.com> <510BD9EF.1050202@oracle.com> <510BDCAA.1080909@oracle.com> <510F8E6C.2090301@oracle.com> Message-ID: <510F9393.8080509@oracle.com> On 04/02/2013 10:33, Yekaterina Kantserova wrote: > > No, it was a bad example. Let's take another one: > > /java -jar jtreg.jar -jdk MONKEY -compilejdk LION test.java/ > > In this case JDKToolFinder.getJDKTool("jcmd") will return > LION/bin/jcmd, but I need to test MONKEY/bin/jcmd. The -compilejdk option should only be used when testing a JRE -- ie: no tools in the runtime under test. So this your example shouldn't include the -compilejdk option as it is testing a JDK. -Alan. From yekaterina.kantserova at oracle.com Mon Feb 4 11:03:50 2013 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Mon, 04 Feb 2013 12:03:50 +0100 Subject: RFR (S) 8007142: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <510F9393.8080509@oracle.com> References: <510BB12C.2030802@oracle.com> <510BB5CC.6050604@oracle.com> <510BC3E0.6020107@oracle.com> <510BCF1B.3010704@oracle.com> <510BD9EF.1050202@oracle.com> <510BDCAA.1080909@oracle.com> <510F8E6C.2090301@oracle.com> <510F9393.8080509@oracle.com> Message-ID: <510F9596.8060503@oracle.com> On 02/04/2013 11:55 AM, Alan Bateman wrote: > On 04/02/2013 10:33, Yekaterina Kantserova wrote: >> >> No, it was a bad example. Let's take another one: >> >> /java -jar jtreg.jar -jdk MONKEY -compilejdk LION test.java/ >> >> In this case JDKToolFinder.getJDKTool("jcmd") will return >> LION/bin/jcmd, but I need to test MONKEY/bin/jcmd. > The -compilejdk option should only be used when testing a JRE -- ie: > no tools in the runtime under test. > > So this your example shouldn't include the -compilejdk option as it is > testing a JDK. > > -Alan. But JDKToolFinder.getJDKTool is used even for finding java, e.g. I need to fork a java process - JDKToolFinder.getJDKTool("java") for some JRE tests? // Katja From david.holmes at oracle.com Mon Feb 4 11:11:58 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 04 Feb 2013 21:11:58 +1000 Subject: Parallel ClassLoading space optimizations In-Reply-To: <510F7491.1040505@gmail.com> References: <50BF371A.1060604@oracle.com> <510A38BB.3090103@oracle.com> <510A6C8B.60701@gmail.com> <510B3E17.3050104@oracle.com> <510F7491.1040505@gmail.com> Message-ID: <510F977E.2010407@oracle.com> Hi Peter, On 4/02/2013 6:42 PM, Peter Levart wrote: > Hi David, > > I might have something usable, but I just wanted to verify some things > beforehand. What I investigated was a simple keeping a cache of locks in > a map weekly referenced. In your blog: > > * > https://blogs.oracle.com/dholmes/entry/parallel_classloading_revisited_fully_concurrent > > ...you describe this a a 3rd alternative: > > /3. Reduce the lifetime of lock objects so that entries are removed > from the map when no longer needed (eg remove after loading,*use > weak references* to the lock objects and cleanup the map periodically)./ > > > ...but later you preclude this option: > > /Similarly we might reason that we can remove a mapping (and the > lock object) because the class is already loaded, but this would > again violate the specification because it can be reasoned that the > following assertion should hold true: / > > | > Object lock1 = loader.getClassLoadingLock(name); > loader.loadClass(name); > Object lock2 = loader.getClassLoadingLock(name); > assert lock1 == lock2; > | > > /Without modifying the specification, or at least doing some > creative wordsmithing on it, options 1 and 3 are precluded. / > > > When using WeakReferences to cache lock Objects, the above assertion > would still hold true, wouldn't it? No. The WeakReference can be cleared causing lock2 to be a different object. > I can not think of any reasonable 3rd party ClassLoader code that would > behave differently when having lock objects strongly referenced for the > entire VM lifetime vs. having them temporarily weakly referenced and > eventually recreated if needed. For example, only code that does the > following things can see difference: > > * use .toString or .hashCode on lock object and keep it somewhere > without also keeping the lock object itself to use it later > * wrap a lock object into a WeakReference and observe reference being > cleared or not But that is the point - we don't know what any actual external classloader does with the classloading lock, so we can't just arbitrarily change the existing specification without being very sure about the implications for making that change. Such a change would have to have been proposed well before now so there was time to evaluate the impact. David ----- > Is that a reasonable assumption to continue in this direction? If the > semantics are reasonably OK, then all the solution has to prove is > (space and time) performance, right? > > Here's some preliminary illustration what can be achieved space-wise. > This is a test that attempts to load all the classes from the rt.jar. > The situation we have now (using -Xms256m -Xmx256m and 32bit addresses): > > ...At the beginning of main() > > Total memory: 257294336 bytes > Free memory: 251920320 bytes > Deep size of sun.misc.Launcher$ExtClassLoader at 3d4eac69: 7936 bytes > Deep size of sun.misc.Launcher$AppClassLoader at 55f96302: 30848 bytes > Deep size of both: 38784 bytes (reference) > > ...Attempted to load: 18558 classes in: 1964.55825 ms > > Total memory: 257294336 bytes > Free memory: 227314112 bytes > Deep size of sun.misc.Launcher$ExtClassLoader at 3d4eac69: 1162184 bytes > Deep size of sun.misc.Launcher$AppClassLoader at 55f96302: 2215216 bytes > Deep size of both: 3377400 bytes (difference to reference: 3338616 bytes) > > ...Performing gc() > > ...Loading class: test.TestClassLoader$Last (to trigger expunging) > > Total memory: 260440064 bytes > Free memory: 193163368 bytes > Deep size of sun.misc.Launcher$ExtClassLoader at 3d4eac69: 1162328 bytes > Deep size of sun.misc.Launcher$AppClassLoader at 55f96302: 2215408 bytes > Deep size of both: 3377736 bytes (difference to reference: 3338952 bytes) > > > vs. having lock objects weekly referenced and doing expunging work at > each request for a lock: > > ...At the beginning of main() > > Total memory: 257294336 bytes > Free memory: 251920320 bytes > Deep size of sun.misc.Launcher$ExtClassLoader at 75b84c92: 9584 bytes > Deep size of sun.misc.Launcher$AppClassLoader at 42a57993: 33960 bytes > Deep size of both: 43544 bytes (reference) > Lock stats... > create: 108 > return old: 0 > replace: 0 > expunge: 0 > > ...Attempted to load: 18558 classes in: 2005.14628 ms > > Total memory: 257294336 bytes > Free memory: 187198776 bytes > Deep size of sun.misc.Launcher$ExtClassLoader at 75b84c92: 572768 bytes > Deep size of sun.misc.Launcher$AppClassLoader at 42a57993: 1122976 bytes > Deep size of both: 1695744 bytes (difference to reference: 1652200 bytes) > Lock stats... > create: 37302 > return old: 201 > replace: 0 > expunge: 25893 > > ...Performing gc() > > ...Loading class: test.TestClassLoader$Last (to trigger expunging) > > Total memory: 257294336 bytes > Free memory: 238693336 bytes > Deep size of sun.misc.Launcher$ExtClassLoader at 75b84c92: 78944 bytes > Deep size of sun.misc.Launcher$AppClassLoader at 42a57993: 168512 bytes > Deep size of both: 247456 bytes (difference to reference: 203912 bytes) > Lock stats... > create: 2 > return old: 0 > replace: 0 > expunge: 11517 > > > ... as can be seen from this particular usecase, there's approx. 20% > overhead of storage for locks because of WeakReference indirection (at > the beginning of main() before any expunging kicks-in) and it seems > there's a negligible overhead of about 2% in performance when > considering total time of loading classes. After that we see that (since > this is a single-threaded example) re-use of lock for a class that is > already (being) loaded is rare (I assume only explicit requests like > Class.forName trigger that event in this example). At the end, almost > all locks are eventually released, which frees 3MB+ heap space. > > Here's a piece of code for obtaining locks (coded as a subclass of > ConcurrentHashMap for performance reasons): > > public Object getOrCreate(K key) { > // the most common situation is that the key is new, so > optimize fast-path accordingly > Object lock = new Object(); > LockRef ref = new LockRef<>(key, lock, refQueue); > expungeStaleEntries(); > for (; ; ) { > @SuppressWarnings("unchecked") > LockRef oldRef = (LockRef) super.putIfAbsent(key, ref); > if (oldRef == null) { > if (keepStats) createCount.increment(); > return lock; > } > else { > Object oldLock = oldRef.get(); > if (oldLock != null) { > if (keepStats) returnOldCount.increment(); > return oldLock; > } > else if (super.replace(key, oldRef, ref)) { > if (keepStats) replaceCount.increment(); > return lock; > } > } > } > } > > private void expungeStaleEntries() { > LockRef ref; > while ((ref = (LockRef) refQueue.poll()) != null) { > super.remove(ref.key, ref); > if (keepStats) expungeCount.increment(); > } > } > > > Do you think this is something worth pursuing further? > > > Regards, Peter > > > On 02/01/2013 05:01 AM, David Holmes wrote: >> Hi Peter, >> >> On 31/01/2013 11:07 PM, Peter Levart wrote: >>> Hi David, >>> >>> Could the parallel classloading be at least space optimized somehow in >>> the JDK8 timeframe if there was a solution ready? >> >> If there is something that does not impact any of the existing >> specified semantics regarding the classloader lock object then it may >> be possible to work it into an 8 update if not 8 itself. But all the >> suggestions I've seen for reducing the memory usage also alter the >> semantics in someway. >> >> However, a key part of the concurrent classloader proposal was that it >> didn't change the behaviour of any existing classloaders outside the >> core JDK. Anything that changes existing behaviour has a much higher >> compatibility bar to get over. >> >> David >> ----- > From david.holmes at oracle.com Mon Feb 4 11:50:53 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 04 Feb 2013 21:50:53 +1000 Subject: Parallel ClassLoading space optimizations In-Reply-To: <510F977E.2010407@oracle.com> References: <50BF371A.1060604@oracle.com> <510A38BB.3090103@oracle.com> <510A6C8B.60701@gmail.com> <510B3E17.3050104@oracle.com> <510F7491.1040505@gmail.com> <510F977E.2010407@oracle.com> Message-ID: <510FA09D.2090709@oracle.com> On 4/02/2013 9:11 PM, David Holmes wrote: > On 4/02/2013 6:42 PM, Peter Levart wrote: >> I might have something usable, but I just wanted to verify some things >> beforehand. What I investigated was a simple keeping a cache of locks in >> a map weekly referenced. In your blog: >> >> * >> https://blogs.oracle.com/dholmes/entry/parallel_classloading_revisited_fully_concurrent >> >> >> ...you describe this a a 3rd alternative: >> >> /3. Reduce the lifetime of lock objects so that entries are removed >> from the map when no longer needed (eg remove after loading,*use >> weak references* to the lock objects and cleanup the map periodically)./ >> >> >> ...but later you preclude this option: >> >> /Similarly we might reason that we can remove a mapping (and the >> lock object) because the class is already loaded, but this would >> again violate the specification because it can be reasoned that the >> following assertion should hold true: / >> >> | >> Object lock1 = loader.getClassLoadingLock(name); >> loader.loadClass(name); >> Object lock2 = loader.getClassLoadingLock(name); >> assert lock1 == lock2; >> | >> >> /Without modifying the specification, or at least doing some >> creative wordsmithing on it, options 1 and 3 are precluded. / >> >> >> When using WeakReferences to cache lock Objects, the above assertion >> would still hold true, wouldn't it? > > No. The WeakReference can be cleared causing lock2 to be a different > object. As Peter has pointed out to me this is of course not correct. The only way you can write the assert is to have maintained strong references to the lock objects, hence the WeakReference can not be cleared. I need to re-consider this approach as my previous thoughts on it were flawed. David ----- >> I can not think of any reasonable 3rd party ClassLoader code that would >> behave differently when having lock objects strongly referenced for the >> entire VM lifetime vs. having them temporarily weakly referenced and >> eventually recreated if needed. For example, only code that does the >> following things can see difference: >> >> * use .toString or .hashCode on lock object and keep it somewhere >> without also keeping the lock object itself to use it later >> * wrap a lock object into a WeakReference and observe reference being >> cleared or not > > But that is the point - we don't know what any actual external > classloader does with the classloading lock, so we can't just > arbitrarily change the existing specification without being very sure > about the implications for making that change. > > Such a change would have to have been proposed well before now so there > was time to evaluate the impact. > > David > ----- > >> Is that a reasonable assumption to continue in this direction? If the >> semantics are reasonably OK, then all the solution has to prove is >> (space and time) performance, right? >> >> Here's some preliminary illustration what can be achieved space-wise. >> This is a test that attempts to load all the classes from the rt.jar. >> The situation we have now (using -Xms256m -Xmx256m and 32bit addresses): >> >> ...At the beginning of main() >> >> Total memory: 257294336 bytes >> Free memory: 251920320 bytes >> Deep size of sun.misc.Launcher$ExtClassLoader at 3d4eac69: 7936 bytes >> Deep size of sun.misc.Launcher$AppClassLoader at 55f96302: 30848 bytes >> Deep size of both: 38784 bytes (reference) >> >> ...Attempted to load: 18558 classes in: 1964.55825 ms >> >> Total memory: 257294336 bytes >> Free memory: 227314112 bytes >> Deep size of sun.misc.Launcher$ExtClassLoader at 3d4eac69: 1162184 bytes >> Deep size of sun.misc.Launcher$AppClassLoader at 55f96302: 2215216 bytes >> Deep size of both: 3377400 bytes (difference to reference: 3338616 bytes) >> >> ...Performing gc() >> >> ...Loading class: test.TestClassLoader$Last (to trigger expunging) >> >> Total memory: 260440064 bytes >> Free memory: 193163368 bytes >> Deep size of sun.misc.Launcher$ExtClassLoader at 3d4eac69: 1162328 bytes >> Deep size of sun.misc.Launcher$AppClassLoader at 55f96302: 2215408 bytes >> Deep size of both: 3377736 bytes (difference to reference: 3338952 bytes) >> >> >> vs. having lock objects weekly referenced and doing expunging work at >> each request for a lock: >> >> ...At the beginning of main() >> >> Total memory: 257294336 bytes >> Free memory: 251920320 bytes >> Deep size of sun.misc.Launcher$ExtClassLoader at 75b84c92: 9584 bytes >> Deep size of sun.misc.Launcher$AppClassLoader at 42a57993: 33960 bytes >> Deep size of both: 43544 bytes (reference) >> Lock stats... >> create: 108 >> return old: 0 >> replace: 0 >> expunge: 0 >> >> ...Attempted to load: 18558 classes in: 2005.14628 ms >> >> Total memory: 257294336 bytes >> Free memory: 187198776 bytes >> Deep size of sun.misc.Launcher$ExtClassLoader at 75b84c92: 572768 bytes >> Deep size of sun.misc.Launcher$AppClassLoader at 42a57993: 1122976 bytes >> Deep size of both: 1695744 bytes (difference to reference: 1652200 bytes) >> Lock stats... >> create: 37302 >> return old: 201 >> replace: 0 >> expunge: 25893 >> >> ...Performing gc() >> >> ...Loading class: test.TestClassLoader$Last (to trigger expunging) >> >> Total memory: 257294336 bytes >> Free memory: 238693336 bytes >> Deep size of sun.misc.Launcher$ExtClassLoader at 75b84c92: 78944 bytes >> Deep size of sun.misc.Launcher$AppClassLoader at 42a57993: 168512 bytes >> Deep size of both: 247456 bytes (difference to reference: 203912 bytes) >> Lock stats... >> create: 2 >> return old: 0 >> replace: 0 >> expunge: 11517 >> >> >> ... as can be seen from this particular usecase, there's approx. 20% >> overhead of storage for locks because of WeakReference indirection (at >> the beginning of main() before any expunging kicks-in) and it seems >> there's a negligible overhead of about 2% in performance when >> considering total time of loading classes. After that we see that (since >> this is a single-threaded example) re-use of lock for a class that is >> already (being) loaded is rare (I assume only explicit requests like >> Class.forName trigger that event in this example). At the end, almost >> all locks are eventually released, which frees 3MB+ heap space. >> >> Here's a piece of code for obtaining locks (coded as a subclass of >> ConcurrentHashMap for performance reasons): >> >> public Object getOrCreate(K key) { >> // the most common situation is that the key is new, so >> optimize fast-path accordingly >> Object lock = new Object(); >> LockRef ref = new LockRef<>(key, lock, refQueue); >> expungeStaleEntries(); >> for (; ; ) { >> @SuppressWarnings("unchecked") >> LockRef oldRef = (LockRef) super.putIfAbsent(key, ref); >> if (oldRef == null) { >> if (keepStats) createCount.increment(); >> return lock; >> } >> else { >> Object oldLock = oldRef.get(); >> if (oldLock != null) { >> if (keepStats) returnOldCount.increment(); >> return oldLock; >> } >> else if (super.replace(key, oldRef, ref)) { >> if (keepStats) replaceCount.increment(); >> return lock; >> } >> } >> } >> } >> >> private void expungeStaleEntries() { >> LockRef ref; >> while ((ref = (LockRef) refQueue.poll()) != null) { >> super.remove(ref.key, ref); >> if (keepStats) expungeCount.increment(); >> } >> } >> >> >> Do you think this is something worth pursuing further? >> >> >> Regards, Peter >> >> >> On 02/01/2013 05:01 AM, David Holmes wrote: >>> Hi Peter, >>> >>> On 31/01/2013 11:07 PM, Peter Levart wrote: >>>> Hi David, >>>> >>>> Could the parallel classloading be at least space optimized somehow in >>>> the JDK8 timeframe if there was a solution ready? >>> >>> If there is something that does not impact any of the existing >>> specified semantics regarding the classloader lock object then it may >>> be possible to work it into an 8 update if not 8 itself. But all the >>> suggestions I've seen for reducing the memory usage also alter the >>> semantics in someway. >>> >>> However, a key part of the concurrent classloader proposal was that it >>> didn't change the behaviour of any existing classloaders outside the >>> core JDK. Anything that changes existing behaviour has a much higher >>> compatibility bar to get over. >>> >>> David >>> ----- >> From alexey.utkin at oracle.com Mon Feb 4 12:28:25 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Mon, 04 Feb 2013 16:28:25 +0400 Subject: Request for review: 8007454 Wrong parameters in Win32 native code. In-Reply-To: <50AE2E0A.7020609@oracle.com> References: <50AE2E0A.7020609@oracle.com> Message-ID: <510FA969.303@oracle.com> Hi, Please review the fix. Bug description: http://bugs.sun.com/view_bug.do?bug_id=8007454 https://jbs.oracle.com/bugs/browse/JDK-8007454 The suggested fix: http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8007454/webrev.01/ Summary: Old version of code for the [Java_java_lang_ProcessImpl_create] function could not work right in some cases. The [SetHandleInformation] call worked partially and just because HANDLE_FLAG_INHERIT == TRUE == 1 and FALSE == 0. Regards, -uta From Alan.Bateman at oracle.com Mon Feb 4 13:18:41 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 04 Feb 2013 13:18:41 +0000 Subject: RFR (S) 8007142: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <510F9596.8060503@oracle.com> References: <510BB12C.2030802@oracle.com> <510BB5CC.6050604@oracle.com> <510BC3E0.6020107@oracle.com> <510BCF1B.3010704@oracle.com> <510BD9EF.1050202@oracle.com> <510BDCAA.1080909@oracle.com> <510F8E6C.2090301@oracle.com> <510F9393.8080509@oracle.com> <510F9596.8060503@oracle.com> Message-ID: <510FB531.8040407@oracle.com> On 04/02/2013 11:03, Yekaterina Kantserova wrote: > > But JDKToolFinder.getJDKTool is used even for finding java, e.g. I > need to fork a java process - JDKToolFinder.getJDKTool("java") for > some JRE tests? It might be better to rename JDKToolFinder to something like JdkFinder and have it define getJavaLauncher() and getTool(String tool) methods. If you don't agree then you could at least change ProcessTools.createJavaProcessBuilder so that it looks like "java" in the JDK/JRE under test. -Alan. From Alan.Bateman at oracle.com Mon Feb 4 13:54:09 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 04 Feb 2013 13:54:09 +0000 Subject: RFR : 8006594/8006595 : Define jdk_core test set In-Reply-To: <04B58247-CBCC-4825-8CC8-38236442E24A@oracle.com> References: <216D5987-F917-473E-98EF-C84BAB302C53@oracle.com> <50FFF51B.1030809@oracle.com> <04B58247-CBCC-4825-8CC8-38236442E24A@oracle.com> Message-ID: <510FBD81.4050709@oracle.com> On 02/02/2013 20:40, Mike Duigou wrote: > I have updated both the jdk repo patch: > > 8006594: Add jdk_core target to jdk/test/Makefile > http://cr.openjdk.java.net/~mduigou/JDK-8006594/1/webrev/ > > and the root repo patch: > > 8006595: Use jdk/test/Makefile targets in preference to local definitions > http://cr.openjdk.java.net/~mduigou/JDK-8006595/1/webrev/ > > The primary difference between this version and the previous is the judicious use of "-k" option and silencing of command spew. A top-level make test TEST=jdk_core now succeeds even if sub-tests fail. > > I investigated changing the behaviour which determines the test output location so that all jdk_core output would be in a single directory. I have opted to not change it yet as I can't be certain what depends upon the current behaviour. > > I would like to change one additional aspect--currently the "prep" target forces the output dir to be wiped via a dependency on "clean". I would like to remove this dependency and not wipe the output dir with each run. For RE and JPRT uses they are likely to be running in fresh directories anyway so this change should only impact developers who likely wouldn't want the complete wipe anyway. > > There are some things about the jtreg_tests target which seem very specific to how JPRT uses this makefile. Not all of the behaviours, such as bundling of test output into zip files, make sense for all likely users of this makefile. I will work with Kelly to partition the JPRT functionality and better understand how this Makefile is used by JPRT for future patches. > > Mike If I understand correctly, then the default will now be jdk_core + langtools but no hotspot (just checking that this is what is intended). I agree that having JPRT config in the repo is confusing, especially with the *.test.targets properties that overlap/conflict with the make files. common/makefiles/Main.gmk - it looks like you've added CONCURRENCY=$(JOBS). Is $(JOBS) coming from the --num-cores specified to configure? If so then I think we have to careful because -concurrency means a lot of virtual memory and I'm not convinced that we limit it via -vmoption in jdk/test/Makefile. I could see us wanting to dial this down on 32-bit Windows for example. Also I'm not 100% sure that jdk/test/TEST.ROOT is up to date for the client area -- that's the place where excludeAccess.dirs lists the directories with tests that cannot run concurrently. The webrev has an updated to webrev.ksh, I assume we should ignore that. In jdk/test/Makefile you have silenced the jtreg command but I think that is very useful to have in the log files. Minor nit in jdk/test/Makefile but the jdk_core recipe could be split over multiple lines to avoid the very long line. Otherwise I think this looks okay to me. As I mentioned in the original mail I do think we need to move to the point where the mappings is not in the make files and hopefully a future installation will get us moving in that direction. -Alan From Alan.Bateman at oracle.com Mon Feb 4 14:20:15 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 04 Feb 2013 14:20:15 +0000 Subject: [Base64] Codereview request for 8006315 8006530 AND 8006295 In-Reply-To: <510BF39E.3020302@oracle.com> References: <510B70D7.2040702@oracle.com> <510BF39E.3020302@oracle.com> Message-ID: <510FC39F.8010101@oracle.com> On 01/02/2013 16:55, Xueming Shen wrote: > Hi, > > For 8006295 it appears the more reasonable approach is to continue > throw IOE > but document this behavior clearly at the wrap(is) API. So the change > is joined > with these two. > > 8006295: Base64.Decoder.wrap(java.io.InputStream) returns InputStream > which throws unspecified IOException on attempt to decode invalid > Base64 byte stream > > http://cr.openjdk.java.net/~sherman/8006295_8006315_8006530/webrev/ > > Thanks! > -Sherman In Decoder's javadoc then I would suggest "as if followed by padding characters(s)" rather than "as if there are padding charcacter(s) followed". In wrap's javadoc it currently reads: "If the input byte stream is not in valid Base64 encoding scheme then IOException will be thrown when reading any invalid Base64 byte(s) from the returned input stream." I guess this okay but an alternative would be: "The {@code InputStream} methods that reads from the stream throw {@code IOException} if bytes are read that cannot be decoded". Otherwise this looks okay to me and good to have additional test coverage. -Alan. From Alan.Bateman at oracle.com Mon Feb 4 14:25:17 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 04 Feb 2013 14:25:17 +0000 Subject: Request for review: 8007454 Wrong parameters in Win32 native code. In-Reply-To: <510FA969.303@oracle.com> References: <50AE2E0A.7020609@oracle.com> <510FA969.303@oracle.com> Message-ID: <510FC4CD.2060208@oracle.com> On 04/02/2013 12:28, Alexey Utkin wrote: > Hi, > Please review the fix. > > Bug description: > http://bugs.sun.com/view_bug.do?bug_id=8007454 > https://jbs.oracle.com/bugs/browse/JDK-8007454 > > The suggested fix: > http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8007454/webrev.01/ > > Summary: > Old version of code for the [Java_java_lang_ProcessImpl_create] > function could not work right in some cases. The > [SetHandleInformation] call worked partially and just because > HANDLE_FLAG_INHERIT == TRUE == 1 and FALSE == 0. As the parameter is a DWORD then it shouldn't be using a BOOLEAN so I agree with that. Can you explain why HANDLE_FLAG_PROTECT_FROM_CLOSE is needed? -Alan. From mike.duigou at oracle.com Mon Feb 4 16:02:34 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 4 Feb 2013 08:02:34 -0800 Subject: RFR : 8006594/8006595 : Define jdk_core test set In-Reply-To: <510FBD81.4050709@oracle.com> References: <216D5987-F917-473E-98EF-C84BAB302C53@oracle.com> <50FFF51B.1030809@oracle.com> <04B58247-CBCC-4825-8CC8-38236442E24A@oracle.com> <510FBD81.4050709@oracle.com> Message-ID: <71B03773-1288-40C0-98E5-137EC2B7F509@oracle.com> On Feb 4 2013, at 05:54 , Alan Bateman wrote: > On 02/02/2013 20:40, Mike Duigou wrote: >> I have updated both the jdk repo patch: >> >> 8006594: Add jdk_core target to jdk/test/Makefile >> http://cr.openjdk.java.net/~mduigou/JDK-8006594/1/webrev/ >> >> and the root repo patch: >> >> 8006595: Use jdk/test/Makefile targets in preference to local definitions >> http://cr.openjdk.java.net/~mduigou/JDK-8006595/1/webrev/ >> >> The primary difference between this version and the previous is the judicious use of "-k" option and silencing of command spew. A top-level make test TEST=jdk_core now succeeds even if sub-tests fail. >> >> I investigated changing the behaviour which determines the test output location so that all jdk_core output would be in a single directory. I have opted to not change it yet as I can't be certain what depends upon the current behaviour. >> >> I would like to change one additional aspect--currently the "prep" target forces the output dir to be wiped via a dependency on "clean". I would like to remove this dependency and not wipe the output dir with each run. For RE and JPRT uses they are likely to be running in fresh directories anyway so this change should only impact developers who likely wouldn't want the complete wipe anyway. >> >> There are some things about the jtreg_tests target which seem very specific to how JPRT uses this makefile. Not all of the behaviours, such as bundling of test output into zip files, make sense for all likely users of this makefile. I will work with Kelly to partition the JPRT functionality and better understand how this Makefile is used by JPRT for future patches. >> >> Mike > If I understand correctly, then the default will now be jdk_core + langtools but no hotspot (just checking that this is what is intended). Correct. This is actually unchanged. I am not sure if we should redefine the default to do a broad but shallow smoke test of all repos. I believe this would be the most useful default. The jdk_core set can be expanded/altered if we would like a wider cross section of tests run. > I agree that having JPRT config in the repo is confusing, especially with the *.test.targets properties that overlap/conflict with the make files. For now I don't want to break/change any existing usages. > > common/makefiles/Main.gmk - it looks like you've added CONCURRENCY=$(JOBS). Is $(JOBS) coming from the --num-cores specified to configure? Correct. > If so then I think we have to careful because -concurrency means a lot of virtual memory and I'm not convinced that we limit it via -vmoption in jdk/test/Makefile > I could see us wanting to dial this down on 32-bit Windows for example. We do limit the max size via -Xmx512M which does seem quite small and is generally well balanced with the number of cores. I opened a build/infrastructure issue to have MEMORY_SIZE and perhaps some suggested VM sizes recorded to the spec.gmk I planned to revisit this again once only new build is supported. > Also I'm not 100% sure that jdk/test/TEST.ROOT is up to date for the client area -- that's the place where excludeAccess.dirs lists the directories with tests that cannot run concurrently. The makefile currently segregates tests to use othervm or agentvm by target ie. jdk_beans1 . I haven't checked whether these are synchronized against TEST.ROOT and indeed it would be a shame if these had not been kept in sync. (This is why I added notes about "keep this in sync with ..." in various places) I will check this with Stuart Marks today and plan remediation if necessary. > The webrev has an updated to webrev.ksh, I assume we should ignore that. Correct, spillover from 8004726 patch. (which also needs review. :-) ) > > In jdk/test/Makefile you have silenced the jtreg command but I think that is very useful to have in the log files. It does produce a lot of spew but I will unsilence it. When the old build is retired we can integrate the new build logging control and make this controllable. > Minor nit in jdk/test/Makefile but the jdk_core recipe could be split over multiple lines to avoid the very long line. I will do so. > Otherwise I think this looks okay to me. As I mentioned in the original mail I do think we need to move to the point where the mappings is not in the make files and hopefully a future installation will get us moving in that direction. > > -Alan From chris.hegarty at oracle.com Mon Feb 4 16:05:21 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 04 Feb 2013 16:05:21 +0000 Subject: [Base64] Codereview request for 8006315 8006530 AND 8006295 In-Reply-To: <510FC39F.8010101@oracle.com> References: <510B70D7.2040702@oracle.com> <510BF39E.3020302@oracle.com> <510FC39F.8010101@oracle.com> Message-ID: <510FDC41.9010500@oracle.com> On 04/02/2013 14:20, Alan Bateman wrote: > On 01/02/2013 16:55, Xueming Shen wrote: >> Hi, >> >> For 8006295 it appears the more reasonable approach is to continue >> throw IOE >> but document this behavior clearly at the wrap(is) API. So the change >> is joined >> with these two. >> >> 8006295: Base64.Decoder.wrap(java.io.InputStream) returns InputStream >> which throws unspecified IOException on attempt to decode invalid >> Base64 byte stream >> >> http://cr.openjdk.java.net/~sherman/8006295_8006315_8006530/webrev/ >> >> Thanks! >> -Sherman > In Decoder's javadoc then I would suggest "as if followed by padding > characters(s)" rather than "as if there are padding charcacter(s) > followed". > > In wrap's javadoc it currently reads: > > "If the input byte stream is not in valid Base64 encoding scheme then > IOException will be thrown when reading any invalid Base64 byte(s) from > the returned input stream." > > I guess this okay but an alternative would be: > > "The {@code InputStream} methods that reads from the stream throw {@code > IOException} if bytes are read that cannot be decoded". OR "The {@code read} methods of the returned {@code InputStream} will throw {@code IOException} if it encounters bytes that cannot be decoded". I agree with the approach of specify this behavior in the method description of wrap. -Chris. > > Otherwise this looks okay to me and good to have additional test coverage. > > -Alan. > > > > From Alan.Bateman at oracle.com Mon Feb 4 16:33:01 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 04 Feb 2013 16:33:01 +0000 Subject: RFR : 8006594/8006595 : Define jdk_core test set In-Reply-To: <71B03773-1288-40C0-98E5-137EC2B7F509@oracle.com> References: <216D5987-F917-473E-98EF-C84BAB302C53@oracle.com> <50FFF51B.1030809@oracle.com> <04B58247-CBCC-4825-8CC8-38236442E24A@oracle.com> <510FBD81.4050709@oracle.com> <71B03773-1288-40C0-98E5-137EC2B7F509@oracle.com> Message-ID: <510FE2BD.4080401@oracle.com> On 04/02/2013 16:02, Mike Duigou wrote: > : >> If so then I think we have to careful because -concurrency means a lot of virtual memory and I'm not convinced that we limit it via -vmoption in jdk/test/Makefile >> I could see us wanting to dial this down on 32-bit Windows for example. > We do limit the max size via -Xmx512M which does seem quite small and is generally well balanced with the number of cores. > > I opened a build/infrastructure issue to have MEMORY_SIZE and perhaps some suggested VM sizes recorded to the spec.gmk I planned to revisit this again once only new build is supported. My reading of the make file is that -J-Xmx512m is passed to jtreg and so it's the maximum heap size of the jtreg process, not the agent VMs running tests. If we are turning on concurrency then it will need -vmoption:-Xmx512m too, otherwise you risk each agent reserving 1/4 of physical memory. In addition, limited virtual memory on Windows 32-bit will limit the number of agent VMs that you can run and so $(JOBS) may be too much. You might need to limit it to 2 or 3 on Windows 32-bit. > >> Also I'm not 100% sure that jdk/test/TEST.ROOT is up to date for the client area -- that's the place where excludeAccess.dirs lists the directories with tests that cannot run concurrently. > The makefile currently segregates tests to use othervm or agentvm by target ie. jdk_beans1 . I haven't checked whether these are synchronized against TEST.ROOT and indeed it would be a shame if these had not been kept in sync. (This is why I added notes about "keep this in sync with ..." in various places) I will check this with Stuart Marks today and plan remediation if necessary. I think we should ultimately remove the othervm vs. agentvm selection from the make file. I just checked TEST.ROOT and othervm.dirs is right. The value of exclusiveAccess.dirs looks right too but may be incomplete -- I just don't run the client area tests to know if there are any areas that cannot run concurrently. -Alan. From Ulf.Zibis at CoSoCo.de Mon Feb 4 16:36:48 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Mon, 04 Feb 2013 17:36:48 +0100 Subject: [Base64] Codereview request for 8006315 8006530 AND 8006295 In-Reply-To: <510FDC41.9010500@oracle.com> References: <510B70D7.2040702@oracle.com> <510BF39E.3020302@oracle.com> <510FC39F.8010101@oracle.com> <510FDC41.9010500@oracle.com> Message-ID: <510FE3A0.2070809@CoSoCo.de> Am 04.02.2013 17:05, schrieb Chris Hegarty: > On 04/02/2013 14:20, Alan Bateman wrote: >> On 01/02/2013 16:55, Xueming Shen wrote: >>> Hi, >>> >>> For 8006295 it appears the more reasonable approach is to continue >>> throw IOE >>> but document this behavior clearly at the wrap(is) API. So the change >>> is joined >>> with these two. >>> >>> 8006295: Base64.Decoder.wrap(java.io.InputStream) returns InputStream >>> which throws unspecified IOException on attempt to decode invalid >>> Base64 byte stream >>> >>> http://cr.openjdk.java.net/~sherman/8006295_8006315_8006530/webrev/ >>> >>> Thanks! >>> -Sherman >> In Decoder's javadoc then I would suggest "as if followed by padding >> characters(s)" rather than "as if there are padding charcacter(s) >> followed". >> >> In wrap's javadoc it currently reads: >> >> "If the input byte stream is not in valid Base64 encoding scheme then >> IOException will be thrown when reading any invalid Base64 byte(s) from >> the returned input stream." I most like this, but adding some {@code ...} tags would help, at least for IOE. Maybe one of the terms "Base64" would be enough, like: If the input byte stream is not of valid Base64 encoding scheme then {@code IOException} will be thrown by it's {@code read} methods when encountering any undecodable byte(s) >> >> I guess this okay but an alternative would be: >> >> "The {@code InputStream} methods that reads from the stream throw {@code >> IOException} if bytes are read that cannot be decoded". Better: ... that read ... (no 's', typo ?) Also: ... byte(s) ... > > OR > > "The {@code read} methods of the returned {@code InputStream} will throw {@code IOException} if it > encounters bytes that cannot be decoded". My 2 ct: ... encounters any Base64-invalid byte(s) -Ulf From Ulf.Zibis at CoSoCo.de Mon Feb 4 17:15:52 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Mon, 04 Feb 2013 18:15:52 +0100 Subject: [Base64] Codereview request for 8006315 8006530 AND 8006295 In-Reply-To: <510FE3A0.2070809@CoSoCo.de> References: <510B70D7.2040702@oracle.com> <510BF39E.3020302@oracle.com> <510FC39F.8010101@oracle.com> <510FDC41.9010500@oracle.com> <510FE3A0.2070809@CoSoCo.de> Message-ID: <510FECC8.6080905@CoSoCo.de> Am 04.02.2013 17:36, schrieb Ulf Zibis: >> On 04/02/2013 14:20, Alan Bateman wrote: >>> "If the input byte stream is not in valid Base64 encoding scheme then >>> IOException will be thrown when reading any invalid Base64 byte(s) from >>> the returned input stream." Additionally there is a comma missing after "scheme", as same on my suggestion below ... > > I most like this, but adding some {@code ...} tags would help, at least for IOE. Maybe one of the > terms "Base64" would be enough, like: > If the input byte stream is not of valid Base64 encoding scheme then {@code IOException} will be > thrown by it's {@code read} methods when encountering any undecodable byte(s) -Ulf From vincent.x.ryan at oracle.com Mon Feb 4 17:21:27 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Mon, 04 Feb 2013 17:21:27 +0000 Subject: hg: jdk8/tl/jdk: 8006994: Cleanup PKCS12 tests to ensure streams get closed Message-ID: <20130204172205.4E993477EF@hg.openjdk.java.net> Changeset: 5bf1c9e6be60 Author: vinnie Date: 2013-02-04 17:20 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5bf1c9e6be60 8006994: Cleanup PKCS12 tests to ensure streams get closed Reviewed-by: mullan ! test/java/security/KeyStore/PBETest.java ! test/sun/security/pkcs12/StorePasswordTest.java ! test/sun/security/pkcs12/StoreSecretKeyTest.java ! test/sun/security/pkcs12/StoreTrustedCertTest.java From brian.burkhalter at oracle.com Mon Feb 4 18:04:56 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 4 Feb 2013 10:04:56 -0800 Subject: Math.round(...) and bug 6430675 In-Reply-To: <1359798058.38334.YahooMailNeo@web132106.mail.ird.yahoo.com> References: <1359667580.92728.YahooMailNeo@web132106.mail.ird.yahoo.com> <97FBDF44-F141-4158-B16F-0C4BFA9330EF@oracle.com> <1359798058.38334.YahooMailNeo@web132106.mail.ird.yahoo.com> Message-ID: <2D06F838-AF51-465D-B2E1-4EE67C127479@oracle.com> Thank you! Brian On Feb 2, 2013, at 1:40 AM, Jeff Hain wrote: > >Would you mind filing an issue so that this may be tracked? > > Done: "Math.round has surprising behavior for odd values of ulp 1" From brian.burkhalter at oracle.com Mon Feb 4 18:09:39 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 4 Feb 2013 10:09:39 -0800 Subject: RFR - 6480539: BigDecimal.stripTrailingZeros() should specify no-op on zero BigDecimals Message-ID: Hi, While stripTrailingZeros() should perhaps for purity of specification always return BigDecimal.ZERO for anything which is numerically equal to zero, the present behavior of this method has been extant for some years, so following the prevailing convention it would be preferable to modify the specification to match the behavior. Proposed change: diff -r 20eeb727d171 -r 8789e8736763 src/share/classes/java/math/BigDecimal.java --- a/src/share/classes/java/math/BigDecimal.java Fri Feb 01 16:32:53 2013 -0800 +++ b/src/share/classes/java/math/BigDecimal.java Fri Feb 01 16:32:53 2013 -0800 @@ -2589,7 +2589,9 @@ * the {@code BigDecimal} value {@code 600.0}, which has * [{@code BigInteger}, {@code scale}] components equals to * [6000, 1], yields {@code 6E2} with [{@code BigInteger}, - * {@code scale}] components equals to [6, -2] + * {@code scale}] components equals to [6, -2]. This method has no + * effect on a {@code BigDecimal} x which is numerically + * equal to zero, i.e., {@code x.compareTo(BigDecimal.ZERO) == 0}. * * @return a numerically equal {@code BigDecimal} with any * trailing zeros removed. Thanks, Brian From scolebourne at joda.org Mon Feb 4 18:13:49 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 4 Feb 2013 18:13:49 +0000 Subject: RFR - 6480539: BigDecimal.stripTrailingZeros() should specify no-op on zero BigDecimals In-Reply-To: References: Message-ID: On 4 February 2013 18:09, Brian Burkhalter wrote: > While stripTrailingZeros() should perhaps for purity of specification always return BigDecimal.ZERO for anything which is numerically equal to zero, the present behavior of this method has been extant for some years, so following the prevailing convention it would be preferable to modify the specification to match the behavior. > > Proposed change: > > diff -r 20eeb727d171 -r 8789e8736763 src/share/classes/java/math/BigDecimal.java > --- a/src/share/classes/java/math/BigDecimal.java Fri Feb 01 16:32:53 2013 -0800 > +++ b/src/share/classes/java/math/BigDecimal.java Fri Feb 01 16:32:53 2013 -0800 > @@ -2589,7 +2589,9 @@ > * the {@code BigDecimal} value {@code 600.0}, which has > * [{@code BigInteger}, {@code scale}] components equals to > * [6000, 1], yields {@code 6E2} with [{@code BigInteger}, > - * {@code scale}] components equals to [6, -2] > + * {@code scale}] components equals to [6, -2]. This method has no > + * effect on a {@code BigDecimal} x which is numerically > + * equal to zero, i.e., {@code x.compareTo(BigDecimal.ZERO) == 0}. > * > * @return a numerically equal {@code BigDecimal} with any > * trailing zeros removed. This is a bug that has bitten me on more than one occasion. Changing the spec is not the solution here. Fixing the bug is. Stephen From kelly.ohair at oracle.com Mon Feb 4 18:15:51 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 4 Feb 2013 10:15:51 -0800 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <510BD3E6.1090103@oracle.com> References: <510BD3E6.1090103@oracle.com> Message-ID: Looks fine to me. -kto On Feb 1, 2013, at 6:40 AM, Chris Hegarty wrote: > [ to build-dev and core-libs-dev, expect reviewer from either, but will integrate through jdk8/tl ] > > This issue is mainly of interest to Oracle engineers, but it effects the public hgforest script. > > When hgforest.sh is run with an addition argument to specify a closed server, there is a problem/race between the creation of the directories to hold nested repositories and the clone itself. These directories need to be created before the clone command is executed, otherwise it will fail, as below. > > The trivial fix is to back off these nested repos until their containing directory exists. > > Webrev: > http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ > > sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log > # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed hotspot/test/closed deploy install sponsors pubs > > Waiting 5 secs before spawning next background command. > Waiting 5 secs before spawning next background command. > Waiting 5 secs before spawning next background command. > jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u /java/devtools/sparc/mercurial/latest/bin/hg clone http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed > jdk/src/closed: abort: No such file or directory: jdk/src/closed > jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u /java/devtools/sparc/mercurial/latest/bin/hg clone http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed > jdk/make/closed: abort: No such file or directory: jdk/make/closed > Waiting 5 secs before spawning next background command. > .... > > > -Chris. From huizhe.wang at oracle.com Mon Feb 4 19:02:30 2013 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 04 Feb 2013 11:02:30 -0800 Subject: Review Request for JDK-8007389: Remove uses of _ as identifier in jaxp In-Reply-To: <510C4D7D.8010205@oracle.com> References: <510BF121.30105@oracle.com> <654238BD-516E-4AFD-8C01-C64AAC2ADF50@oracle.com> <510C4D7D.8010205@oracle.com> Message-ID: <511005C6.2060808@oracle.com> Hi Eric, The change is fine. Thanks for taking on fixing this! Joe On 2/1/2013 3:19 PM, Eric McCorkle wrote: > Thanks. Do I have a second? > > On 02/01/13 12:04, Lance Andersen - Oracle wrote: >> Its OK. >> >> Not sure I would have replaced it with 'unused' but not a big deal as it is just a personal preference. >> >> >> On Feb 1, 2013, at 11:45 AM, Eric McCorkle wrote: >> >>> Hello, >>> >>> Please review this trivial patch which removes uses of _ as an >>> identifier in the jaxp API. >>> >>> The webrev is here: >>> http://cr.openjdk.java.net/~emc/8007389/ >>> >>> The bug should be here, but does not seem to be showing up yet: >>> http://bugs.sun.com/view_bug.do?bug_id=8007389 >> >> >> >> 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 joe.darcy at oracle.com Mon Feb 4 19:31:35 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 04 Feb 2013 11:31:35 -0800 Subject: RFR - 6480539: BigDecimal.stripTrailingZeros() should specify no-op on zero BigDecimals In-Reply-To: References: Message-ID: <51100C97.4040504@oracle.com> On 2/4/2013 10:13 AM, Stephen Colebourne wrote: > On 4 February 2013 18:09, Brian Burkhalter wrote: >> While stripTrailingZeros() should perhaps for purity of specification always return BigDecimal.ZERO for anything which is numerically equal to zero, the present behavior of this method has been extant for some years, so following the prevailing convention it would be preferable to modify the specification to match the behavior. >> >> Proposed change: >> >> diff -r 20eeb727d171 -r 8789e8736763 src/share/classes/java/math/BigDecimal.java >> --- a/src/share/classes/java/math/BigDecimal.java Fri Feb 01 16:32:53 2013 -0800 >> +++ b/src/share/classes/java/math/BigDecimal.java Fri Feb 01 16:32:53 2013 -0800 >> @@ -2589,7 +2589,9 @@ >> * the {@code BigDecimal} value {@code 600.0}, which has >> * [{@code BigInteger}, {@code scale}] components equals to >> * [6000, 1], yields {@code 6E2} with [{@code BigInteger}, >> - * {@code scale}] components equals to [6, -2] >> + * {@code scale}] components equals to [6, -2]. This method has no >> + * effect on a {@code BigDecimal} x which is numerically >> + * equal to zero, i.e., {@code x.compareTo(BigDecimal.ZERO) == 0}. >> * >> * @return a numerically equal {@code BigDecimal} with any >> * trailing zeros removed. > This is a bug that has bitten me on more than one occasion. Changing > the spec is not the solution here. Fixing the bug is. > Stephen The stripTrailingZeros method has acted in this surprising way since the IBM-led JSR 13 was integrated into the platform back in JDK 5, which shipped in 2004. This situation is analogous to when the specification and behavior disagree. Our general policy to resolve such cases when evolving the JDK is: "..., there are times in evolving the JDK when differences are found between the specified behavior and the actual behavior (for example 4707389, 6365176). The two basic approaches to fixing these bugs are to change the implementation to match the specified behavior or to change the specification (in a platform release) to match the implementation's (perhaps long-standing) behavior; often the latter option is chosen since it has a lower de facto impact on behavioral compatibility." http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html If this issue were being addressed before JDK 5 shipped or even during JDK 6, I would support changing the behavior of stripTrailingZeros. However, for addressing this in JDK 8, I think it is more appropriate to keep the behavior as-is and document this special case. -Joe From ioi.lam at oracle.com Mon Feb 4 19:36:35 2013 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 04 Feb 2013 11:36:35 -0800 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <510C43A8.7040805@oracle.com> References: <510BD3E6.1090103@oracle.com> <510C43A8.7040805@oracle.com> Message-ID: <51100DC3.4090007@oracle.com> How about adding a message to indicate the sleep, just in case the directory is never created for whatever reason. If you don't like too many such messages, you can print the message after the initial wait. 177 while [ ! -d "$path" ] ## nested repo, ensure containing dir exists 178 do 179 sleep 5 if[ ! -d "$path" ] ; then echo "Sleeping to wait for '$path' to be created"; fi 180 done 181 fi - Ioi On 02/01/2013 02:37 PM, David Holmes wrote: > Hi Chris, > > On 2/02/2013 12:40 AM, Chris Hegarty wrote: >> [ to build-dev and core-libs-dev, expect reviewer from either, but will >> integrate through jdk8/tl ] >> >> This issue is mainly of interest to Oracle engineers, but it effects the >> public hgforest script. >> >> When hgforest.sh is run with an addition argument to specify a closed >> server, there is a problem/race between the creation of the directories >> to hold nested repositories and the clone itself. These directories need >> to be created before the clone command is executed, otherwise it will >> fail, as below. > > I think I reported this myself just last week - probably internally to > build or build-infra. > > The weird thing is that based on the list of repos it shouldn't be > grabbing the closed one yet. > >> The trivial fix is to back off these nested repos until their containing >> directory exists. > > That seems to assume/require that the nested repo will always be later > in the list. They happen to be but .... > > Workaround is to run get_source.sh twice first without the "extra > base" then with it. > > David > ----- > >> >> Webrev: >> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >> >> sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log >> # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed >> jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed >> hotspot/test/closed deploy install sponsors pubs >> >> Waiting 5 secs before spawning next background command. >> Waiting 5 secs before spawning next background command. >> Waiting 5 secs before spawning next background command. >> jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >> /java/devtools/sparc/mercurial/latest/bin/hg clone >> http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed >> jdk/src/closed: abort: No such file or directory: jdk/src/closed >> jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >> /java/devtools/sparc/mercurial/latest/bin/hg clone >> http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed >> jdk/make/closed: abort: No such file or directory: jdk/make/closed >> Waiting 5 secs before spawning next background command. >> .... >> >> >> -Chris. From xueming.shen at oracle.com Mon Feb 4 19:41:08 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 04 Feb 2013 11:41:08 -0800 Subject: [Base64] Codereview request for 8006315 8006530 AND 8006295 In-Reply-To: <510FE3A0.2070809@CoSoCo.de> References: <510B70D7.2040702@oracle.com> <510BF39E.3020302@oracle.com> <510FC39F.8010101@oracle.com> <510FDC41.9010500@oracle.com> <510FE3A0.2070809@CoSoCo.de> Message-ID: <51100ED4.3010107@oracle.com> Thanks Alan, Chris and Ulf for the review and comments. The wording has been updated accordingly. Hope it is clear enough for push. http://cr.openjdk.java.net/~sherman/8006295_8006315_8006530/webrev/ -Sherman On 02/04/2013 08:36 AM, Ulf Zibis wrote: > > Am 04.02.2013 17:05, schrieb Chris Hegarty: >> On 04/02/2013 14:20, Alan Bateman wrote: >>> On 01/02/2013 16:55, Xueming Shen wrote: >>>> Hi, >>>> >>>> For 8006295 it appears the more reasonable approach is to continue >>>> throw IOE >>>> but document this behavior clearly at the wrap(is) API. So the change >>>> is joined >>>> with these two. >>>> >>>> 8006295: Base64.Decoder.wrap(java.io.InputStream) returns InputStream >>>> which throws unspecified IOException on attempt to decode invalid >>>> Base64 byte stream >>>> >>>> http://cr.openjdk.java.net/~sherman/8006295_8006315_8006530/webrev/ >>>> >>>> Thanks! >>>> -Sherman >>> In Decoder's javadoc then I would suggest "as if followed by padding >>> characters(s)" rather than "as if there are padding charcacter(s) >>> followed". >>> >>> In wrap's javadoc it currently reads: >>> >>> "If the input byte stream is not in valid Base64 encoding scheme then >>> IOException will be thrown when reading any invalid Base64 byte(s) from >>> the returned input stream." > > I most like this, but adding some {@code ...} tags would help, at least for IOE. Maybe one of the terms "Base64" would be enough, like: > If the input byte stream is not of valid Base64 encoding scheme then {@code IOException} will be thrown by it's {@code read} methods when encountering any undecodable byte(s) > >>> >>> I guess this okay but an alternative would be: >>> >>> "The {@code InputStream} methods that reads from the stream throw {@code >>> IOException} if bytes are read that cannot be decoded". > > Better: ... that read ... (no 's', typo ?) > Also: ... byte(s) ... > >> >> OR >> >> "The {@code read} methods of the returned {@code InputStream} will throw {@code IOException} if it encounters bytes that cannot be decoded". > > My 2 ct: > ... encounters any Base64-invalid byte(s) > > -Ulf > > > From eric.mccorkle at oracle.com Mon Feb 4 19:43:11 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Mon, 04 Feb 2013 14:43:11 -0500 Subject: Review Request for JDK-8007389: Remove uses of _ as identifier in jaxp In-Reply-To: <511005C6.2060808@oracle.com> References: <510BF121.30105@oracle.com> <654238BD-516E-4AFD-8C01-C64AAC2ADF50@oracle.com> <510C4D7D.8010205@oracle.com> <511005C6.2060808@oracle.com> Message-ID: <51100F4F.6030004@oracle.com> Thanks for the reviews everybody! On 02/04/13 14:02, Joe Wang wrote: > Hi Eric, > > The change is fine. Thanks for taking on fixing this! > > Joe > > On 2/1/2013 3:19 PM, Eric McCorkle wrote: >> Thanks. Do I have a second? >> >> On 02/01/13 12:04, Lance Andersen - Oracle wrote: >>> Its OK. >>> >>> Not sure I would have replaced it with 'unused' but not a big deal as >>> it is just a personal preference. >>> >>> >>> On Feb 1, 2013, at 11:45 AM, Eric McCorkle wrote: >>> >>>> Hello, >>>> >>>> Please review this trivial patch which removes uses of _ as an >>>> identifier in the jaxp API. >>>> >>>> The webrev is here: >>>> http://cr.openjdk.java.net/~emc/8007389/ >>>> >>>> The bug should be here, but does not seem to be showing up yet: >>>> http://bugs.sun.com/view_bug.do?bug_id=8007389 >>> >>> >>> >>> 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 xueming.shen at oracle.com Mon Feb 4 20:00:02 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Mon, 04 Feb 2013 20:00:02 +0000 Subject: hg: jdk8/tl/jdk: 8006295: Base64.Decoder.wrap(java.io.InputStream) returns InputStream which throws unspecified IOException on attempt to decode invalid Base64 byte stream; ... Message-ID: <20130204200026.8C3DD477F8@hg.openjdk.java.net> Changeset: e202f43a8b8a Author: sherman Date: 2013-02-04 11:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e202f43a8b8a 8006295: Base64.Decoder.wrap(java.io.InputStream) returns InputStream which throws unspecified IOException on attempt to decode invalid Base64 byte stream 8006315: Base64.Decoder decoding methods are not consistent in treating non-padded data 8006530: Base64.getMimeDecoder().decode() throws exception for non-base64 character after adding = Summary: updated the spec to describe the expected behave explicitly and the implementation to follow Reviewed-by: alanb, chegar, lancea ! src/share/classes/java/util/Base64.java ! test/java/util/Base64/TestBase64.java From chris.hegarty at oracle.com Mon Feb 4 20:01:28 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 4 Feb 2013 20:01:28 +0000 Subject: [Base64] Codereview request for 8006315 8006530 AND 8006295 In-Reply-To: <51100ED4.3010107@oracle.com> References: <510B70D7.2040702@oracle.com> <510BF39E.3020302@oracle.com> <510FC39F.8010101@oracle.com> <510FDC41.9010500@oracle.com> <510FE3A0.2070809@CoSoCo.de> <51100ED4.3010107@oracle.com> Message-ID: Looks ok to me. -Chris On 4 Feb 2013, at 19:41, Xueming Shen wrote: > Thanks Alan, Chris and Ulf for the review and comments. The wording > has been updated accordingly. Hope it is clear enough for push. > > http://cr.openjdk.java.net/~sherman/8006295_8006315_8006530/webrev/ > > -Sherman > > On 02/04/2013 08:36 AM, Ulf Zibis wrote: >> >> Am 04.02.2013 17:05, schrieb Chris Hegarty: >>> On 04/02/2013 14:20, Alan Bateman wrote: >>>> On 01/02/2013 16:55, Xueming Shen wrote: >>>>> Hi, >>>>> >>>>> For 8006295 it appears the more reasonable approach is to continue >>>>> throw IOE >>>>> but document this behavior clearly at the wrap(is) API. So the change >>>>> is joined >>>>> with these two. >>>>> >>>>> 8006295: Base64.Decoder.wrap(java.io.InputStream) returns InputStream >>>>> which throws unspecified IOException on attempt to decode invalid >>>>> Base64 byte stream >>>>> >>>>> http://cr.openjdk.java.net/~sherman/8006295_8006315_8006530/webrev/ >>>>> >>>>> Thanks! >>>>> -Sherman >>>> In Decoder's javadoc then I would suggest "as if followed by padding >>>> characters(s)" rather than "as if there are padding charcacter(s) >>>> followed". >>>> >>>> In wrap's javadoc it currently reads: >>>> >>>> "If the input byte stream is not in valid Base64 encoding scheme then >>>> IOException will be thrown when reading any invalid Base64 byte(s) from >>>> the returned input stream." >> >> I most like this, but adding some {@code ...} tags would help, at least for IOE. Maybe one of the terms "Base64" would be enough, like: >> If the input byte stream is not of valid Base64 encoding scheme then {@code IOException} will be thrown by it's {@code read} methods when encountering any undecodable byte(s) >> >>>> >>>> I guess this okay but an alternative would be: >>>> >>>> "The {@code InputStream} methods that reads from the stream throw {@code >>>> IOException} if bytes are read that cannot be decoded". >> >> Better: ... that read ... (no 's', typo ?) >> Also: ... byte(s) ... >> >>> >>> OR >>> >>> "The {@code read} methods of the returned {@code InputStream} will throw {@code IOException} if it encounters bytes that cannot be decoded". >> >> My 2 ct: >> ... encounters any Base64-invalid byte(s) >> >> -Ulf > From Ulf.Zibis at CoSoCo.de Mon Feb 4 20:20:31 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Mon, 04 Feb 2013 21:20:31 +0100 Subject: [Base64] Codereview request for 8006315 8006530 AND 8006295 In-Reply-To: <51100ED4.3010107@oracle.com> References: <510B70D7.2040702@oracle.com> <510BF39E.3020302@oracle.com> <510FC39F.8010101@oracle.com> <510FDC41.9010500@oracle.com> <510FE3A0.2070809@CoSoCo.de> <51100ED4.3010107@oracle.com> Message-ID: <5110180F.5010602@CoSoCo.de> Am 04.02.2013 20:41, schrieb Xueming Shen: > Thanks Alan, Chris and Ulf for the review and comments. The wording > has been updated accordingly. Hope it is clear enough for push. > > http://cr.openjdk.java.net/~sherman/8006295_8006315_8006530/webrev/ The wording now looks perfect to me! A similar problem, an obviously bad matching exception type, was seen here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6792535 -Ulf From chris.hegarty at oracle.com Mon Feb 4 20:32:44 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 4 Feb 2013 20:32:44 +0000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <51100DC3.4090007@oracle.com> References: <510BD3E6.1090103@oracle.com> <510C43A8.7040805@oracle.com> <51100DC3.4090007@oracle.com> Message-ID: <4BDAEAC3-6B3C-471E-8BBA-3B6794C0B7A6@oracle.com> On 4 Feb 2013, at 19:36, Ioi Lam wrote: > How about adding a message to indicate the sleep, just in case the directory is never created for whatever reason. If you don't like too many such messages, you can print the message after the initial wait. I understand the reason for your suggestion, but in my environment it can take more than a minute before these directories are created, which will be very noisy with six of these nested repos. If these repos are never created then you have bigger problems, disk space, I/O, etc, which such be indicated by the process that encounters the problem. -Chris. > > 177 while [ ! -d "$path" ] ## nested repo, ensure containing dir exists > 178 do > 179 sleep 5 > if[ ! -d "$path" ] ; then > echo "Sleeping to wait for '$path' to be created"; > fi > 180 done > 181 fi > > - Ioi > > On 02/01/2013 02:37 PM, David Holmes wrote: >> Hi Chris, >> >> On 2/02/2013 12:40 AM, Chris Hegarty wrote: >>> [ to build-dev and core-libs-dev, expect reviewer from either, but will >>> integrate through jdk8/tl ] >>> >>> This issue is mainly of interest to Oracle engineers, but it effects the >>> public hgforest script. >>> >>> When hgforest.sh is run with an addition argument to specify a closed >>> server, there is a problem/race between the creation of the directories >>> to hold nested repositories and the clone itself. These directories need >>> to be created before the clone command is executed, otherwise it will >>> fail, as below. >> >> I think I reported this myself just last week - probably internally to build or build-infra. >> >> The weird thing is that based on the list of repos it shouldn't be grabbing the closed one yet. >> >>> The trivial fix is to back off these nested repos until their containing >>> directory exists. >> >> That seems to assume/require that the nested repo will always be later in the list. They happen to be but .... >> >> Workaround is to run get_source.sh twice first without the "extra base" then with it. >> >> David >> ----- >> >>> >>> Webrev: >>> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >>> >>> sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log >>> # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed >>> jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed >>> hotspot/test/closed deploy install sponsors pubs >>> >>> Waiting 5 secs before spawning next background command. >>> Waiting 5 secs before spawning next background command. >>> Waiting 5 secs before spawning next background command. >>> jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed >>> jdk/src/closed: abort: No such file or directory: jdk/src/closed >>> jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed >>> jdk/make/closed: abort: No such file or directory: jdk/make/closed >>> Waiting 5 secs before spawning next background command. >>> .... >>> >>> >>> -Chris. > From scolebourne at joda.org Mon Feb 4 21:36:30 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 4 Feb 2013 21:36:30 +0000 Subject: RFR - 6480539: BigDecimal.stripTrailingZeros() should specify no-op on zero BigDecimals In-Reply-To: <51100C97.4040504@oracle.com> References: <51100C97.4040504@oracle.com> Message-ID: On 4 February 2013 19:31, Joe Darcy wrote: > The stripTrailingZeros method has acted in this surprising way since the > IBM-led JSR 13 was integrated into the platform back in JDK 5, which shipped > in 2004. > > This situation is analogous to when the specification and behavior disagree. > Our general policy to resolve such cases when evolving the JDK is: > > "..., there are times in evolving the JDK when differences are found between > the specified behavior and the actual behavior (for example 4707389, > 6365176). The two basic approaches to fixing these bugs are to change the > implementation to match the specified behavior or to change the > specification (in a platform release) to match the implementation's (perhaps > long-standing) behavior; often the latter option is chosen since it has a > lower de facto impact on behavioral compatibility." > http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html > > If this issue were being addressed before JDK 5 shipped or even during JDK > 6, I would support changing the behavior of stripTrailingZeros. However, > for addressing this in JDK 8, I think it is more appropriate to keep the > behavior as-is and document this special case. I don't see what JDK 5 vs 6 vs 8 really has to do with it. Sun/Oracle has a large bug backlog, and this is just one of them. Fixing it is not that hard, and I can't see how fixing it would be risky to the world's applications. Without this, people like us (OpenGamma) have to have work-arounds: https://github.com/OpenGamma/OG-Platform/blob/master/projects/OG-Util/src/main/java/com/opengamma/util/JdkUtils.java#L26 Stephen From jonathan.gibbons at oracle.com Mon Feb 4 23:32:12 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 04 Feb 2013 23:32:12 +0000 Subject: hg: jdk8/tl/langtools: 8007490: NPE from DocumentationTool.run Message-ID: <20130204233217.0C59F47808@hg.openjdk.java.net> Changeset: 1690928dc560 Author: jjg Date: 2013-02-04 15:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1690928dc560 8007490: NPE from DocumentationTool.run Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/api/JavadocTool.java ! test/tools/javadoc/api/basic/RunTest.java From joe.darcy at oracle.com Tue Feb 5 00:05:56 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Mon, 04 Feb 2013 16:05:56 -0800 Subject: RFR - 6480539: BigDecimal.stripTrailingZeros() should specify no-op on zero BigDecimals In-Reply-To: References: <51100C97.4040504@oracle.com> Message-ID: <51104CE4.10506@oracle.com> On 2/4/2013 1:36 PM, Stephen Colebourne wrote: > On 4 February 2013 19:31, Joe Darcy wrote: >> The stripTrailingZeros method has acted in this surprising way since the >> IBM-led JSR 13 was integrated into the platform back in JDK 5, which shipped >> in 2004. >> >> This situation is analogous to when the specification and behavior disagree. >> Our general policy to resolve such cases when evolving the JDK is: >> >> "..., there are times in evolving the JDK when differences are found between >> the specified behavior and the actual behavior (for example 4707389, >> 6365176). The two basic approaches to fixing these bugs are to change the >> implementation to match the specified behavior or to change the >> specification (in a platform release) to match the implementation's (perhaps >> long-standing) behavior; often the latter option is chosen since it has a >> lower de facto impact on behavioral compatibility." >> http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html >> >> If this issue were being addressed before JDK 5 shipped or even during JDK >> 6, I would support changing the behavior of stripTrailingZeros. However, >> for addressing this in JDK 8, I think it is more appropriate to keep the >> behavior as-is and document this special case. > I don't see what JDK 5 vs 6 vs 8 really has to do with it. The longer a particular behavior has been in a shipped JDK release, the more likely it is various people have built code that depend on that behavior. -Joe From joe.darcy at oracle.com Tue Feb 5 01:56:46 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 05 Feb 2013 01:56:46 +0000 Subject: hg: jdk8/tl/jdk: 8007113: Upgrade AnnotatedElement.isAnnotionPresent to be a default method Message-ID: <20130205015708.AEDEE4780B@hg.openjdk.java.net> Changeset: e04467fa13af Author: darcy Date: 2013-02-04 17:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e04467fa13af 8007113: Upgrade AnnotatedElement.isAnnotionPresent to be a default method Reviewed-by: chegar, jfranck ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/reflect/AccessibleObject.java ! src/share/classes/java/lang/reflect/AnnotatedElement.java ! src/share/classes/java/lang/reflect/Parameter.java ! src/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java From jonathan.gibbons at oracle.com Tue Feb 5 02:14:29 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 05 Feb 2013 02:14:29 +0000 Subject: hg: jdk8/tl/langtools: 8007492: DocumentationTool cannot locate standard doclet when invoked from JRE Message-ID: <20130205021433.E758A4780E@hg.openjdk.java.net> Changeset: 62d91c13dce2 Author: jjg Date: 2013-02-04 18:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/62d91c13dce2 8007492: DocumentationTool cannot locate standard doclet when invoked from JRE Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/api/JavadocTool.java From david.holmes at oracle.com Tue Feb 5 06:21:32 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 05 Feb 2013 16:21:32 +1000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <510BD3E6.1090103@oracle.com> References: <510BD3E6.1090103@oracle.com> Message-ID: <5110A4EC.1050907@oracle.com> Chris, When these failures occur does the failure get reflected in an error exit code? I'm seeing hudson builds merilly buildinh OpenJDK instead of Oracle JDK because the closed repos were skipped due to this bug :( David On 2/02/2013 12:40 AM, Chris Hegarty wrote: > [ to build-dev and core-libs-dev, expect reviewer from either, but will > integrate through jdk8/tl ] > > This issue is mainly of interest to Oracle engineers, but it effects the > public hgforest script. > > When hgforest.sh is run with an addition argument to specify a closed > server, there is a problem/race between the creation of the directories > to hold nested repositories and the clone itself. These directories need > to be created before the clone command is executed, otherwise it will > fail, as below. > > The trivial fix is to back off these nested repos until their containing > directory exists. > > Webrev: > http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ > > sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log > # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed > jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed > hotspot/test/closed deploy install sponsors pubs > > Waiting 5 secs before spawning next background command. > Waiting 5 secs before spawning next background command. > Waiting 5 secs before spawning next background command. > jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u > /java/devtools/sparc/mercurial/latest/bin/hg clone > http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed > jdk/src/closed: abort: No such file or directory: jdk/src/closed > jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u > /java/devtools/sparc/mercurial/latest/bin/hg clone > http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed > jdk/make/closed: abort: No such file or directory: jdk/make/closed > Waiting 5 secs before spawning next background command. > .... > > > -Chris. From oehrstroem at gmail.com Tue Feb 5 06:38:04 2013 From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Tue, 5 Feb 2013 07:38:04 +0100 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <5110A4EC.1050907@oracle.com> References: <510BD3E6.1090103@oracle.com> <5110A4EC.1050907@oracle.com> Message-ID: Fixing get_source.sh problem: We can hardcode pre-creation of the closed repo locations as mkdir -p calls. We can do the openjdk clone first (in parllell) and when that is finished do the closedjdk clone. We can drop parallell clone altogether because it does not give the speedup we are looking for? We could actually fix how the SCM handles the source code? (Yes, I know that I am reiterating my statement from 2011 here, but I find it incomprehensible that Java is stored in an SCM, in such a way that you cannot reliably bisect to a faulty commit, nor in fact extract any old code from the SCM, in a state that is guaranteed to work or even compile. Johan Walles and I developed a reasonably non-intrusive solution for this where get_source.sh is not needed. So, fixing get_source.sh is clearly in an uphill battle.) //Fredrik 2013/2/5 David Holmes : > Chris, > > When these failures occur does the failure get reflected in an error exit > code? > > I'm seeing hudson builds merilly buildinh OpenJDK instead of Oracle JDK > because the closed repos were skipped due to this bug :( > > David > > > On 2/02/2013 12:40 AM, Chris Hegarty wrote: >> >> [ to build-dev and core-libs-dev, expect reviewer from either, but will >> integrate through jdk8/tl ] >> >> This issue is mainly of interest to Oracle engineers, but it effects the >> public hgforest script. >> >> When hgforest.sh is run with an addition argument to specify a closed >> server, there is a problem/race between the creation of the directories >> to hold nested repositories and the clone itself. These directories need >> to be created before the clone command is executed, otherwise it will >> fail, as below. >> >> The trivial fix is to back off these nested repos until their containing >> directory exists. >> >> Webrev: >> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >> >> sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log >> # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed >> jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed >> hotspot/test/closed deploy install sponsors pubs >> >> Waiting 5 secs before spawning next background command. >> Waiting 5 secs before spawning next background command. >> Waiting 5 secs before spawning next background command. >> jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >> /java/devtools/sparc/mercurial/latest/bin/hg clone >> http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed >> jdk/src/closed: abort: No such file or directory: jdk/src/closed >> jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >> /java/devtools/sparc/mercurial/latest/bin/hg clone >> http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed >> jdk/make/closed: abort: No such file or directory: jdk/make/closed >> Waiting 5 secs before spawning next background command. >> .... >> >> >> -Chris. From lana.steuck at oracle.com Tue Feb 5 07:24:41 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 05 Feb 2013 07:24:41 +0000 Subject: hg: jdk8/tl: Added tag jdk8-b75 for changeset 2a713921952c Message-ID: <20130205072441.3DB904781C@hg.openjdk.java.net> Changeset: 5b19cef637a6 Author: katleman Date: 2013-01-31 17:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/5b19cef637a6 Added tag jdk8-b75 for changeset 2a713921952c ! .hgtags From lana.steuck at oracle.com Tue Feb 5 07:24:41 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 05 Feb 2013 07:24:41 +0000 Subject: hg: jdk8/tl/corba: Added tag jdk8-b75 for changeset d4e68ce17795 Message-ID: <20130205072443.5E08B4781D@hg.openjdk.java.net> Changeset: 4a6be02e66a3 Author: katleman Date: 2013-01-31 17:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/4a6be02e66a3 Added tag jdk8-b75 for changeset d4e68ce17795 ! .hgtags From lana.steuck at oracle.com Tue Feb 5 07:24:45 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 05 Feb 2013 07:24:45 +0000 Subject: hg: jdk8/tl/hotspot: Added tag jdk8-b75 for changeset 6778d0b16593 Message-ID: <20130205072456.148B94781E@hg.openjdk.java.net> Changeset: 20b605466ccb Author: katleman Date: 2013-01-31 17:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/20b605466ccb Added tag jdk8-b75 for changeset 6778d0b16593 ! .hgtags From lana.steuck at oracle.com Tue Feb 5 07:24:44 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 05 Feb 2013 07:24:44 +0000 Subject: hg: jdk8/tl/jaxp: Added tag jdk8-b75 for changeset ff0b73a6b3f6 Message-ID: <20130205072456.2A5914781F@hg.openjdk.java.net> Changeset: 8d65b381880b Author: katleman Date: 2013-01-31 17:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/8d65b381880b Added tag jdk8-b75 for changeset ff0b73a6b3f6 ! .hgtags From lana.steuck at oracle.com Tue Feb 5 07:24:46 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 05 Feb 2013 07:24:46 +0000 Subject: hg: jdk8/tl/jaxws: Added tag jdk8-b75 for changeset 966bf9f3c41a Message-ID: <20130205072456.5C8D447820@hg.openjdk.java.net> Changeset: a63ef2391c20 Author: katleman Date: 2013-01-31 17:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/a63ef2391c20 Added tag jdk8-b75 for changeset 966bf9f3c41a ! .hgtags From lana.steuck at oracle.com Tue Feb 5 07:24:51 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 05 Feb 2013 07:24:51 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20130205072503.59ED147821@hg.openjdk.java.net> Changeset: 716935fec613 Author: katleman Date: 2013-01-31 17:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/716935fec613 Added tag jdk8-b75 for changeset c2e11e2ec4a3 ! .hgtags Changeset: 10619513f51a Author: lana Date: 2013-02-04 22:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/10619513f51a Merge From lana.steuck at oracle.com Tue Feb 5 07:24:58 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 05 Feb 2013 07:24:58 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130205072534.CB9A147822@hg.openjdk.java.net> Changeset: 6ba6353ab42c Author: katleman Date: 2013-01-31 17:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6ba6353ab42c Added tag jdk8-b75 for changeset 4a67fdb752b7 ! .hgtags Changeset: fd37f0846653 Author: lana Date: 2013-02-04 22:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fd37f0846653 Merge From tom.schindl at bestsolution.at Tue Feb 5 08:57:49 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 05 Feb 2013 09:57:49 +0100 Subject: RFR (M): JDK-8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call In-Reply-To: <50F98A3E.3090705@oracle.com> References: <50F6F303.3000504@oracle.com> <50F95E1D.7050202@oracle.com> <9A41FC71-08B0-4F93-98B7-E3FDF4B392D1@oracle.com> <50F98A3E.3090705@oracle.com> Message-ID: <5110C98D.8090100@bestsolution.at> Is this available in any Java8 build? I think the VerifyError is what I see when running Eclipse on Java8 [1] Tom [1]https://bugs.eclipse.org/bugs/show_bug.cgi?id=399801 Am 18.01.13 18:45, schrieb Bharadwaj Yadavalli: > > Thanks for the review, Karen. > > On 1/18/2013 10:15 AM, Karen Kinnear wrote: >> I like the additional checking. I wonder if you could possibly modify >> this to rename >> the API to JVM_IsVMGeneratedMethodIx - since that might be clearer >> that this is has internal >> vm meaning which is not related to any of the specifications on the >> constant pool etc. > > I have made the suggested changes. > > Please review the updated changes at > http://cr.openjdk.java.net/~bharadwaj/8004967/alt_impl > > Hotspot tree changes : > http://cr.openjdk.java.net/~bharadwaj/8004967/alt_impl/hotspot/webrev/ > JDK tree changes : > http://cr.openjdk.java.net/~bharadwaj/8004967/alt_impl/jdk/webrev/ > > Thanks, > > Bharadwaj > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From paul.sandoz at oracle.com Tue Feb 5 09:09:20 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 5 Feb 2013 10:09:20 +0100 Subject: RFR - 6480539: BigDecimal.stripTrailingZeros() should specify no-op on zero BigDecimals In-Reply-To: <51104CE4.10506@oracle.com> References: <51100C97.4040504@oracle.com> <51104CE4.10506@oracle.com> Message-ID: <1BA5F227-8369-4AC4-A108-165A094BD763@oracle.com> On Feb 5, 2013, at 1:05 AM, Joseph Darcy wrote: > > On 2/4/2013 1:36 PM, Stephen Colebourne wrote: >> On 4 February 2013 19:31, Joe Darcy wrote: >>> The stripTrailingZeros method has acted in this surprising way since the >>> IBM-led JSR 13 was integrated into the platform back in JDK 5, which shipped >>> in 2004. >>> >>> This situation is analogous to when the specification and behavior disagree. >>> Our general policy to resolve such cases when evolving the JDK is: >>> >>> "..., there are times in evolving the JDK when differences are found between >>> the specified behavior and the actual behavior (for example 4707389, >>> 6365176). The two basic approaches to fixing these bugs are to change the >>> implementation to match the specified behavior or to change the >>> specification (in a platform release) to match the implementation's (perhaps >>> long-standing) behavior; often the latter option is chosen since it has a >>> lower de facto impact on behavioral compatibility." >>> http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html >>> >>> If this issue were being addressed before JDK 5 shipped or even during JDK >>> 6, I would support changing the behavior of stripTrailingZeros. However, >>> for addressing this in JDK 8, I think it is more appropriate to keep the >>> behavior as-is and document this special case. >> I don't see what JDK 5 vs 6 vs 8 really has to do with it. > > The longer a particular behavior has been in a shipped JDK release, the more likely it is various people have built code that depend on that behavior. > This is one of those unfortunate cases where a bug can become a feature. Sometimes it is useful when evaluating to obtain empirical data on how much such a feature is used e.g. analysing jars from public maven repos: http://grepcode.com/search/usages?type=method&id=repository.grepcode.com%24java%24root at jdk%24openjdk at 7-b147@java%24math at BigDecimal@stripTrailingZeros%28%29&k=u Of course i have no idea of the internals of BigDecimal and what knock on effects such a change would have. Paul. From Alan.Bateman at oracle.com Tue Feb 5 09:30:32 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 05 Feb 2013 09:30:32 +0000 Subject: RFR (M): JDK-8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call In-Reply-To: <5110C98D.8090100@bestsolution.at> References: <50F6F303.3000504@oracle.com> <50F95E1D.7050202@oracle.com> <9A41FC71-08B0-4F93-98B7-E3FDF4B392D1@oracle.com> <50F98A3E.3090705@oracle.com> <5110C98D.8090100@bestsolution.at> Message-ID: <5110D138.3030303@oracle.com> On 05/02/2013 08:57, Tom Schindl wrote: > Is this available in any Java8 build? I think the VerifyError is what I > see when running Eclipse on Java8 [1] > > Tom > > [1]https://bugs.eclipse.org/bugs/show_bug.cgi?id=399801 > Not yet, Bharadwaj has the VM support in hotspot-rt/hotspot and I believe plans to push the changes to the old type-inferencing verifier once the hotspot changes get to jdk8/tl. -Alan. From yekaterina.kantserova at oracle.com Tue Feb 5 10:51:32 2013 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 05 Feb 2013 11:51:32 +0100 Subject: RFR (S) 8007142: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <510FB531.8040407@oracle.com> References: <510BB12C.2030802@oracle.com> <510BB5CC.6050604@oracle.com> <510BC3E0.6020107@oracle.com> <510BCF1B.3010704@oracle.com> <510BD9EF.1050202@oracle.com> <510BDCAA.1080909@oracle.com> <510F8E6C.2090301@oracle.com> <510F9393.8080509@oracle.com> <510F9596.8060503@oracle.com> <510FB531.8040407@oracle.com> Message-ID: <5110E434.40600@oracle.com> On 02/04/2013 02:18 PM, Alan Bateman wrote: > On 04/02/2013 11:03, Yekaterina Kantserova wrote: >> >> But JDKToolFinder.getJDKTool is used even for finding java, e.g. I >> need to fork a java process - JDKToolFinder.getJDKTool("java") for >> some JRE tests? > It might be better to rename JDKToolFinder to something like JdkFinder > and have it define getJavaLauncher() and getTool(String tool) methods. I think it's good idea to separate java launcher and tools. Here is the new JdkFinder: http://cr.openjdk.java.net/~ykantser/8007142/webrev.02/test/lib/testlibrary/jdk/testlibrary/JdkFinder.java.html. It now possible to retrieve java/tools both from the test.jdk and compile.jdk. > If you don't agree then you could at least change > ProcessTools.createJavaProcessBuilder so that it looks like "java" in > the JDK/JRE under test. > JDKToolFinder.getJDKTool("java") became JdkFinder.getJavaLauncher in the createJavaProcessBuilder (http://cr.openjdk.java.net/~ykantser/8007142/webrev.02/test/lib/testlibrary/jdk/testlibrary/ProcessTools.java.html). > -Alan. Thanks, Katja From Alan.Bateman at oracle.com Tue Feb 5 11:54:44 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 05 Feb 2013 11:54:44 +0000 Subject: RFR (S) 8007142: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <5110E434.40600@oracle.com> References: <510BB12C.2030802@oracle.com> <510BB5CC.6050604@oracle.com> <510BC3E0.6020107@oracle.com> <510BCF1B.3010704@oracle.com> <510BD9EF.1050202@oracle.com> <510BDCAA.1080909@oracle.com> <510F8E6C.2090301@oracle.com> <510F9393.8080509@oracle.com> <510F9596.8060503@oracle.com> <510FB531.8040407@oracle.com> <5110E434.40600@oracle.com> Message-ID: <5110F304.4080602@oracle.com> On 05/02/2013 10:51, Yekaterina Kantserova wrote: > On 02/04/2013 02:18 PM, Alan Bateman wrote: >> On 04/02/2013 11:03, Yekaterina Kantserova wrote: >>> >>> But JDKToolFinder.getJDKTool is used even for finding java, e.g. I >>> need to fork a java process - JDKToolFinder.getJDKTool("java") for >>> some JRE tests? >> It might be better to rename JDKToolFinder to something like >> JdkFinder and have it define getJavaLauncher() and getTool(String >> tool) methods. > I think it's good idea to separate java launcher and tools. Here is > the new JdkFinder: > http://cr.openjdk.java.net/~ykantser/8007142/webrev.02/test/lib/testlibrary/jdk/testlibrary/JdkFinder.java.html. > It now possible to retrieve java/tools both from the test.jdk and > compile.jdk. > >> If you don't agree then you could at least change >> ProcessTools.createJavaProcessBuilder so that it looks like "java" in >> the JDK/JRE under test. >> > JDKToolFinder.getJDKTool("java") became JdkFinder.getJavaLauncher in > the createJavaProcessBuilder > (http://cr.openjdk.java.net/~ykantser/8007142/webrev.02/test/lib/testlibrary/jdk/testlibrary/ProcessTools.java.html). >> -Alan. > It looks right to me now. -Alan From chris.hegarty at oracle.com Tue Feb 5 14:07:36 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 05 Feb 2013 14:07:36 +0000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <5110A4EC.1050907@oracle.com> References: <510BD3E6.1090103@oracle.com> <5110A4EC.1050907@oracle.com> Message-ID: <51111228.5010707@oracle.com> On 02/05/2013 06:21 AM, David Holmes wrote: > Chris, > > When these failures occur does the failure get reflected in an error > exit code? Not currently, good point. > I'm seeing hudson builds merilly buildinh OpenJDK instead of Oracle JDK > because the closed repos were skipped due to this bug :( This is what I am seeing too, and the reason I proposed a patch to resolve it. Updated webrev; http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ 1) now checks, and returns, appropriate error code, so that higher level scripts can determine if it completed successfully 2) Added diagnostic error message to help identify potential future problems if a nested repo is blocked for too long -Chris. > > David > > On 2/02/2013 12:40 AM, Chris Hegarty wrote: >> [ to build-dev and core-libs-dev, expect reviewer from either, but will >> integrate through jdk8/tl ] >> >> This issue is mainly of interest to Oracle engineers, but it effects the >> public hgforest script. >> >> When hgforest.sh is run with an addition argument to specify a closed >> server, there is a problem/race between the creation of the directories >> to hold nested repositories and the clone itself. These directories need >> to be created before the clone command is executed, otherwise it will >> fail, as below. >> >> The trivial fix is to back off these nested repos until their containing >> directory exists. >> >> Webrev: >> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >> >> sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log >> # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed >> jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed >> hotspot/test/closed deploy install sponsors pubs >> >> Waiting 5 secs before spawning next background command. >> Waiting 5 secs before spawning next background command. >> Waiting 5 secs before spawning next background command. >> jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >> /java/devtools/sparc/mercurial/latest/bin/hg clone >> http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed >> jdk/src/closed: abort: No such file or directory: jdk/src/closed >> jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >> /java/devtools/sparc/mercurial/latest/bin/hg clone >> http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed >> jdk/make/closed: abort: No such file or directory: jdk/make/closed >> Waiting 5 secs before spawning next background command. >> .... >> >> >> -Chris. From vincent.x.ryan at oracle.com Tue Feb 5 14:27:47 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Tue, 05 Feb 2013 14:27:47 +0000 Subject: hg: jdk8/tl/jdk: 8007483: attributes are ignored when loading keys from a PKCS12 keystore Message-ID: <20130205142810.420EC47838@hg.openjdk.java.net> Changeset: e526277b51be Author: vinnie Date: 2013-02-05 14:25 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e526277b51be 8007483: attributes are ignored when loading keys from a PKCS12 keystore Reviewed-by: mullan ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! test/sun/security/pkcs12/StorePasswordTest.java From Lance.Andersen at oracle.com Tue Feb 5 14:40:15 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 5 Feb 2013 09:40:15 -0500 Subject: review request: 8006505 additional updates for JSR 310 Message-ID: <006D1601-CF80-476A-BC8A-C6B6B226C36F@oracle.com> HI, This is a review request for http://cr.openjdk.java.net/~lancea/8006505/webrev.00/ which adds support to SQLInput/Ouput (used for UDTs) to have generic methods for types allowing support for JSR 310. Also now that 310 is in M6, update Types and JDBCType to add entries for TIME/TIMESTAMP with Timezone There will be a separate webrev from Sherman which will be coming soon which will add some helper methods to the java.sql. datetime classes to go to/from LocalXXX types. 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 alan.bateman at oracle.com Tue Feb 5 14:59:29 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 05 Feb 2013 14:59:29 +0000 Subject: hg: jdk8/tl/jaxp: 8007389: Remove uses of _ as identifier in jaxp Message-ID: <20130205145933.C9A134783A@hg.openjdk.java.net> Changeset: f0ad3747b40e Author: emc Date: 2013-02-05 14:56 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/f0ad3747b40e 8007389: Remove uses of _ as identifier in jaxp Reviewed-by: lancea, joehw ! src/javax/xml/validation/SchemaFactoryFinder.java ! src/javax/xml/xpath/XPathFactoryFinder.java From weijun.wang at oracle.com Tue Feb 5 15:35:08 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 05 Feb 2013 23:35:08 +0800 Subject: How to find out if a file belong to me? Message-ID: <511126AC.2000306@oracle.com> Maybe comparing Files.getAttribute(p, "unix:uid") and UnixSystem().getUid()? Is there a cross-platform way? I noticed Files.getOwner(), but seems UserPrincipal has no method of its own and all its implementation classes are non public. Thanks Max From james.holmlund at oracle.com Tue Feb 5 18:56:11 2013 From: james.holmlund at oracle.com (james.holmlund at oracle.com) Date: Tue, 05 Feb 2013 18:56:11 +0000 Subject: hg: jdk8/tl/langtools: 8007504: Remove @ignore from tests that no longer need it Message-ID: <20130205185616.C6A2647848@hg.openjdk.java.net> Changeset: 2480aec9a3f1 Author: jjh Date: 2013-02-05 18:55 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2480aec9a3f1 8007504: Remove @ignore from tests that no longer need it Reviewed-by: mcimadamore ! test/tools/javac/api/T6306137.java ! test/tools/javac/defaultMethods/TestNoBridgeOnDefaults.java ! test/tools/javac/lambda/LambdaCapture06.java ! test/tools/javac/lambda/LambdaExpr15.java From eric.mccorkle at oracle.com Tue Feb 5 19:58:00 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Tue, 05 Feb 2013 14:58:00 -0500 Subject: Review request for JDK-8007405: Message-ID: <51116448.8050300@oracle.com> Hello, please review this patch, which implements some spec changes for parameter reflection in the java.lang.reflect API. This patch changes the SYNTHESIZED flag to MANDATED, and changes the associated methods. It also updates some javadoc comments. The webrev is here: http://cr.openjdk.java.net/~emc/8007405/ The bug report is here: http://bugs.sun.com/view_bug.do?bug_id=8007405 The latest version of the spec is here: http://cr.openjdk.java.net/~abuckley/8misc.pdf Thanks, Eric From mike.duigou at oracle.com Tue Feb 5 20:10:20 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 5 Feb 2013 12:10:20 -0800 Subject: RFR : 8006594/8006595 : Define jdk_core test set In-Reply-To: <510FE2BD.4080401@oracle.com> References: <216D5987-F917-473E-98EF-C84BAB302C53@oracle.com> <50FFF51B.1030809@oracle.com> <04B58247-CBCC-4825-8CC8-38236442E24A@oracle.com> <510FBD81.4050709@oracle.com> <71B03773-1288-40C0-98E5-137EC2B7F509@oracle.com> <510FE2BD.4080401@oracle.com> Message-ID: <80B155BF-B2E3-40C5-BE86-B0D29F1C4F5C@oracle.com> On Feb 4 2013, at 08:33 , Alan Bateman wrote: > On 04/02/2013 16:02, Mike Duigou wrote: >> : >>> If so then I think we have to careful because -concurrency means a lot of virtual memory and I'm not convinced that we limit it via -vmoption in jdk/test/Makefile >>> I could see us wanting to dial this down on 32-bit Windows for example. >> We do limit the max size via -Xmx512M which does seem quite small and is generally well balanced with the number of cores. >> >> I opened a build/infrastructure issue to have MEMORY_SIZE and perhaps some suggested VM sizes recorded to the spec.gmk I planned to revisit this again once only new build is supported. > My reading of the make file is that -J-Xmx512m is passed to jtreg and so it's the maximum heap size of the jtreg process, not the agent VMs running tests. If we are turning on concurrency then it will need -vmoption:-Xmx512m too, otherwise you risk each agent reserving 1/4 of physical memory. In addition, limited virtual memory on Windows 32-bit will limit the number of agent VMs that you can run and so $(JOBS) may be too much. You might need to limit it to 2 or 3 on Windows 32-bit. OK, that is my misunderstanding. I thought it was being applied to both the jtreg vm and the test vms. I think for now I will just remove concurrent rather than try to set VM sizing. > >> >>> Also I'm not 100% sure that jdk/test/TEST.ROOT is up to date for the client area -- that's the place where excludeAccess.dirs lists the directories with tests that cannot run concurrently. >> The makefile currently segregates tests to use othervm or agentvm by target ie. jdk_beans1 . I haven't checked whether these are synchronized against TEST.ROOT and indeed it would be a shame if these had not been kept in sync. (This is why I added notes about "keep this in sync with ..." in various places) I will check this with Stuart Marks today and plan remediation if necessary. > I think we should ultimately remove the othervm vs. agentvm selection from the make file. Agreed > I just checked TEST.ROOT and othervm.dirs is right. The value of exclusiveAccess.dirs looks right too but may be incomplete -- I just don't run the client area tests to know if there are any areas that cannot run concurrently. We can hopefully improve this in future rounds. Mike From eric.mccorkle at oracle.com Tue Feb 5 20:40:09 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Tue, 05 Feb 2013 15:40:09 -0500 Subject: Review request for JDK-8007405: Update parameter reflection API in accordance with spec changes In-Reply-To: <51116448.8050300@oracle.com> References: <51116448.8050300@oracle.com> Message-ID: <51116E29.8020600@oracle.com> Clarification here: the issue's title is a bit more narrow than the scope of the fix. It addresses some javadoc comments and handling of nameless parameters as well. On 02/05/13 14:58, Eric McCorkle wrote: > Hello, please review this patch, which implements some spec changes for > parameter reflection in the java.lang.reflect API. > > This patch changes the SYNTHESIZED flag to MANDATED, and changes the > associated methods. It also updates some javadoc comments. > > The webrev is here: > http://cr.openjdk.java.net/~emc/8007405/ > > The bug report is here: > http://bugs.sun.com/view_bug.do?bug_id=8007405 > > The latest version of the spec is here: > http://cr.openjdk.java.net/~abuckley/8misc.pdf > > Thanks, > Eric From joe.darcy at oracle.com Tue Feb 5 22:16:31 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 05 Feb 2013 14:16:31 -0800 Subject: JDK 8 code review request for 8005623: Retrofit FunctionalInterface annotations to core platform interfaces Message-ID: <511184BF.9040202@oracle.com> Hello, As a follow-up to adding the FunctionalInterface annotation type to the platform, the time has come to annotate JDK classes with the annotation. I ran an annotation processor over the sources in the jdk repo to look for candidates to be marked as FunctionalInterfaces and for a first cut I have added the annotation to 34 types, including all of the types in java.util.function: src/share/classes/java/io/Closeable.java src/share/classes/java/io/FileFilter.java src/share/classes/java/io/FilenameFilter.java src/share/classes/java/io/Flushable.java src/share/classes/java/lang/AutoCloseable.java src/share/classes/java/lang/Comparable.java src/share/classes/java/lang/Iterable.java src/share/classes/java/lang/Readable.java src/share/classes/java/lang/Runnable.java src/share/classes/java/lang/Thread.java src/share/classes/java/util/Comparator.java src/share/classes/java/util/function/BinaryOperator.java src/share/classes/java/util/function/Block.java src/share/classes/java/util/function/DoubleBinaryOperator.java src/share/classes/java/util/function/DoubleBlock.java src/share/classes/java/util/function/DoubleFunction.java src/share/classes/java/util/function/DoubleSupplier.java src/share/classes/java/util/function/DoubleUnaryOperator.java src/share/classes/java/util/function/Function.java src/share/classes/java/util/function/IntBinaryOperator.java src/share/classes/java/util/function/IntBlock.java src/share/classes/java/util/function/IntFunction.java src/share/classes/java/util/function/IntSupplier.java src/share/classes/java/util/function/IntUnaryOperator.java src/share/classes/java/util/function/LongBinaryOperator.java src/share/classes/java/util/function/LongBlock.java src/share/classes/java/util/function/LongFunction.java src/share/classes/java/util/function/LongSupplier.java src/share/classes/java/util/function/LongUnaryOperator.java src/share/classes/java/util/function/Predicate.java src/share/classes/java/util/function/Supplier.java src/share/classes/java/util/function/UnaryOperator.java src/share/classes/java/util/logging/Filter.java src/share/classes/java/util/prefs/PreferenceChangeListener.java Webrev: http://cr.openjdk.java.net/~darcy/8005623.0/ This review is both to cover the addition of @FunctionalInterface to the types above and also to query if the annotation should be included in any of the other types below under the same bug. The sub-areas I have not annotated yet include: * xml * jdbc * JSR 310 * JNDI * RMI * Beans * networking * JMX/management * java.util.concurrent The annotation can be added in these areas separately later as well; if that is done, I recommend sub-tasks of JDK-8005297 "Add FunctionalInterface support to the platform" be used to track the work. I'll separately be sending email to the security and awt/swing teams about the functional interface candidates in their areas. Thanks, -Joe misc core ======== jdk/src/share/classes/java/lang/annotation/Annotation.java:40: Note: Candidate functional interface public interface Annotation { ^ jdk/src/share/classes/java/io/ObjectInputValidation.java:38: Note: Candidate functional interface public interface ObjectInputValidation { ^ jdk/src/share/classes/java/util/ResourceBundle.java:690: Note: Candidate functional interface private static interface CacheKeyReference { ^ jdk/src/share/classes/java/util/spi/ResourceBundleControlProvider.java:51: Note: Candidate functional interface public interface ResourceBundleControlProvider { ^ jdk/src/share/classes/java/util/Formattable.java:119: Note: Candidate functional interface public interface Formattable { ^ jdk/src/share/classes/java/util/Observer.java:35: Note: Candidate functional interface public interface Observer { ^ jdk/src/share/classes/java/nio/file/WatchEvent.java:76: Note: Candidate functional interface public static interface Modifier { ^ jdk/src/share/classes/java/nio/file/attribute/AttributeView.java:38: Note: Candidate functional interface public interface AttributeView { ^ jdk/src/share/classes/java/nio/file/attribute/FileStoreAttributeView.java:35: Note: Candidate functional interface public interface FileStoreAttributeView ^ jdk/src/share/classes/java/nio/file/attribute/FileAttributeView.java:39: Note: Candidate functional interface public interface FileAttributeView ^ jdk/src/share/classes/java/nio/file/attribute/UserPrincipal.java:54: Note: Candidate functional interface public interface UserPrincipal extends Principal { } ^ jdk/src/share/classes/java/nio/file/attribute/GroupPrincipal.java:42: Note: Candidate functional interface public interface GroupPrincipal extends UserPrincipal { } ^ jdk/src/share/classes/java/nio/file/PathMatcher.java:38: Note: Candidate functional interface public interface PathMatcher { ^ jdk/src/share/classes/java/nio/file/DirectoryStream.java:133: Note: Candidate functional interface public static interface Filter { ^ jdk/src/share/classes/javax/accessibility/Accessible.java:39: Note: Candidate functional interface public interface Accessible { ^ jdk/src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheData.java:37: Note: Candidate functional interface public interface ApacheData extends Data { reflection ============= jdk/src/share/classes/java/lang/reflect/GenericArrayType.java:33: Note: Candidate functional interface public interface GenericArrayType extends Type { ^ jdk/src/share/classes/java/lang/reflect/GenericDeclaration.java:33: Note: Candidate functional interface public interface GenericDeclaration { ^ jdk/src/share/classes/java/lang/reflect/InvocationHandler.java:41: Note: Candidate functional interface public interface InvocationHandler { ^ xml ===== jdk/src/share/classes/javax/xml/crypto/KeySelectorResult.java:46: Note: Candidate functional interface public interface KeySelectorResult { ^ jdk/src/share/classes/javax/xml/crypto/URIDereferencer.java:55: Note: Candidate functional interface public interface URIDereferencer { ^ jdk/src/share/classes/javax/xml/crypto/NodeSetData.java:42: Note: Candidate functional interface public interface NodeSetData extends Data { ^ jdk/src/share/classes/javax/xml/crypto/XMLStructure.java:39: Note: Candidate functional interface public interface XMLStructure { ^ JDBC - Assuming this will be handled separately under JDBC maintenance ====== jdk/src/share/classes/java/sql/RowId.java:63: Note: Candidate functional interface public interface RowId { ^ jdk/src/share/classes/javax/sql/RowSetReader.java:41: Note: Candidate functional interface public interface RowSetReader { ^ jdk/src/share/classes/javax/sql/RowSetWriter.java:49: Note: Candidate functional interface public interface RowSetWriter { ^ JSR 310 - Assuming this will be handled separately under JSR 310 evolution ========= jdk/src/share/classes/java/time/temporal/TemporalAdjuster.java:96: Note: Candidate functional interface public interface TemporalAdjuster { ^ jdk/src/share/classes/java/time/temporal/TemporalQuery.java:101: Note: Candidate functional interface public interface TemporalQuery { ^ jdk/src/share/classes/java/time/temporal/TemporalAdder.java:95: Note: Candidate functional interface public interface TemporalAdder { ^ jdk/src/share/classes/java/time/temporal/TemporalSubtractor.java:95: Note: Candidate functional interface public interface TemporalSubtractor { ^ JNDI ====== jdk/src/share/classes/javax/naming/event/NamingListener.java:57: Note: Candidate functional interface public interface NamingListener extends java.util.EventListener { ^ jdk/src/share/classes/javax/naming/ldap/HasControls.java:60: Note: Candidate functional interface public interface HasControls { ^ jdk/src/share/classes/javax/naming/Referenceable.java:49: Note: Candidate functional interface public interface Referenceable { ^ jdk/src/share/classes/javax/naming/NameParser.java:45: Note: Candidate functional interface public interface NameParser { ^ jdk/src/share/classes/javax/naming/spi/StateFactory.java:80: Note: Candidate functional interface public interface StateFactory { ^ jdk/src/share/classes/javax/naming/spi/ObjectFactoryBuilder.java:57: Note: Candidate functional interface public interface ObjectFactoryBuilder { ^ jdk/src/share/classes/javax/naming/spi/ObjectFactory.java:70: Note: Candidate functional interface public interface ObjectFactory { ^ jdk/src/share/classes/javax/naming/spi/InitialContextFactoryBuilder.java:54: Note: Candidate functional interface public interface InitialContextFactoryBuilder { ^ jdk/src/share/classes/javax/naming/spi/InitialContextFactory.java:53: Note: Candidate functional interface public interface InitialContextFactory { ^ RMI ===== jdk/src/share/classes/java/rmi/activation/ActivationInstantiator.java:42: Note: Candidate functional interface public interface ActivationInstantiator extends Remote { ^ jdk/src/share/classes/java/rmi/activation/Activator.java:64: Note: Candidate functional interface public interface Activator extends Remote { ^ jdk/src/share/classes/java/rmi/server/RMIServerSocketFactory.java:61: Note: Candidate functional interface public interface RMIServerSocketFactory { ^ jdk/src/share/classes/java/rmi/server/RMIFailureHandler.java:40: Note: Candidate functional interface public interface RMIFailureHandler { ^ jdk/src/share/classes/java/rmi/server/RMIClientSocketFactory.java:62: Note: Candidate functional interface public interface RMIClientSocketFactory { ^ jdk/src/share/classes/java/rmi/server/Unreferenced.java:37: Note: Candidate functional interface public interface Unreferenced { ^ Beans ======== jdk/src/share/classes/java/beans/PropertyChangeListener.java:34: Note: Candidate functional interface public interface PropertyChangeListener extends java.util.EventListener { ^ jdk/src/share/classes/java/beans/VetoableChangeListener.java:33: Note: Candidate functional interface public interface VetoableChangeListener extends java.util.EventListener { ^ jdk/src/share/classes/java/beans/ExceptionListener.java:34: Note: Candidate functional interface public interface ExceptionListener { ^ jdk/src/share/classes/java/beans/beancontext/BeanContextServiceRevokedListener.java:37: Note: Candidate functional interface public interface BeanContextServiceRevokedListener extends EventListener { ^ jdk/src/share/classes/java/beans/beancontext/BeanContextProxy.java:76: Note: Candidate functional interface public interface BeanContextProxy { ^ jdk/src/share/classes/java/beans/beancontext/BeanContextContainerProxy.java:43: Note: Candidate functional interface public interface BeanContextContainerProxy { ^ jdk/src/share/classes/java/beans/beancontext/BeanContextChildComponentProxy.java:44: Note: Candidate functional interface public interface BeanContextChildComponentProxy { ^ networking ========== jdk/src/share/classes/java/net/ContentHandlerFactory.java:41: Note: Candidate functional interface public interface ContentHandlerFactory { ^ jdk/src/share/classes/java/net/HttpCookie.java:855: Note: Candidate functional interface static interface CookieAttributeAssignor { ^ jdk/src/share/classes/java/net/SocketImplFactory.java:40: Note: Candidate functional interface interface SocketImplFactory { ^ jdk/src/share/classes/java/net/CookiePolicy.java:38: Note: Candidate functional interface public interface CookiePolicy { ^ jdk/src/share/classes/java/net/URLStreamHandlerFactory.java:40: Note: Candidate functional interface public interface URLStreamHandlerFactory { ^ jdk/src/share/classes/java/net/DatagramSocketImplFactory.java:38: Note: Candidate functional interface interface DatagramSocketImplFactory { ^ jdk/src/share/classes/java/net/FileNameMap.java:35: Note: Candidate functional interface public interface FileNameMap { ^ jdk/src/share/classes/java/net/ProtocolFamily.java:34: Note: Candidate functional interface public interface ProtocolFamily { ^ jdk/src/share/classes/javax/net/ssl/HostnameVerifier.java:46: Note: Candidate functional interface public interface HostnameVerifier { ^ jdk/src/share/classes/javax/net/ssl/HandshakeCompletedListener.java:44: Note: Candidate functional interface public interface HandshakeCompletedListener extends EventListener ^ jmx/management ================ jdk/src/share/classes/java/lang/management/PlatformManagedObject.java:52: Note: Candidate functional interface public interface PlatformManagedObject { ^ jdk/src/share/classes/java/lang/management/PlatformComponent.java:279: Note: Candidate functional interface interface MXBeanFetcher { ^ jdk/src/share/classes/java/lang/instrument/ClassFileTransformer.java:50: Note: Candidate functional interface public interface ClassFileTransformer { ^ jdk/src/share/classes/javax/management/openmbean/CompositeDataView.java:109: Note: Candidate functional interface public interface CompositeDataView { ^ jdk/src/share/classes/javax/management/NotificationFilter.java:35: Note: Candidate functional interface public interface NotificationFilter extends java.io.Serializable { ^ jdk/src/share/classes/javax/management/remote/JMXAddressable.java:44: Note: Candidate functional interface public interface JMXAddressable { ^ jdk/src/share/classes/javax/management/remote/JMXAuthenticator.java:52: Note: Candidate functional interface public interface JMXAuthenticator { ^ jdk/src/share/classes/javax/management/remote/JMXConnectorServerProvider.java:42: Note: Candidate functional interface public interface JMXConnectorServerProvider { ^ jdk/src/share/classes/javax/management/remote/JMXConnectorProvider.java:41: Note: Candidate functional interface public interface JMXConnectorProvider { ^ jdk/src/share/classes/javax/management/NotificationListener.java:34: Note: Candidate functional interface public interface NotificationListener extends java.util.EventListener { ^ jdk/src/share/classes/javax/management/DescriptorRead.java:33: Note: Candidate functional interface public interface DescriptorRead { ^ concurrent - Assume this will be done first upstream in Doug's repos ============ jdk/src/share/classes/java/util/concurrent/ThreadFactory.java:58: Note: Candidate functional interface public interface ThreadFactory { ^ jdk/src/share/classes/java/util/concurrent/ForkJoinPool.java:545: Note: Candidate functional interface public static interface ForkJoinWorkerThreadFactory { ^ jdk/src/share/classes/java/util/concurrent/RejectedExecutionHandler.java:44: Note: Candidate functional interface public interface RejectedExecutionHandler { ^ jdk/src/share/classes/java/util/concurrent/Callable.java:57: Note: Candidate functional interface public interface Callable { ^ jdk/src/share/classes/java/util/concurrent/Executor.java:128: Note: Candidate functional interface public interface Executor { From jaroslav.bachorik at oracle.com Tue Feb 5 11:29:19 2013 From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com) Date: Tue, 05 Feb 2013 11:29:19 +0000 Subject: hg: jdk8/tl/jdk: 7170447: Intermittent DeadListenerTest.java failure Message-ID: <20130205112943.1E78647830@hg.openjdk.java.net> Changeset: 9ffcd758e2be Author: jbachorik Date: 2013-02-05 12:28 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9ffcd758e2be 7170447: Intermittent DeadListenerTest.java failure Summary: Due to asynchronous nature of processing server notifications it may happen that an "unregister" notification ha$ Reviewed-by: sjiang ! test/javax/management/remote/mandatory/notif/DeadListenerTest.java From jaroslav.bachorik at oracle.com Tue Feb 5 11:38:04 2013 From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com) Date: Tue, 05 Feb 2013 11:38:04 +0000 Subject: hg: jdk8/tl/jdk: 8005791: Remove java.beans.* imports from com.sun.jmx.mbeanserver.Introspector Message-ID: <20130205113826.4CEED47831@hg.openjdk.java.net> Changeset: 3119f0ebb58d Author: jbachorik Date: 2013-02-05 12:36 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3119f0ebb58d 8005791: Remove java.beans.* imports from com.sun.jmx.mbeanserver.Introspector Reviewed-by: rbackman ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java From mike.duigou at oracle.com Tue Feb 5 22:34:56 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 5 Feb 2013 14:34:56 -0800 Subject: JDK 8 code review request for 8005623: Retrofit FunctionalInterface annotations to core platform interfaces In-Reply-To: <511184BF.9040202@oracle.com> References: <511184BF.9040202@oracle.com> Message-ID: <21EF2C01-7D53-4691-B910-5503DE9A19AD@oracle.com> Looks fine to me. Mike On Feb 5 2013, at 14:16 , Joe Darcy wrote: > Hello, > > As a follow-up to adding the FunctionalInterface annotation type to the platform, the time has come to annotate JDK classes with the annotation. > > I ran an annotation processor over the sources in the jdk repo to look for candidates to be marked as FunctionalInterfaces and for a first cut I have added the annotation to 34 types, including all of the types in java.util.function: > > src/share/classes/java/io/Closeable.java > src/share/classes/java/io/FileFilter.java > src/share/classes/java/io/FilenameFilter.java > src/share/classes/java/io/Flushable.java > src/share/classes/java/lang/AutoCloseable.java > src/share/classes/java/lang/Comparable.java > src/share/classes/java/lang/Iterable.java > src/share/classes/java/lang/Readable.java > src/share/classes/java/lang/Runnable.java > src/share/classes/java/lang/Thread.java > src/share/classes/java/util/Comparator.java > src/share/classes/java/util/function/BinaryOperator.java > src/share/classes/java/util/function/Block.java > src/share/classes/java/util/function/DoubleBinaryOperator.java > src/share/classes/java/util/function/DoubleBlock.java > src/share/classes/java/util/function/DoubleFunction.java > src/share/classes/java/util/function/DoubleSupplier.java > src/share/classes/java/util/function/DoubleUnaryOperator.java > src/share/classes/java/util/function/Function.java > src/share/classes/java/util/function/IntBinaryOperator.java > src/share/classes/java/util/function/IntBlock.java > src/share/classes/java/util/function/IntFunction.java > src/share/classes/java/util/function/IntSupplier.java > src/share/classes/java/util/function/IntUnaryOperator.java > src/share/classes/java/util/function/LongBinaryOperator.java > src/share/classes/java/util/function/LongBlock.java > src/share/classes/java/util/function/LongFunction.java > src/share/classes/java/util/function/LongSupplier.java > src/share/classes/java/util/function/LongUnaryOperator.java > src/share/classes/java/util/function/Predicate.java > src/share/classes/java/util/function/Supplier.java > src/share/classes/java/util/function/UnaryOperator.java > src/share/classes/java/util/logging/Filter.java > src/share/classes/java/util/prefs/PreferenceChangeListener.java > > Webrev: > http://cr.openjdk.java.net/~darcy/8005623.0/ > > This review is both to cover the addition of @FunctionalInterface to the types above and also to query if the annotation should be included in any of the other types below under the same bug. The sub-areas I have not annotated yet include: > > * xml > * jdbc > * JSR 310 > * JNDI > * RMI > * Beans > * networking > * JMX/management > * java.util.concurrent > > The annotation can be added in these areas separately later as well; if that is done, I recommend sub-tasks of JDK-8005297 "Add FunctionalInterface support to the platform" be used to track the work. > > I'll separately be sending email to the security and awt/swing teams about the functional interface candidates in their areas. > > Thanks, > > -Joe > > misc core > ======== > > jdk/src/share/classes/java/lang/annotation/Annotation.java:40: Note: Candidate functional interface > public interface Annotation { > ^ > jdk/src/share/classes/java/io/ObjectInputValidation.java:38: Note: Candidate functional interface > public interface ObjectInputValidation { > ^ > jdk/src/share/classes/java/util/ResourceBundle.java:690: Note: Candidate functional interface > private static interface CacheKeyReference { > ^ > jdk/src/share/classes/java/util/spi/ResourceBundleControlProvider.java:51: Note: Candidate functional interface > public interface ResourceBundleControlProvider { > ^ > jdk/src/share/classes/java/util/Formattable.java:119: Note: Candidate functional interface > public interface Formattable { > ^ > jdk/src/share/classes/java/util/Observer.java:35: Note: Candidate functional interface > public interface Observer { > ^ > jdk/src/share/classes/java/nio/file/WatchEvent.java:76: Note: Candidate functional interface > public static interface Modifier { > ^ > jdk/src/share/classes/java/nio/file/attribute/AttributeView.java:38: Note: Candidate functional interface > public interface AttributeView { > ^ > jdk/src/share/classes/java/nio/file/attribute/FileStoreAttributeView.java:35: Note: Candidate functional interface > public interface FileStoreAttributeView > ^ > jdk/src/share/classes/java/nio/file/attribute/FileAttributeView.java:39: Note: Candidate functional interface > public interface FileAttributeView > ^ > jdk/src/share/classes/java/nio/file/attribute/UserPrincipal.java:54: Note: Candidate functional interface > public interface UserPrincipal extends Principal { } > ^ > jdk/src/share/classes/java/nio/file/attribute/GroupPrincipal.java:42: Note: Candidate functional interface > public interface GroupPrincipal extends UserPrincipal { } > ^ > jdk/src/share/classes/java/nio/file/PathMatcher.java:38: Note: Candidate functional interface > public interface PathMatcher { > ^ > jdk/src/share/classes/java/nio/file/DirectoryStream.java:133: Note: Candidate functional interface > public static interface Filter { > ^ > jdk/src/share/classes/javax/accessibility/Accessible.java:39: Note: Candidate functional interface > public interface Accessible { > ^ > > jdk/src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheData.java:37: Note: Candidate functional interface > public interface ApacheData extends Data { > > reflection > ============= > > jdk/src/share/classes/java/lang/reflect/GenericArrayType.java:33: Note: Candidate functional interface > public interface GenericArrayType extends Type { > ^ > > jdk/src/share/classes/java/lang/reflect/GenericDeclaration.java:33: Note: Candidate functional interface > public interface GenericDeclaration { > ^ > jdk/src/share/classes/java/lang/reflect/InvocationHandler.java:41: Note: Candidate functional interface > public interface InvocationHandler { > ^ > > > xml > ===== > > jdk/src/share/classes/javax/xml/crypto/KeySelectorResult.java:46: Note: Candidate functional interface > public interface KeySelectorResult { > ^ > jdk/src/share/classes/javax/xml/crypto/URIDereferencer.java:55: Note: Candidate functional interface > public interface URIDereferencer { > ^ > jdk/src/share/classes/javax/xml/crypto/NodeSetData.java:42: Note: Candidate functional interface > public interface NodeSetData extends Data { > ^ > jdk/src/share/classes/javax/xml/crypto/XMLStructure.java:39: Note: Candidate functional interface > public interface XMLStructure { > ^ > > JDBC - Assuming this will be handled separately under JDBC maintenance > ====== > > jdk/src/share/classes/java/sql/RowId.java:63: Note: Candidate functional interface > public interface RowId { > ^ > jdk/src/share/classes/javax/sql/RowSetReader.java:41: Note: Candidate functional interface > public interface RowSetReader { > ^ > jdk/src/share/classes/javax/sql/RowSetWriter.java:49: Note: Candidate functional interface > public interface RowSetWriter { > ^ > JSR 310 - Assuming this will be handled separately under JSR 310 evolution > ========= > > jdk/src/share/classes/java/time/temporal/TemporalAdjuster.java:96: Note: Candidate functional interface > public interface TemporalAdjuster { > ^ > jdk/src/share/classes/java/time/temporal/TemporalQuery.java:101: Note: Candidate functional interface > public interface TemporalQuery { > ^ > jdk/src/share/classes/java/time/temporal/TemporalAdder.java:95: Note: Candidate functional interface > public interface TemporalAdder { > ^ > jdk/src/share/classes/java/time/temporal/TemporalSubtractor.java:95: Note: Candidate functional interface > public interface TemporalSubtractor { > ^ > > JNDI > ====== > > jdk/src/share/classes/javax/naming/event/NamingListener.java:57: Note: Candidate functional interface > public interface NamingListener extends java.util.EventListener { > ^ > jdk/src/share/classes/javax/naming/ldap/HasControls.java:60: Note: Candidate functional interface > public interface HasControls { > ^ > jdk/src/share/classes/javax/naming/Referenceable.java:49: Note: Candidate functional interface > public interface Referenceable { > ^ > jdk/src/share/classes/javax/naming/NameParser.java:45: Note: Candidate functional interface > public interface NameParser { > ^ > jdk/src/share/classes/javax/naming/spi/StateFactory.java:80: Note: Candidate functional interface > public interface StateFactory { > ^ > jdk/src/share/classes/javax/naming/spi/ObjectFactoryBuilder.java:57: Note: Candidate functional interface > public interface ObjectFactoryBuilder { > ^ > jdk/src/share/classes/javax/naming/spi/ObjectFactory.java:70: Note: Candidate functional interface > public interface ObjectFactory { > ^ > jdk/src/share/classes/javax/naming/spi/InitialContextFactoryBuilder.java:54: Note: Candidate functional interface > public interface InitialContextFactoryBuilder { > ^ > jdk/src/share/classes/javax/naming/spi/InitialContextFactory.java:53: Note: Candidate functional interface > public interface InitialContextFactory { > ^ > > RMI > ===== > > jdk/src/share/classes/java/rmi/activation/ActivationInstantiator.java:42: Note: Candidate functional interface > public interface ActivationInstantiator extends Remote { > ^ > jdk/src/share/classes/java/rmi/activation/Activator.java:64: Note: Candidate functional interface > public interface Activator extends Remote { > ^ > jdk/src/share/classes/java/rmi/server/RMIServerSocketFactory.java:61: Note: Candidate functional interface > public interface RMIServerSocketFactory { > ^ > jdk/src/share/classes/java/rmi/server/RMIFailureHandler.java:40: Note: Candidate functional interface > public interface RMIFailureHandler { > ^ > jdk/src/share/classes/java/rmi/server/RMIClientSocketFactory.java:62: Note: Candidate functional interface > public interface RMIClientSocketFactory { > ^ > jdk/src/share/classes/java/rmi/server/Unreferenced.java:37: Note: Candidate functional interface > public interface Unreferenced { > ^ > Beans > ======== > > jdk/src/share/classes/java/beans/PropertyChangeListener.java:34: Note: Candidate functional interface > public interface PropertyChangeListener extends java.util.EventListener { > ^ > jdk/src/share/classes/java/beans/VetoableChangeListener.java:33: Note: Candidate functional interface > public interface VetoableChangeListener extends java.util.EventListener { > ^ > jdk/src/share/classes/java/beans/ExceptionListener.java:34: Note: Candidate functional interface > public interface ExceptionListener { > ^ > jdk/src/share/classes/java/beans/beancontext/BeanContextServiceRevokedListener.java:37: Note: Candidate functional interface > public interface BeanContextServiceRevokedListener extends EventListener { > ^ > jdk/src/share/classes/java/beans/beancontext/BeanContextProxy.java:76: Note: Candidate functional interface > public interface BeanContextProxy { > ^ > jdk/src/share/classes/java/beans/beancontext/BeanContextContainerProxy.java:43: Note: Candidate functional interface > public interface BeanContextContainerProxy { > ^ > jdk/src/share/classes/java/beans/beancontext/BeanContextChildComponentProxy.java:44: Note: Candidate functional interface > public interface BeanContextChildComponentProxy { > ^ > networking > ========== > > jdk/src/share/classes/java/net/ContentHandlerFactory.java:41: Note: Candidate functional interface > public interface ContentHandlerFactory { > ^ > jdk/src/share/classes/java/net/HttpCookie.java:855: Note: Candidate functional interface > static interface CookieAttributeAssignor { > ^ > jdk/src/share/classes/java/net/SocketImplFactory.java:40: Note: Candidate functional interface > interface SocketImplFactory { > ^ > jdk/src/share/classes/java/net/CookiePolicy.java:38: Note: Candidate functional interface > public interface CookiePolicy { > ^ > jdk/src/share/classes/java/net/URLStreamHandlerFactory.java:40: Note: Candidate functional interface > public interface URLStreamHandlerFactory { > ^ > jdk/src/share/classes/java/net/DatagramSocketImplFactory.java:38: Note: Candidate functional interface > interface DatagramSocketImplFactory { > ^ > jdk/src/share/classes/java/net/FileNameMap.java:35: Note: Candidate functional interface > public interface FileNameMap { > ^ > jdk/src/share/classes/java/net/ProtocolFamily.java:34: Note: Candidate functional interface > public interface ProtocolFamily { > ^ > jdk/src/share/classes/javax/net/ssl/HostnameVerifier.java:46: Note: Candidate functional interface > public interface HostnameVerifier { > ^ > jdk/src/share/classes/javax/net/ssl/HandshakeCompletedListener.java:44: Note: Candidate functional interface > public interface HandshakeCompletedListener extends EventListener > ^ > jmx/management > ================ > > jdk/src/share/classes/java/lang/management/PlatformManagedObject.java:52: Note: Candidate functional interface > public interface PlatformManagedObject { > ^ > jdk/src/share/classes/java/lang/management/PlatformComponent.java:279: Note: Candidate functional interface > interface MXBeanFetcher { > ^ > jdk/src/share/classes/java/lang/instrument/ClassFileTransformer.java:50: Note: Candidate functional interface > public interface ClassFileTransformer { > ^ > jdk/src/share/classes/javax/management/openmbean/CompositeDataView.java:109: Note: Candidate functional interface > public interface CompositeDataView { > ^ > jdk/src/share/classes/javax/management/NotificationFilter.java:35: Note: Candidate functional interface > public interface NotificationFilter extends java.io.Serializable { > ^ > jdk/src/share/classes/javax/management/remote/JMXAddressable.java:44: Note: Candidate functional interface > public interface JMXAddressable { > ^ > jdk/src/share/classes/javax/management/remote/JMXAuthenticator.java:52: Note: Candidate functional interface > public interface JMXAuthenticator { > ^ > jdk/src/share/classes/javax/management/remote/JMXConnectorServerProvider.java:42: Note: Candidate functional interface > public interface JMXConnectorServerProvider { > ^ > jdk/src/share/classes/javax/management/remote/JMXConnectorProvider.java:41: Note: Candidate functional interface > public interface JMXConnectorProvider { > ^ > jdk/src/share/classes/javax/management/NotificationListener.java:34: Note: Candidate functional interface > public interface NotificationListener extends java.util.EventListener { > ^ > jdk/src/share/classes/javax/management/DescriptorRead.java:33: Note: Candidate functional interface > public interface DescriptorRead { > ^ > concurrent - Assume this will be done first upstream in Doug's repos > ============ > > jdk/src/share/classes/java/util/concurrent/ThreadFactory.java:58: Note: Candidate functional interface > public interface ThreadFactory { > ^ > jdk/src/share/classes/java/util/concurrent/ForkJoinPool.java:545: Note: Candidate functional interface > public static interface ForkJoinWorkerThreadFactory { > ^ > jdk/src/share/classes/java/util/concurrent/RejectedExecutionHandler.java:44: Note: Candidate functional interface > public interface RejectedExecutionHandler { > ^ > jdk/src/share/classes/java/util/concurrent/Callable.java:57: Note: Candidate functional interface > public interface Callable { > ^ > jdk/src/share/classes/java/util/concurrent/Executor.java:128: Note: Candidate functional interface > public interface Executor { > From Ulf.Zibis at CoSoCo.de Tue Feb 5 23:07:35 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Wed, 06 Feb 2013 00:07:35 +0100 Subject: review request: 8006505 additional updates for JSR 310 In-Reply-To: <006D1601-CF80-476A-BC8A-C6B6B226C36F@oracle.com> References: <006D1601-CF80-476A-BC8A-C6B6B226C36F@oracle.com> Message-ID: <511190B7.2030703@CoSoCo.de> Am 05.02.2013 15:40, schrieb Lance Andersen - Oracle: > HI, > > > This is a review request for http://cr.openjdk.java.net/~lancea/8006505/webrev.00/ which adds support to SQLInput/Ouput (used for UDTs) to have generic methods for types allowing support for JSR 310. > Hi Lance, I would set the exception message to "method not implemented" instead "read/writeObject not implemented". the latter looks more like a parameter, which is not present. Have you observed internal review ID of 2426775? -Ulf From chris.hegarty at oracle.com Tue Feb 5 23:20:39 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 5 Feb 2013 23:20:39 +0000 Subject: JDK 8 code review request for 8005623: Retrofit FunctionalInterface annotations to core platform interfaces In-Reply-To: <21EF2C01-7D53-4691-B910-5503DE9A19AD@oracle.com> References: <511184BF.9040202@oracle.com> <21EF2C01-7D53-4691-B910-5503DE9A19AD@oracle.com> Message-ID: <1D460CC1-6374-42E1-8CB3-9903EFCAC830@oracle.com> On 5 Feb 2013, at 22:34, Mike Duigou wrote: > Looks fine to me. +1, looks good to me too. -Chris > > Mike > > On Feb 5 2013, at 14:16 , Joe Darcy wrote: > >> Hello, >> >> As a follow-up to adding the FunctionalInterface annotation type to the platform, the time has come to annotate JDK classes with the annotation. >> >> I ran an annotation processor over the sources in the jdk repo to look for candidates to be marked as FunctionalInterfaces and for a first cut I have added the annotation to 34 types, including all of the types in java.util.function: >> >> src/share/classes/java/io/Closeable.java >> src/share/classes/java/io/FileFilter.java >> src/share/classes/java/io/FilenameFilter.java >> src/share/classes/java/io/Flushable.java >> src/share/classes/java/lang/AutoCloseable.java >> src/share/classes/java/lang/Comparable.java >> src/share/classes/java/lang/Iterable.java >> src/share/classes/java/lang/Readable.java >> src/share/classes/java/lang/Runnable.java >> src/share/classes/java/lang/Thread.java >> src/share/classes/java/util/Comparator.java >> src/share/classes/java/util/function/BinaryOperator.java >> src/share/classes/java/util/function/Block.java >> src/share/classes/java/util/function/DoubleBinaryOperator.java >> src/share/classes/java/util/function/DoubleBlock.java >> src/share/classes/java/util/function/DoubleFunction.java >> src/share/classes/java/util/function/DoubleSupplier.java >> src/share/classes/java/util/function/DoubleUnaryOperator.java >> src/share/classes/java/util/function/Function.java >> src/share/classes/java/util/function/IntBinaryOperator.java >> src/share/classes/java/util/function/IntBlock.java >> src/share/classes/java/util/function/IntFunction.java >> src/share/classes/java/util/function/IntSupplier.java >> src/share/classes/java/util/function/IntUnaryOperator.java >> src/share/classes/java/util/function/LongBinaryOperator.java >> src/share/classes/java/util/function/LongBlock.java >> src/share/classes/java/util/function/LongFunction.java >> src/share/classes/java/util/function/LongSupplier.java >> src/share/classes/java/util/function/LongUnaryOperator.java >> src/share/classes/java/util/function/Predicate.java >> src/share/classes/java/util/function/Supplier.java >> src/share/classes/java/util/function/UnaryOperator.java >> src/share/classes/java/util/logging/Filter.java >> src/share/classes/java/util/prefs/PreferenceChangeListener.java >> >> Webrev: >> http://cr.openjdk.java.net/~darcy/8005623.0/ >> >> This review is both to cover the addition of @FunctionalInterface to the types above and also to query if the annotation should be included in any of the other types below under the same bug. The sub-areas I have not annotated yet include: >> >> * xml >> * jdbc >> * JSR 310 >> * JNDI >> * RMI >> * Beans >> * networking >> * JMX/management >> * java.util.concurrent >> >> The annotation can be added in these areas separately later as well; if that is done, I recommend sub-tasks of JDK-8005297 "Add FunctionalInterface support to the platform" be used to track the work. >> >> I'll separately be sending email to the security and awt/swing teams about the functional interface candidates in their areas. >> >> Thanks, >> >> -Joe >> >> misc core >> ======== >> >> jdk/src/share/classes/java/lang/annotation/Annotation.java:40: Note: Candidate functional interface >> public interface Annotation { >> ^ >> jdk/src/share/classes/java/io/ObjectInputValidation.java:38: Note: Candidate functional interface >> public interface ObjectInputValidation { >> ^ >> jdk/src/share/classes/java/util/ResourceBundle.java:690: Note: Candidate functional interface >> private static interface CacheKeyReference { >> ^ >> jdk/src/share/classes/java/util/spi/ResourceBundleControlProvider.java:51: Note: Candidate functional interface >> public interface ResourceBundleControlProvider { >> ^ >> jdk/src/share/classes/java/util/Formattable.java:119: Note: Candidate functional interface >> public interface Formattable { >> ^ >> jdk/src/share/classes/java/util/Observer.java:35: Note: Candidate functional interface >> public interface Observer { >> ^ >> jdk/src/share/classes/java/nio/file/WatchEvent.java:76: Note: Candidate functional interface >> public static interface Modifier { >> ^ >> jdk/src/share/classes/java/nio/file/attribute/AttributeView.java:38: Note: Candidate functional interface >> public interface AttributeView { >> ^ >> jdk/src/share/classes/java/nio/file/attribute/FileStoreAttributeView.java:35: Note: Candidate functional interface >> public interface FileStoreAttributeView >> ^ >> jdk/src/share/classes/java/nio/file/attribute/FileAttributeView.java:39: Note: Candidate functional interface >> public interface FileAttributeView >> ^ >> jdk/src/share/classes/java/nio/file/attribute/UserPrincipal.java:54: Note: Candidate functional interface >> public interface UserPrincipal extends Principal { } >> ^ >> jdk/src/share/classes/java/nio/file/attribute/GroupPrincipal.java:42: Note: Candidate functional interface >> public interface GroupPrincipal extends UserPrincipal { } >> ^ >> jdk/src/share/classes/java/nio/file/PathMatcher.java:38: Note: Candidate functional interface >> public interface PathMatcher { >> ^ >> jdk/src/share/classes/java/nio/file/DirectoryStream.java:133: Note: Candidate functional interface >> public static interface Filter { >> ^ >> jdk/src/share/classes/javax/accessibility/Accessible.java:39: Note: Candidate functional interface >> public interface Accessible { >> ^ >> >> jdk/src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheData.java:37: Note: Candidate functional interface >> public interface ApacheData extends Data { >> >> reflection >> ============= >> >> jdk/src/share/classes/java/lang/reflect/GenericArrayType.java:33: Note: Candidate functional interface >> public interface GenericArrayType extends Type { >> ^ >> >> jdk/src/share/classes/java/lang/reflect/GenericDeclaration.java:33: Note: Candidate functional interface >> public interface GenericDeclaration { >> ^ >> jdk/src/share/classes/java/lang/reflect/InvocationHandler.java:41: Note: Candidate functional interface >> public interface InvocationHandler { >> ^ >> >> >> xml >> ===== >> >> jdk/src/share/classes/javax/xml/crypto/KeySelectorResult.java:46: Note: Candidate functional interface >> public interface KeySelectorResult { >> ^ >> jdk/src/share/classes/javax/xml/crypto/URIDereferencer.java:55: Note: Candidate functional interface >> public interface URIDereferencer { >> ^ >> jdk/src/share/classes/javax/xml/crypto/NodeSetData.java:42: Note: Candidate functional interface >> public interface NodeSetData extends Data { >> ^ >> jdk/src/share/classes/javax/xml/crypto/XMLStructure.java:39: Note: Candidate functional interface >> public interface XMLStructure { >> ^ >> >> JDBC - Assuming this will be handled separately under JDBC maintenance >> ====== >> >> jdk/src/share/classes/java/sql/RowId.java:63: Note: Candidate functional interface >> public interface RowId { >> ^ >> jdk/src/share/classes/javax/sql/RowSetReader.java:41: Note: Candidate functional interface >> public interface RowSetReader { >> ^ >> jdk/src/share/classes/javax/sql/RowSetWriter.java:49: Note: Candidate functional interface >> public interface RowSetWriter { >> ^ >> JSR 310 - Assuming this will be handled separately under JSR 310 evolution >> ========= >> >> jdk/src/share/classes/java/time/temporal/TemporalAdjuster.java:96: Note: Candidate functional interface >> public interface TemporalAdjuster { >> ^ >> jdk/src/share/classes/java/time/temporal/TemporalQuery.java:101: Note: Candidate functional interface >> public interface TemporalQuery { >> ^ >> jdk/src/share/classes/java/time/temporal/TemporalAdder.java:95: Note: Candidate functional interface >> public interface TemporalAdder { >> ^ >> jdk/src/share/classes/java/time/temporal/TemporalSubtractor.java:95: Note: Candidate functional interface >> public interface TemporalSubtractor { >> ^ >> >> JNDI >> ====== >> >> jdk/src/share/classes/javax/naming/event/NamingListener.java:57: Note: Candidate functional interface >> public interface NamingListener extends java.util.EventListener { >> ^ >> jdk/src/share/classes/javax/naming/ldap/HasControls.java:60: Note: Candidate functional interface >> public interface HasControls { >> ^ >> jdk/src/share/classes/javax/naming/Referenceable.java:49: Note: Candidate functional interface >> public interface Referenceable { >> ^ >> jdk/src/share/classes/javax/naming/NameParser.java:45: Note: Candidate functional interface >> public interface NameParser { >> ^ >> jdk/src/share/classes/javax/naming/spi/StateFactory.java:80: Note: Candidate functional interface >> public interface StateFactory { >> ^ >> jdk/src/share/classes/javax/naming/spi/ObjectFactoryBuilder.java:57: Note: Candidate functional interface >> public interface ObjectFactoryBuilder { >> ^ >> jdk/src/share/classes/javax/naming/spi/ObjectFactory.java:70: Note: Candidate functional interface >> public interface ObjectFactory { >> ^ >> jdk/src/share/classes/javax/naming/spi/InitialContextFactoryBuilder.java:54: Note: Candidate functional interface >> public interface InitialContextFactoryBuilder { >> ^ >> jdk/src/share/classes/javax/naming/spi/InitialContextFactory.java:53: Note: Candidate functional interface >> public interface InitialContextFactory { >> ^ >> >> RMI >> ===== >> >> jdk/src/share/classes/java/rmi/activation/ActivationInstantiator.java:42: Note: Candidate functional interface >> public interface ActivationInstantiator extends Remote { >> ^ >> jdk/src/share/classes/java/rmi/activation/Activator.java:64: Note: Candidate functional interface >> public interface Activator extends Remote { >> ^ >> jdk/src/share/classes/java/rmi/server/RMIServerSocketFactory.java:61: Note: Candidate functional interface >> public interface RMIServerSocketFactory { >> ^ >> jdk/src/share/classes/java/rmi/server/RMIFailureHandler.java:40: Note: Candidate functional interface >> public interface RMIFailureHandler { >> ^ >> jdk/src/share/classes/java/rmi/server/RMIClientSocketFactory.java:62: Note: Candidate functional interface >> public interface RMIClientSocketFactory { >> ^ >> jdk/src/share/classes/java/rmi/server/Unreferenced.java:37: Note: Candidate functional interface >> public interface Unreferenced { >> ^ >> Beans >> ======== >> >> jdk/src/share/classes/java/beans/PropertyChangeListener.java:34: Note: Candidate functional interface >> public interface PropertyChangeListener extends java.util.EventListener { >> ^ >> jdk/src/share/classes/java/beans/VetoableChangeListener.java:33: Note: Candidate functional interface >> public interface VetoableChangeListener extends java.util.EventListener { >> ^ >> jdk/src/share/classes/java/beans/ExceptionListener.java:34: Note: Candidate functional interface >> public interface ExceptionListener { >> ^ >> jdk/src/share/classes/java/beans/beancontext/BeanContextServiceRevokedListener.java:37: Note: Candidate functional interface >> public interface BeanContextServiceRevokedListener extends EventListener { >> ^ >> jdk/src/share/classes/java/beans/beancontext/BeanContextProxy.java:76: Note: Candidate functional interface >> public interface BeanContextProxy { >> ^ >> jdk/src/share/classes/java/beans/beancontext/BeanContextContainerProxy.java:43: Note: Candidate functional interface >> public interface BeanContextContainerProxy { >> ^ >> jdk/src/share/classes/java/beans/beancontext/BeanContextChildComponentProxy.java:44: Note: Candidate functional interface >> public interface BeanContextChildComponentProxy { >> ^ >> networking >> ========== >> >> jdk/src/share/classes/java/net/ContentHandlerFactory.java:41: Note: Candidate functional interface >> public interface ContentHandlerFactory { >> ^ >> jdk/src/share/classes/java/net/HttpCookie.java:855: Note: Candidate functional interface >> static interface CookieAttributeAssignor { >> ^ >> jdk/src/share/classes/java/net/SocketImplFactory.java:40: Note: Candidate functional interface >> interface SocketImplFactory { >> ^ >> jdk/src/share/classes/java/net/CookiePolicy.java:38: Note: Candidate functional interface >> public interface CookiePolicy { >> ^ >> jdk/src/share/classes/java/net/URLStreamHandlerFactory.java:40: Note: Candidate functional interface >> public interface URLStreamHandlerFactory { >> ^ >> jdk/src/share/classes/java/net/DatagramSocketImplFactory.java:38: Note: Candidate functional interface >> interface DatagramSocketImplFactory { >> ^ >> jdk/src/share/classes/java/net/FileNameMap.java:35: Note: Candidate functional interface >> public interface FileNameMap { >> ^ >> jdk/src/share/classes/java/net/ProtocolFamily.java:34: Note: Candidate functional interface >> public interface ProtocolFamily { >> ^ >> jdk/src/share/classes/javax/net/ssl/HostnameVerifier.java:46: Note: Candidate functional interface >> public interface HostnameVerifier { >> ^ >> jdk/src/share/classes/javax/net/ssl/HandshakeCompletedListener.java:44: Note: Candidate functional interface >> public interface HandshakeCompletedListener extends EventListener >> ^ >> jmx/management >> ================ >> >> jdk/src/share/classes/java/lang/management/PlatformManagedObject.java:52: Note: Candidate functional interface >> public interface PlatformManagedObject { >> ^ >> jdk/src/share/classes/java/lang/management/PlatformComponent.java:279: Note: Candidate functional interface >> interface MXBeanFetcher { >> ^ >> jdk/src/share/classes/java/lang/instrument/ClassFileTransformer.java:50: Note: Candidate functional interface >> public interface ClassFileTransformer { >> ^ >> jdk/src/share/classes/javax/management/openmbean/CompositeDataView.java:109: Note: Candidate functional interface >> public interface CompositeDataView { >> ^ >> jdk/src/share/classes/javax/management/NotificationFilter.java:35: Note: Candidate functional interface >> public interface NotificationFilter extends java.io.Serializable { >> ^ >> jdk/src/share/classes/javax/management/remote/JMXAddressable.java:44: Note: Candidate functional interface >> public interface JMXAddressable { >> ^ >> jdk/src/share/classes/javax/management/remote/JMXAuthenticator.java:52: Note: Candidate functional interface >> public interface JMXAuthenticator { >> ^ >> jdk/src/share/classes/javax/management/remote/JMXConnectorServerProvider.java:42: Note: Candidate functional interface >> public interface JMXConnectorServerProvider { >> ^ >> jdk/src/share/classes/javax/management/remote/JMXConnectorProvider.java:41: Note: Candidate functional interface >> public interface JMXConnectorProvider { >> ^ >> jdk/src/share/classes/javax/management/NotificationListener.java:34: Note: Candidate functional interface >> public interface NotificationListener extends java.util.EventListener { >> ^ >> jdk/src/share/classes/javax/management/DescriptorRead.java:33: Note: Candidate functional interface >> public interface DescriptorRead { >> ^ >> concurrent - Assume this will be done first upstream in Doug's repos >> ============ >> >> jdk/src/share/classes/java/util/concurrent/ThreadFactory.java:58: Note: Candidate functional interface >> public interface ThreadFactory { >> ^ >> jdk/src/share/classes/java/util/concurrent/ForkJoinPool.java:545: Note: Candidate functional interface >> public static interface ForkJoinWorkerThreadFactory { >> ^ >> jdk/src/share/classes/java/util/concurrent/RejectedExecutionHandler.java:44: Note: Candidate functional interface >> public interface RejectedExecutionHandler { >> ^ >> jdk/src/share/classes/java/util/concurrent/Callable.java:57: Note: Candidate functional interface >> public interface Callable { >> ^ >> jdk/src/share/classes/java/util/concurrent/Executor.java:128: Note: Candidate functional interface >> public interface Executor { > From john.zavgren at oracle.com Tue Feb 5 23:49:39 2013 From: john.zavgren at oracle.com (John Zavgren) Date: Tue, 5 Feb 2013 15:49:39 -0800 (PST) Subject: RFR JDK-8007609 Message-ID: <3d9879ec-77e4-42f7-bc90-578d7c488054@default> Greetings: I modified the code in src/windows/native/java/io/WinNTFileSystem_md.c so that it checks the return value of realloc() and frees memory when there is an error. The webrev image of this change is visible at: http://cr.openjdk.java.net/~jzavgren/8007609/webrev.01/ Thanks! John Zavgren From Lance.Andersen at oracle.com Tue Feb 5 23:54:22 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 5 Feb 2013 18:54:22 -0500 Subject: review request: 8006505 additional updates for JSR 310 In-Reply-To: <511190B7.2030703@CoSoCo.de> References: <006D1601-CF80-476A-BC8A-C6B6B226C36F@oracle.com> <511190B7.2030703@CoSoCo.de> Message-ID: <24671E0D-2571-49A5-9873-B2471414096C@oracle.com> Hi Ulf, On Feb 5, 2013, at 6:07 PM, Ulf Zibis wrote: > Am 05.02.2013 15:40, schrieb Lance Andersen - Oracle: >> HI, >> >> >> This is a review request for http://cr.openjdk.java.net/~lancea/8006505/webrev.00/ which adds support to SQLInput/Ouput (used for UDTs) to have generic methods for types allowing support for JSR 310. >> > > Hi Lance, > > I would set the exception message to "method not implemented" instead "read/writeObject not implemented". > the latter looks more like a parameter, which is not present. I can change that text and will do so before i put back. > > Have you observed internal review ID of 2426775? I have not seen this come through as of yet but will let you know when I do. Best Lance > > -Ulf > -------------- 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 Ulf.Zibis at CoSoCo.de Wed Feb 6 00:22:27 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Wed, 06 Feb 2013 01:22:27 +0100 Subject: review request: 8006505 additional updates for JSR 310 In-Reply-To: <24671E0D-2571-49A5-9873-B2471414096C@oracle.com> References: <006D1601-CF80-476A-BC8A-C6B6B226C36F@oracle.com> <511190B7.2030703@CoSoCo.de> <24671E0D-2571-49A5-9873-B2471414096C@oracle.com> Message-ID: <5111A243.1070207@CoSoCo.de> Am 06.02.2013 00:54, schrieb Lance Andersen - Oracle: > > I can change that text and will do so before i put back. fine! >> Have you observed internal review ID of 2426775? > I have not seen this come through as of yet but will let you know when I do. It was from 16.01.2013 15:19 +0100 -Ulf From david.holmes at oracle.com Wed Feb 6 01:53:40 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 Feb 2013 11:53:40 +1000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <51111228.5010707@oracle.com> References: <510BD3E6.1090103@oracle.com> <5110A4EC.1050907@oracle.com> <51111228.5010707@oracle.com> Message-ID: <5111B7A4.8040902@oracle.com> Hi Chris, I don't speak fluent sh but ... 204 # Terminate with exit 0 only if all subprocesses were successful 205 ec=0 206 if [ -d ${tmp} ]; then 207 for rc in `ls ${tmp}/*.pid.rc` ; do I don't think you need to subshell an invocation of ls, simply do for rc in "${tmp}/*.pid.rc" ; do 208 exit_code=`cat ${rc} | tr -d ' \n\r'` 209 if [ "${exit_code}" != "0" ] ; then 210 echo "WARNING: ${rc} exited abnormally." Not sure printing ${rc} will be very informative there ?? 211 ec=1 Is there a "break" we can add here? --- In get_source.sh # Get clones of all nested repositories ! sh ./common/bin/hgforest.sh clone "$@" || exit 1 # Update all existing repositories to the latest sources sh ./common/bin/hgforest.sh pull -u don't we want "|| exit 1" for the pull case as well? Thanks, David On 6/02/2013 12:07 AM, Chris Hegarty wrote: > On 02/05/2013 06:21 AM, David Holmes wrote: >> Chris, >> >> When these failures occur does the failure get reflected in an error >> exit code? > > Not currently, good point. > >> I'm seeing hudson builds merilly buildinh OpenJDK instead of Oracle JDK >> because the closed repos were skipped due to this bug :( > > This is what I am seeing too, and the reason I proposed a patch to > resolve it. > > Updated webrev; > http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ > > 1) now checks, and returns, appropriate error code, so that higher > level scripts can determine if it completed successfully > 2) Added diagnostic error message to help identify potential future > problems if a nested repo is blocked for too long > > -Chris. > >> >> David >> >> On 2/02/2013 12:40 AM, Chris Hegarty wrote: >>> [ to build-dev and core-libs-dev, expect reviewer from either, but will >>> integrate through jdk8/tl ] >>> >>> This issue is mainly of interest to Oracle engineers, but it effects the >>> public hgforest script. >>> >>> When hgforest.sh is run with an addition argument to specify a closed >>> server, there is a problem/race between the creation of the directories >>> to hold nested repositories and the clone itself. These directories need >>> to be created before the clone command is executed, otherwise it will >>> fail, as below. >>> >>> The trivial fix is to back off these nested repos until their containing >>> directory exists. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >>> >>> sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log >>> # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed >>> jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed >>> hotspot/test/closed deploy install sponsors pubs >>> >>> Waiting 5 secs before spawning next background command. >>> Waiting 5 secs before spawning next background command. >>> Waiting 5 secs before spawning next background command. >>> jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed >>> jdk/src/closed: abort: No such file or directory: jdk/src/closed >>> jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed >>> jdk/make/closed: abort: No such file or directory: jdk/make/closed >>> Waiting 5 secs before spawning next background command. >>> .... >>> >>> >>> -Chris. From alex.buckley at oracle.com Wed Feb 6 02:14:44 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 05 Feb 2013 18:14:44 -0800 Subject: JDK 8 code review request for 8005832: Remove java.lang.annotation.{ContainedBy, ContainerFor} annotation types In-Reply-To: <510AD05C.6030502@oracle.com> References: <510AADBB.8020805@oracle.com> <510AD05C.6030502@oracle.com> Message-ID: <5111BC94.4050505@oracle.com> This changeset was committed on 1/31 despite a) having inaccurate javadoc and b) reducing even further the clarity of a probably unnecessary type in the java.lang hierarchy. Again, I request that the nature of when core reflection throws AnnotationFormatError be raised on enhanced-metadata-spec-discuss, since it needs to correspond with compile-time constraints. Alex On 1/31/2013 12:13 PM, Alex Buckley wrote: > On 1/31/2013 9:45 AM, Joe Darcy wrote: >> With Joel's recent push of 8005712, the repeating annotations feature >> has now transitioned from using the pair of annotation types >> {ContainedBy, ContainerFor} to the single Repeatable annotation. >> >> Please review the removal of the pair of old types: >> >> 8005832: Remove java.lang.annotation.{ContainedBy, ContainerFor} >> annotation types >> http://cr.openjdk.java.net/~darcy/8005832.0/ > > The type-level javadoc for InvalidContainerAnnotationError is: > > "Thrown to indicate that an annotation type expected to act as a > container for another annotation type by virture of an @Repeatable > annotation, does not act as a container." > > An _annotation type_ never acts as a container; an annotation acts as a > container. Also, it is preferable to avoid @Repeatable and instead defer > to the JLS 9.6 concept of "repeatable annotation type". > > To be honest, I've never understood how InvalidContainerAnnotationError > differs from AnnotationFormatError. The spec has precisely one paragraph > calling for an AnnotationFormatError; if the implementation broke it > down into multiple cases, that should be added back to the spec and the > AFE subtype documented. (Please do that on > enhanced-metadata-spec-discuss, not a -dev list.) > > Alex > > From henry.jen at oracle.com Wed Feb 6 03:51:38 2013 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 05 Feb 2013 19:51:38 -0800 Subject: CFR - updated 8001667: Comparator combinators and extension methods Message-ID: <5111D34A.4020309@oracle.com> Hi, This is an update on previous reviewed version, there are two new method introduced for Comparators to convert a Comparator into a BinaryOperator and corresponding test cases. As there is one new class, java.util.Comparators for 8001667, so we need to have makefile change, thus involve build-infra. Comparators.java public static BinaryOperator lesserOf(Comparator comparator); public static BinaryOperator greaterOf(Comparator comparator); [1] http://cr.openjdk.java.net/~henryjen/ccc/8001667.3/webrev Cheers, Henry From jonathan.gibbons at oracle.com Wed Feb 6 05:56:24 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 06 Feb 2013 05:56:24 +0000 Subject: hg: jdk8/tl/langtools: 8007485: test creates .class files in the test/ directory Message-ID: <20130206055629.E9CCE47879@hg.openjdk.java.net> Changeset: de932285124c Author: jjg Date: 2013-02-05 21:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/de932285124c 8007485: test creates .class files in the test/ directory Reviewed-by: mcimadamore ! test/tools/javac/api/8007344/Test.java From erik.joelsson at oracle.com Wed Feb 6 08:31:01 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 06 Feb 2013 09:31:01 +0100 Subject: CFR - updated 8001667: Comparator combinators and extension methods In-Reply-To: <5111D34A.4020309@oracle.com> References: <5111D34A.4020309@oracle.com> Message-ID: <511214C5.5040300@oracle.com> The build change looks fine. The new build will not need any changes. /Erik On 2013-02-06 04:51, Henry Jen wrote: > Hi, > > This is an update on previous reviewed version, there are two new method > introduced for Comparators to convert a Comparator into a BinaryOperator > and corresponding test cases. > > As there is one new class, java.util.Comparators for 8001667, so we need > to have makefile change, thus involve build-infra. > > Comparators.java > > public static BinaryOperator lesserOf(Comparator > comparator); > public static BinaryOperator greaterOf(Comparator > comparator); > > > [1] http://cr.openjdk.java.net/~henryjen/ccc/8001667.3/webrev > > Cheers, > Henry From david.holmes at oracle.com Wed Feb 6 08:42:29 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 Feb 2013 18:42:29 +1000 Subject: JDK 8 code review request for 8005623: Retrofit FunctionalInterface annotations to core platform interfaces In-Reply-To: <511184BF.9040202@oracle.com> References: <511184BF.9040202@oracle.com> Message-ID: <51121775.7030701@oracle.com> I don't think Thread belongs in there. ;-) David On 6/02/2013 8:16 AM, Joe Darcy wrote: > Hello, > > As a follow-up to adding the FunctionalInterface annotation type to the > platform, the time has come to annotate JDK classes with the annotation. > > I ran an annotation processor over the sources in the jdk repo to look > for candidates to be marked as FunctionalInterfaces and for a first cut > I have added the annotation to 34 types, including all of the types in > java.util.function: > > src/share/classes/java/io/Closeable.java > src/share/classes/java/io/FileFilter.java > src/share/classes/java/io/FilenameFilter.java > src/share/classes/java/io/Flushable.java > src/share/classes/java/lang/AutoCloseable.java > src/share/classes/java/lang/Comparable.java > src/share/classes/java/lang/Iterable.java > src/share/classes/java/lang/Readable.java > src/share/classes/java/lang/Runnable.java > src/share/classes/java/lang/Thread.java > src/share/classes/java/util/Comparator.java > src/share/classes/java/util/function/BinaryOperator.java > src/share/classes/java/util/function/Block.java > src/share/classes/java/util/function/DoubleBinaryOperator.java > src/share/classes/java/util/function/DoubleBlock.java > src/share/classes/java/util/function/DoubleFunction.java > src/share/classes/java/util/function/DoubleSupplier.java > src/share/classes/java/util/function/DoubleUnaryOperator.java > src/share/classes/java/util/function/Function.java > src/share/classes/java/util/function/IntBinaryOperator.java > src/share/classes/java/util/function/IntBlock.java > src/share/classes/java/util/function/IntFunction.java > src/share/classes/java/util/function/IntSupplier.java > src/share/classes/java/util/function/IntUnaryOperator.java > src/share/classes/java/util/function/LongBinaryOperator.java > src/share/classes/java/util/function/LongBlock.java > src/share/classes/java/util/function/LongFunction.java > src/share/classes/java/util/function/LongSupplier.java > src/share/classes/java/util/function/LongUnaryOperator.java > src/share/classes/java/util/function/Predicate.java > src/share/classes/java/util/function/Supplier.java > src/share/classes/java/util/function/UnaryOperator.java > src/share/classes/java/util/logging/Filter.java > src/share/classes/java/util/prefs/PreferenceChangeListener.java > > Webrev: > http://cr.openjdk.java.net/~darcy/8005623.0/ > > This review is both to cover the addition of @FunctionalInterface to the > types above and also to query if the annotation should be included in > any of the other types below under the same bug. The sub-areas I have > not annotated yet include: > > * xml > * jdbc > * JSR 310 > * JNDI > * RMI > * Beans > * networking > * JMX/management > * java.util.concurrent > > The annotation can be added in these areas separately later as well; if > that is done, I recommend sub-tasks of JDK-8005297 "Add > FunctionalInterface support to the platform" be used to track the work. > > I'll separately be sending email to the security and awt/swing teams > about the functional interface candidates in their areas. > > Thanks, > > -Joe > > misc core > ======== > > jdk/src/share/classes/java/lang/annotation/Annotation.java:40: Note: > Candidate functional interface > public interface Annotation { > ^ > jdk/src/share/classes/java/io/ObjectInputValidation.java:38: Note: > Candidate functional interface > public interface ObjectInputValidation { > ^ > jdk/src/share/classes/java/util/ResourceBundle.java:690: Note: Candidate > functional interface > private static interface CacheKeyReference { > ^ > jdk/src/share/classes/java/util/spi/ResourceBundleControlProvider.java:51: > Note: Candidate functional interface > public interface ResourceBundleControlProvider { > ^ > jdk/src/share/classes/java/util/Formattable.java:119: Note: Candidate > functional interface > public interface Formattable { > ^ > jdk/src/share/classes/java/util/Observer.java:35: Note: Candidate > functional interface > public interface Observer { > ^ > jdk/src/share/classes/java/nio/file/WatchEvent.java:76: Note: Candidate > functional interface > public static interface Modifier { > ^ > jdk/src/share/classes/java/nio/file/attribute/AttributeView.java:38: > Note: Candidate functional interface > public interface AttributeView { > ^ > jdk/src/share/classes/java/nio/file/attribute/FileStoreAttributeView.java:35: > Note: Candidate functional interface > public interface FileStoreAttributeView > ^ > jdk/src/share/classes/java/nio/file/attribute/FileAttributeView.java:39: > Note: Candidate functional interface > public interface FileAttributeView > ^ > jdk/src/share/classes/java/nio/file/attribute/UserPrincipal.java:54: > Note: Candidate functional interface > public interface UserPrincipal extends Principal { } > ^ > jdk/src/share/classes/java/nio/file/attribute/GroupPrincipal.java:42: > Note: Candidate functional interface > public interface GroupPrincipal extends UserPrincipal { } > ^ > jdk/src/share/classes/java/nio/file/PathMatcher.java:38: Note: Candidate > functional interface > public interface PathMatcher { > ^ > jdk/src/share/classes/java/nio/file/DirectoryStream.java:133: Note: > Candidate functional interface > public static interface Filter { > ^ > jdk/src/share/classes/javax/accessibility/Accessible.java:39: Note: > Candidate functional interface > public interface Accessible { > ^ > > jdk/src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheData.java:37: > Note: Candidate functional interface > public interface ApacheData extends Data { > > reflection > ============= > > jdk/src/share/classes/java/lang/reflect/GenericArrayType.java:33: Note: > Candidate functional interface > public interface GenericArrayType extends Type { > ^ > > jdk/src/share/classes/java/lang/reflect/GenericDeclaration.java:33: > Note: Candidate functional interface > public interface GenericDeclaration { > ^ > jdk/src/share/classes/java/lang/reflect/InvocationHandler.java:41: Note: > Candidate functional interface > public interface InvocationHandler { > ^ > > > xml > ===== > > jdk/src/share/classes/javax/xml/crypto/KeySelectorResult.java:46: Note: > Candidate functional interface > public interface KeySelectorResult { > ^ > jdk/src/share/classes/javax/xml/crypto/URIDereferencer.java:55: Note: > Candidate functional interface > public interface URIDereferencer { > ^ > jdk/src/share/classes/javax/xml/crypto/NodeSetData.java:42: Note: > Candidate functional interface > public interface NodeSetData extends Data { > ^ > jdk/src/share/classes/javax/xml/crypto/XMLStructure.java:39: Note: > Candidate functional interface > public interface XMLStructure { > ^ > > JDBC - Assuming this will be handled separately under JDBC maintenance > ====== > > jdk/src/share/classes/java/sql/RowId.java:63: Note: Candidate functional > interface > public interface RowId { > ^ > jdk/src/share/classes/javax/sql/RowSetReader.java:41: Note: Candidate > functional interface > public interface RowSetReader { > ^ > jdk/src/share/classes/javax/sql/RowSetWriter.java:49: Note: Candidate > functional interface > public interface RowSetWriter { > ^ > JSR 310 - Assuming this will be handled separately under JSR 310 evolution > ========= > > jdk/src/share/classes/java/time/temporal/TemporalAdjuster.java:96: Note: > Candidate functional interface > public interface TemporalAdjuster { > ^ > jdk/src/share/classes/java/time/temporal/TemporalQuery.java:101: Note: > Candidate functional interface > public interface TemporalQuery { > ^ > jdk/src/share/classes/java/time/temporal/TemporalAdder.java:95: Note: > Candidate functional interface > public interface TemporalAdder { > ^ > jdk/src/share/classes/java/time/temporal/TemporalSubtractor.java:95: > Note: Candidate functional interface > public interface TemporalSubtractor { > ^ > > JNDI > ====== > > jdk/src/share/classes/javax/naming/event/NamingListener.java:57: Note: > Candidate functional interface > public interface NamingListener extends java.util.EventListener { > ^ > jdk/src/share/classes/javax/naming/ldap/HasControls.java:60: Note: > Candidate functional interface > public interface HasControls { > ^ > jdk/src/share/classes/javax/naming/Referenceable.java:49: Note: > Candidate functional interface > public interface Referenceable { > ^ > jdk/src/share/classes/javax/naming/NameParser.java:45: Note: Candidate > functional interface > public interface NameParser { > ^ > jdk/src/share/classes/javax/naming/spi/StateFactory.java:80: Note: > Candidate functional interface > public interface StateFactory { > ^ > jdk/src/share/classes/javax/naming/spi/ObjectFactoryBuilder.java:57: > Note: Candidate functional interface > public interface ObjectFactoryBuilder { > ^ > jdk/src/share/classes/javax/naming/spi/ObjectFactory.java:70: Note: > Candidate functional interface > public interface ObjectFactory { > ^ > jdk/src/share/classes/javax/naming/spi/InitialContextFactoryBuilder.java:54: > Note: Candidate functional interface > public interface InitialContextFactoryBuilder { > ^ > jdk/src/share/classes/javax/naming/spi/InitialContextFactory.java:53: > Note: Candidate functional interface > public interface InitialContextFactory { > ^ > > RMI > ===== > > jdk/src/share/classes/java/rmi/activation/ActivationInstantiator.java:42: Note: > Candidate functional interface > public interface ActivationInstantiator extends Remote { > ^ > jdk/src/share/classes/java/rmi/activation/Activator.java:64: Note: > Candidate functional interface > public interface Activator extends Remote { > ^ > jdk/src/share/classes/java/rmi/server/RMIServerSocketFactory.java:61: > Note: Candidate functional interface > public interface RMIServerSocketFactory { > ^ > jdk/src/share/classes/java/rmi/server/RMIFailureHandler.java:40: Note: > Candidate functional interface > public interface RMIFailureHandler { > ^ > jdk/src/share/classes/java/rmi/server/RMIClientSocketFactory.java:62: > Note: Candidate functional interface > public interface RMIClientSocketFactory { > ^ > jdk/src/share/classes/java/rmi/server/Unreferenced.java:37: Note: > Candidate functional interface > public interface Unreferenced { > ^ > Beans > ======== > > jdk/src/share/classes/java/beans/PropertyChangeListener.java:34: Note: > Candidate functional interface > public interface PropertyChangeListener extends java.util.EventListener { > ^ > jdk/src/share/classes/java/beans/VetoableChangeListener.java:33: Note: > Candidate functional interface > public interface VetoableChangeListener extends java.util.EventListener { > ^ > jdk/src/share/classes/java/beans/ExceptionListener.java:34: Note: > Candidate functional interface > public interface ExceptionListener { > ^ > jdk/src/share/classes/java/beans/beancontext/BeanContextServiceRevokedListener.java:37: > Note: Candidate functional interface > public interface BeanContextServiceRevokedListener extends EventListener { > ^ > jdk/src/share/classes/java/beans/beancontext/BeanContextProxy.java:76: > Note: Candidate functional interface > public interface BeanContextProxy { > ^ > jdk/src/share/classes/java/beans/beancontext/BeanContextContainerProxy.java:43: > Note: Candidate functional interface > public interface BeanContextContainerProxy { > ^ > jdk/src/share/classes/java/beans/beancontext/BeanContextChildComponentProxy.java:44: > Note: Candidate functional interface > public interface BeanContextChildComponentProxy { > ^ > networking > ========== > > jdk/src/share/classes/java/net/ContentHandlerFactory.java:41: Note: > Candidate functional interface > public interface ContentHandlerFactory { > ^ > jdk/src/share/classes/java/net/HttpCookie.java:855: Note: Candidate > functional interface > static interface CookieAttributeAssignor { > ^ > jdk/src/share/classes/java/net/SocketImplFactory.java:40: Note: > Candidate functional interface > interface SocketImplFactory { > ^ > jdk/src/share/classes/java/net/CookiePolicy.java:38: Note: Candidate > functional interface > public interface CookiePolicy { > ^ > jdk/src/share/classes/java/net/URLStreamHandlerFactory.java:40: Note: > Candidate functional interface > public interface URLStreamHandlerFactory { > ^ > jdk/src/share/classes/java/net/DatagramSocketImplFactory.java:38: Note: > Candidate functional interface > interface DatagramSocketImplFactory { > ^ > jdk/src/share/classes/java/net/FileNameMap.java:35: Note: Candidate > functional interface > public interface FileNameMap { > ^ > jdk/src/share/classes/java/net/ProtocolFamily.java:34: Note: Candidate > functional interface > public interface ProtocolFamily { > ^ > jdk/src/share/classes/javax/net/ssl/HostnameVerifier.java:46: Note: > Candidate functional interface > public interface HostnameVerifier { > ^ > jdk/src/share/classes/javax/net/ssl/HandshakeCompletedListener.java:44: > Note: Candidate functional interface > public interface HandshakeCompletedListener extends EventListener > ^ > jmx/management > ================ > > jdk/src/share/classes/java/lang/management/PlatformManagedObject.java:52: Note: > Candidate functional interface > public interface PlatformManagedObject { > ^ > jdk/src/share/classes/java/lang/management/PlatformComponent.java:279: > Note: Candidate functional interface > interface MXBeanFetcher { > ^ > jdk/src/share/classes/java/lang/instrument/ClassFileTransformer.java:50: > Note: Candidate functional interface > public interface ClassFileTransformer { > ^ > jdk/src/share/classes/javax/management/openmbean/CompositeDataView.java:109: > Note: Candidate functional interface > public interface CompositeDataView { > ^ > jdk/src/share/classes/javax/management/NotificationFilter.java:35: Note: > Candidate functional interface > public interface NotificationFilter extends java.io.Serializable { > ^ > jdk/src/share/classes/javax/management/remote/JMXAddressable.java:44: > Note: Candidate functional interface > public interface JMXAddressable { > ^ > jdk/src/share/classes/javax/management/remote/JMXAuthenticator.java:52: > Note: Candidate functional interface > public interface JMXAuthenticator { > ^ > jdk/src/share/classes/javax/management/remote/JMXConnectorServerProvider.java:42: > Note: Candidate functional interface > public interface JMXConnectorServerProvider { > ^ > jdk/src/share/classes/javax/management/remote/JMXConnectorProvider.java:41: > Note: Candidate functional interface > public interface JMXConnectorProvider { > ^ > jdk/src/share/classes/javax/management/NotificationListener.java:34: > Note: Candidate functional interface > public interface NotificationListener extends java.util.EventListener { > ^ > jdk/src/share/classes/javax/management/DescriptorRead.java:33: Note: > Candidate functional interface > public interface DescriptorRead { > ^ > concurrent - Assume this will be done first upstream in Doug's repos > ============ > > jdk/src/share/classes/java/util/concurrent/ThreadFactory.java:58: Note: > Candidate functional interface > public interface ThreadFactory { > ^ > jdk/src/share/classes/java/util/concurrent/ForkJoinPool.java:545: Note: > Candidate functional interface > public static interface ForkJoinWorkerThreadFactory { > ^ > jdk/src/share/classes/java/util/concurrent/RejectedExecutionHandler.java:44: > Note: Candidate functional interface > public interface RejectedExecutionHandler { > ^ > jdk/src/share/classes/java/util/concurrent/Callable.java:57: Note: > Candidate functional interface > public interface Callable { > ^ > jdk/src/share/classes/java/util/concurrent/Executor.java:128: Note: > Candidate functional interface > public interface Executor { > From Alan.Bateman at oracle.com Wed Feb 6 08:54:37 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 06 Feb 2013 08:54:37 +0000 Subject: JDK 8 code review request for 8005623: Retrofit FunctionalInterface annotations to core platform interfaces In-Reply-To: <511184BF.9040202@oracle.com> References: <511184BF.9040202@oracle.com> Message-ID: <51121A4D.3070207@oracle.com> On 05/02/2013 22:16, Joe Darcy wrote: > : > > Webrev: > http://cr.openjdk.java.net/~darcy/8005623.0/ > > This review is both to cover the addition of @FunctionalInterface to > the types above and also to query if the annotation should be included > in any of the other types below under the same bug. Looks good to me. I would also include PathMatcher and DirectoryStream.Filter in this first cut. BTW: You mentioned XML as an area that you plan to look at it. One issue to be aware of is that they are currently compiled with the boot JDK so they can't make use of new APIs (this is true of the new build too, at least at this time). -Alan From scolebourne at joda.org Wed Feb 6 08:54:29 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 6 Feb 2013 08:54:29 +0000 Subject: JDK 8 code review request for 8005623: Retrofit FunctionalInterface annotations to core platform interfaces In-Reply-To: <511184BF.9040202@oracle.com> References: <511184BF.9040202@oracle.com> Message-ID: On 5 February 2013 22:16, Joe Darcy wrote: > This review is both to cover the addition of @FunctionalInterface to the > types above and also to query if the annotation should be included in any of > the other types below under the same bug. The sub-areas I have not > annotated yet include: > > * JSR 310 JSR-310 has already been dealt with and will be seen on the next integration. Stephen From joe.darcy at oracle.com Wed Feb 6 09:20:29 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 06 Feb 2013 01:20:29 -0800 Subject: JDK 8 code review request for 8005623: Retrofit FunctionalInterface annotations to core platform interfaces In-Reply-To: <51121775.7030701@oracle.com> References: <511184BF.9040202@oracle.com> <51121775.7030701@oracle.com> Message-ID: <5112205D.5020108@oracle.com> Not Thread itself, but the UncaughtExceptionHandler interface declared inside thread :-) (I wasn't positive this was meaningfully a functional interface though.) -Joe On 2/6/2013 12:42 AM, David Holmes wrote: > I don't think Thread belongs in there. ;-) > > David > > On 6/02/2013 8:16 AM, Joe Darcy wrote: >> Hello, >> >> As a follow-up to adding the FunctionalInterface annotation type to the >> platform, the time has come to annotate JDK classes with the annotation. >> >> I ran an annotation processor over the sources in the jdk repo to look >> for candidates to be marked as FunctionalInterfaces and for a first cut >> I have added the annotation to 34 types, including all of the types in >> java.util.function: >> >> src/share/classes/java/io/Closeable.java >> src/share/classes/java/io/FileFilter.java >> src/share/classes/java/io/FilenameFilter.java >> src/share/classes/java/io/Flushable.java >> src/share/classes/java/lang/AutoCloseable.java >> src/share/classes/java/lang/Comparable.java >> src/share/classes/java/lang/Iterable.java >> src/share/classes/java/lang/Readable.java >> src/share/classes/java/lang/Runnable.java >> src/share/classes/java/lang/Thread.java >> src/share/classes/java/util/Comparator.java >> src/share/classes/java/util/function/BinaryOperator.java >> src/share/classes/java/util/function/Block.java >> src/share/classes/java/util/function/DoubleBinaryOperator.java >> src/share/classes/java/util/function/DoubleBlock.java >> src/share/classes/java/util/function/DoubleFunction.java >> src/share/classes/java/util/function/DoubleSupplier.java >> src/share/classes/java/util/function/DoubleUnaryOperator.java >> src/share/classes/java/util/function/Function.java >> src/share/classes/java/util/function/IntBinaryOperator.java >> src/share/classes/java/util/function/IntBlock.java >> src/share/classes/java/util/function/IntFunction.java >> src/share/classes/java/util/function/IntSupplier.java >> src/share/classes/java/util/function/IntUnaryOperator.java >> src/share/classes/java/util/function/LongBinaryOperator.java >> src/share/classes/java/util/function/LongBlock.java >> src/share/classes/java/util/function/LongFunction.java >> src/share/classes/java/util/function/LongSupplier.java >> src/share/classes/java/util/function/LongUnaryOperator.java >> src/share/classes/java/util/function/Predicate.java >> src/share/classes/java/util/function/Supplier.java >> src/share/classes/java/util/function/UnaryOperator.java >> src/share/classes/java/util/logging/Filter.java >> src/share/classes/java/util/prefs/PreferenceChangeListener.java >> >> Webrev: >> http://cr.openjdk.java.net/~darcy/8005623.0/ >> >> This review is both to cover the addition of @FunctionalInterface to the >> types above and also to query if the annotation should be included in >> any of the other types below under the same bug. The sub-areas I have >> not annotated yet include: >> >> * xml >> * jdbc >> * JSR 310 >> * JNDI >> * RMI >> * Beans >> * networking >> * JMX/management >> * java.util.concurrent >> >> The annotation can be added in these areas separately later as well; if >> that is done, I recommend sub-tasks of JDK-8005297 "Add >> FunctionalInterface support to the platform" be used to track the work. >> >> I'll separately be sending email to the security and awt/swing teams >> about the functional interface candidates in their areas. >> >> Thanks, >> >> -Joe >> >> misc core >> ======== >> >> jdk/src/share/classes/java/lang/annotation/Annotation.java:40: Note: >> Candidate functional interface >> public interface Annotation { >> ^ >> jdk/src/share/classes/java/io/ObjectInputValidation.java:38: Note: >> Candidate functional interface >> public interface ObjectInputValidation { >> ^ >> jdk/src/share/classes/java/util/ResourceBundle.java:690: Note: Candidate >> functional interface >> private static interface CacheKeyReference { >> ^ >> jdk/src/share/classes/java/util/spi/ResourceBundleControlProvider.java:51: >> >> Note: Candidate functional interface >> public interface ResourceBundleControlProvider { >> ^ >> jdk/src/share/classes/java/util/Formattable.java:119: Note: Candidate >> functional interface >> public interface Formattable { >> ^ >> jdk/src/share/classes/java/util/Observer.java:35: Note: Candidate >> functional interface >> public interface Observer { >> ^ >> jdk/src/share/classes/java/nio/file/WatchEvent.java:76: Note: Candidate >> functional interface >> public static interface Modifier { >> ^ >> jdk/src/share/classes/java/nio/file/attribute/AttributeView.java:38: >> Note: Candidate functional interface >> public interface AttributeView { >> ^ >> jdk/src/share/classes/java/nio/file/attribute/FileStoreAttributeView.java:35: >> >> Note: Candidate functional interface >> public interface FileStoreAttributeView >> ^ >> jdk/src/share/classes/java/nio/file/attribute/FileAttributeView.java:39: >> Note: Candidate functional interface >> public interface FileAttributeView >> ^ >> jdk/src/share/classes/java/nio/file/attribute/UserPrincipal.java:54: >> Note: Candidate functional interface >> public interface UserPrincipal extends Principal { } >> ^ >> jdk/src/share/classes/java/nio/file/attribute/GroupPrincipal.java:42: >> Note: Candidate functional interface >> public interface GroupPrincipal extends UserPrincipal { } >> ^ >> jdk/src/share/classes/java/nio/file/PathMatcher.java:38: Note: Candidate >> functional interface >> public interface PathMatcher { >> ^ >> jdk/src/share/classes/java/nio/file/DirectoryStream.java:133: Note: >> Candidate functional interface >> public static interface Filter { >> ^ >> jdk/src/share/classes/javax/accessibility/Accessible.java:39: Note: >> Candidate functional interface >> public interface Accessible { >> ^ >> >> jdk/src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheData.java:37: >> Note: Candidate functional interface >> public interface ApacheData extends Data { >> >> reflection >> ============= >> >> jdk/src/share/classes/java/lang/reflect/GenericArrayType.java:33: Note: >> Candidate functional interface >> public interface GenericArrayType extends Type { >> ^ >> >> jdk/src/share/classes/java/lang/reflect/GenericDeclaration.java:33: >> Note: Candidate functional interface >> public interface GenericDeclaration { >> ^ >> jdk/src/share/classes/java/lang/reflect/InvocationHandler.java:41: Note: >> Candidate functional interface >> public interface InvocationHandler { >> ^ >> >> >> xml >> ===== >> >> jdk/src/share/classes/javax/xml/crypto/KeySelectorResult.java:46: Note: >> Candidate functional interface >> public interface KeySelectorResult { >> ^ >> jdk/src/share/classes/javax/xml/crypto/URIDereferencer.java:55: Note: >> Candidate functional interface >> public interface URIDereferencer { >> ^ >> jdk/src/share/classes/javax/xml/crypto/NodeSetData.java:42: Note: >> Candidate functional interface >> public interface NodeSetData extends Data { >> ^ >> jdk/src/share/classes/javax/xml/crypto/XMLStructure.java:39: Note: >> Candidate functional interface >> public interface XMLStructure { >> ^ >> >> JDBC - Assuming this will be handled separately under JDBC maintenance >> ====== >> >> jdk/src/share/classes/java/sql/RowId.java:63: Note: Candidate functional >> interface >> public interface RowId { >> ^ >> jdk/src/share/classes/javax/sql/RowSetReader.java:41: Note: Candidate >> functional interface >> public interface RowSetReader { >> ^ >> jdk/src/share/classes/javax/sql/RowSetWriter.java:49: Note: Candidate >> functional interface >> public interface RowSetWriter { >> ^ >> JSR 310 - Assuming this will be handled separately under JSR 310 >> evolution >> ========= >> >> jdk/src/share/classes/java/time/temporal/TemporalAdjuster.java:96: Note: >> Candidate functional interface >> public interface TemporalAdjuster { >> ^ >> jdk/src/share/classes/java/time/temporal/TemporalQuery.java:101: Note: >> Candidate functional interface >> public interface TemporalQuery { >> ^ >> jdk/src/share/classes/java/time/temporal/TemporalAdder.java:95: Note: >> Candidate functional interface >> public interface TemporalAdder { >> ^ >> jdk/src/share/classes/java/time/temporal/TemporalSubtractor.java:95: >> Note: Candidate functional interface >> public interface TemporalSubtractor { >> ^ >> >> JNDI >> ====== >> >> jdk/src/share/classes/javax/naming/event/NamingListener.java:57: Note: >> Candidate functional interface >> public interface NamingListener extends java.util.EventListener { >> ^ >> jdk/src/share/classes/javax/naming/ldap/HasControls.java:60: Note: >> Candidate functional interface >> public interface HasControls { >> ^ >> jdk/src/share/classes/javax/naming/Referenceable.java:49: Note: >> Candidate functional interface >> public interface Referenceable { >> ^ >> jdk/src/share/classes/javax/naming/NameParser.java:45: Note: Candidate >> functional interface >> public interface NameParser { >> ^ >> jdk/src/share/classes/javax/naming/spi/StateFactory.java:80: Note: >> Candidate functional interface >> public interface StateFactory { >> ^ >> jdk/src/share/classes/javax/naming/spi/ObjectFactoryBuilder.java:57: >> Note: Candidate functional interface >> public interface ObjectFactoryBuilder { >> ^ >> jdk/src/share/classes/javax/naming/spi/ObjectFactory.java:70: Note: >> Candidate functional interface >> public interface ObjectFactory { >> ^ >> jdk/src/share/classes/javax/naming/spi/InitialContextFactoryBuilder.java:54: >> >> Note: Candidate functional interface >> public interface InitialContextFactoryBuilder { >> ^ >> jdk/src/share/classes/javax/naming/spi/InitialContextFactory.java:53: >> Note: Candidate functional interface >> public interface InitialContextFactory { >> ^ >> >> RMI >> ===== >> >> jdk/src/share/classes/java/rmi/activation/ActivationInstantiator.java:42: >> Note: >> Candidate functional interface >> public interface ActivationInstantiator extends Remote { >> ^ >> jdk/src/share/classes/java/rmi/activation/Activator.java:64: Note: >> Candidate functional interface >> public interface Activator extends Remote { >> ^ >> jdk/src/share/classes/java/rmi/server/RMIServerSocketFactory.java:61: >> Note: Candidate functional interface >> public interface RMIServerSocketFactory { >> ^ >> jdk/src/share/classes/java/rmi/server/RMIFailureHandler.java:40: Note: >> Candidate functional interface >> public interface RMIFailureHandler { >> ^ >> jdk/src/share/classes/java/rmi/server/RMIClientSocketFactory.java:62: >> Note: Candidate functional interface >> public interface RMIClientSocketFactory { >> ^ >> jdk/src/share/classes/java/rmi/server/Unreferenced.java:37: Note: >> Candidate functional interface >> public interface Unreferenced { >> ^ >> Beans >> ======== >> >> jdk/src/share/classes/java/beans/PropertyChangeListener.java:34: Note: >> Candidate functional interface >> public interface PropertyChangeListener extends >> java.util.EventListener { >> ^ >> jdk/src/share/classes/java/beans/VetoableChangeListener.java:33: Note: >> Candidate functional interface >> public interface VetoableChangeListener extends >> java.util.EventListener { >> ^ >> jdk/src/share/classes/java/beans/ExceptionListener.java:34: Note: >> Candidate functional interface >> public interface ExceptionListener { >> ^ >> jdk/src/share/classes/java/beans/beancontext/BeanContextServiceRevokedListener.java:37: >> >> Note: Candidate functional interface >> public interface BeanContextServiceRevokedListener extends >> EventListener { >> ^ >> jdk/src/share/classes/java/beans/beancontext/BeanContextProxy.java:76: >> Note: Candidate functional interface >> public interface BeanContextProxy { >> ^ >> jdk/src/share/classes/java/beans/beancontext/BeanContextContainerProxy.java:43: >> >> Note: Candidate functional interface >> public interface BeanContextContainerProxy { >> ^ >> jdk/src/share/classes/java/beans/beancontext/BeanContextChildComponentProxy.java:44: >> >> Note: Candidate functional interface >> public interface BeanContextChildComponentProxy { >> ^ >> networking >> ========== >> >> jdk/src/share/classes/java/net/ContentHandlerFactory.java:41: Note: >> Candidate functional interface >> public interface ContentHandlerFactory { >> ^ >> jdk/src/share/classes/java/net/HttpCookie.java:855: Note: Candidate >> functional interface >> static interface CookieAttributeAssignor { >> ^ >> jdk/src/share/classes/java/net/SocketImplFactory.java:40: Note: >> Candidate functional interface >> interface SocketImplFactory { >> ^ >> jdk/src/share/classes/java/net/CookiePolicy.java:38: Note: Candidate >> functional interface >> public interface CookiePolicy { >> ^ >> jdk/src/share/classes/java/net/URLStreamHandlerFactory.java:40: Note: >> Candidate functional interface >> public interface URLStreamHandlerFactory { >> ^ >> jdk/src/share/classes/java/net/DatagramSocketImplFactory.java:38: Note: >> Candidate functional interface >> interface DatagramSocketImplFactory { >> ^ >> jdk/src/share/classes/java/net/FileNameMap.java:35: Note: Candidate >> functional interface >> public interface FileNameMap { >> ^ >> jdk/src/share/classes/java/net/ProtocolFamily.java:34: Note: Candidate >> functional interface >> public interface ProtocolFamily { >> ^ >> jdk/src/share/classes/javax/net/ssl/HostnameVerifier.java:46: Note: >> Candidate functional interface >> public interface HostnameVerifier { >> ^ >> jdk/src/share/classes/javax/net/ssl/HandshakeCompletedListener.java:44: >> Note: Candidate functional interface >> public interface HandshakeCompletedListener extends EventListener >> ^ >> jmx/management >> ================ >> >> jdk/src/share/classes/java/lang/management/PlatformManagedObject.java:52: >> Note: >> Candidate functional interface >> public interface PlatformManagedObject { >> ^ >> jdk/src/share/classes/java/lang/management/PlatformComponent.java:279: >> Note: Candidate functional interface >> interface MXBeanFetcher { >> ^ >> jdk/src/share/classes/java/lang/instrument/ClassFileTransformer.java:50: >> Note: Candidate functional interface >> public interface ClassFileTransformer { >> ^ >> jdk/src/share/classes/javax/management/openmbean/CompositeDataView.java:109: >> >> Note: Candidate functional interface >> public interface CompositeDataView { >> ^ >> jdk/src/share/classes/javax/management/NotificationFilter.java:35: Note: >> Candidate functional interface >> public interface NotificationFilter extends java.io.Serializable { >> ^ >> jdk/src/share/classes/javax/management/remote/JMXAddressable.java:44: >> Note: Candidate functional interface >> public interface JMXAddressable { >> ^ >> jdk/src/share/classes/javax/management/remote/JMXAuthenticator.java:52: >> Note: Candidate functional interface >> public interface JMXAuthenticator { >> ^ >> jdk/src/share/classes/javax/management/remote/JMXConnectorServerProvider.java:42: >> >> Note: Candidate functional interface >> public interface JMXConnectorServerProvider { >> ^ >> jdk/src/share/classes/javax/management/remote/JMXConnectorProvider.java:41: >> >> Note: Candidate functional interface >> public interface JMXConnectorProvider { >> ^ >> jdk/src/share/classes/javax/management/NotificationListener.java:34: >> Note: Candidate functional interface >> public interface NotificationListener extends java.util.EventListener { >> ^ >> jdk/src/share/classes/javax/management/DescriptorRead.java:33: Note: >> Candidate functional interface >> public interface DescriptorRead { >> ^ >> concurrent - Assume this will be done first upstream in Doug's repos >> ============ >> >> jdk/src/share/classes/java/util/concurrent/ThreadFactory.java:58: Note: >> Candidate functional interface >> public interface ThreadFactory { >> ^ >> jdk/src/share/classes/java/util/concurrent/ForkJoinPool.java:545: Note: >> Candidate functional interface >> public static interface ForkJoinWorkerThreadFactory { >> ^ >> jdk/src/share/classes/java/util/concurrent/RejectedExecutionHandler.java:44: >> >> Note: Candidate functional interface >> public interface RejectedExecutionHandler { >> ^ >> jdk/src/share/classes/java/util/concurrent/Callable.java:57: Note: >> Candidate functional interface >> public interface Callable { >> ^ >> jdk/src/share/classes/java/util/concurrent/Executor.java:128: Note: >> Candidate functional interface >> public interface Executor { >> From david.holmes at oracle.com Wed Feb 6 09:51:29 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 Feb 2013 19:51:29 +1000 Subject: RFR JDK-8007609 In-Reply-To: <3d9879ec-77e4-42f7-bc90-578d7c488054@default> References: <3d9879ec-77e4-42f7-bc90-578d7c488054@default> Message-ID: <511227A1.4050908@oracle.com> Hi John, On 6/02/2013 9:49 AM, John Zavgren wrote: > Greetings: > > I modified the code in > src/windows/native/java/io/WinNTFileSystem_md.c > so that it checks the return value of realloc() and frees memory when there is an error. > > The webrev image of this change is visible at: > http://cr.openjdk.java.net/~jzavgren/8007609/webrev.01/ The style in that file is all over the place but unless it involves the actual fix it is better to leave it as is - else it just obscures the real change. The core of the fix seems okay. This change: ! if (cp != NULL) ! { was correct in its previous form: if (cp != NULL) { Also the indentation seems very wrong at: len = (*GetFinalPathNameByHandle_func)(h, result, len, 0); Cheers, David > Thanks! > John Zavgren From david.holmes at oracle.com Wed Feb 6 09:52:13 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 Feb 2013 19:52:13 +1000 Subject: RFR JDK-8007609 In-Reply-To: <3d9879ec-77e4-42f7-bc90-578d7c488054@default> References: <3d9879ec-77e4-42f7-bc90-578d7c488054@default> Message-ID: <511227CD.6080705@oracle.com> PS. if(resultTemp == NULL) { Need space after "if" David On 6/02/2013 9:49 AM, John Zavgren wrote: > Greetings: > > I modified the code in > src/windows/native/java/io/WinNTFileSystem_md.c > so that it checks the return value of realloc() and frees memory when there is an error. > > The webrev image of this change is visible at: > http://cr.openjdk.java.net/~jzavgren/8007609/webrev.01/ > > Thanks! > John Zavgren From chris.hegarty at oracle.com Wed Feb 6 10:04:56 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 06 Feb 2013 10:04:56 +0000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <5111B7A4.8040902@oracle.com> References: <510BD3E6.1090103@oracle.com> <5110A4EC.1050907@oracle.com> <51111228.5010707@oracle.com> <5111B7A4.8040902@oracle.com> Message-ID: <51122AC8.2070400@oracle.com> Thank for the review. comments inline... On 06/02/2013 01:53, David Holmes wrote: > 204 # Terminate with exit 0 only if all subprocesses were successful > 205 ec=0 > 206 if [ -d ${tmp} ]; then > 207 for rc in `ls ${tmp}/*.pid.rc` ; do > > I don't think you need to subshell an invocation of ls, simply do > > for rc in "${tmp}/*.pid.rc" ; do Yes this is better, but the quotes are incorrect. It should simply be for rc in ${tmp}/*.pid.rc ; do > 208 exit_code=`cat ${rc} | tr -d ' \n\r'` > 209 if [ "${exit_code}" != "0" ] ; then > 210 echo "WARNING: ${rc} exited abnormally." > > Not sure printing ${rc} will be very informative there ?? It prints the file name which contains the subrepo name. Not pretty, but this gives more information about which clone/pull failed. > 211 ec=1 > > Is there a "break" we can add here? Yes, we could break out/exit early, but I deliberately want to iterator over all the child process exits codes to better highlight which ones, if more than one, failed. > In get_source.sh > > # Get clones of all nested repositories > ! sh ./common/bin/hgforest.sh clone "$@" || exit 1 > > # Update all existing repositories to the latest sources > sh ./common/bin/hgforest.sh pull -u > > don't we want "|| exit 1" for the pull case as well? Since the pull is the last command there is no need for "|| exit 1", since its exit code will be returned. -Chris. > > Thanks, > David > > On 6/02/2013 12:07 AM, Chris Hegarty wrote: >> On 02/05/2013 06:21 AM, David Holmes wrote: >>> Chris, >>> >>> When these failures occur does the failure get reflected in an error >>> exit code? >> >> Not currently, good point. >> >>> I'm seeing hudson builds merilly buildinh OpenJDK instead of Oracle JDK >>> because the closed repos were skipped due to this bug :( >> >> This is what I am seeing too, and the reason I proposed a patch to >> resolve it. >> >> Updated webrev; >> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >> >> 1) now checks, and returns, appropriate error code, so that higher >> level scripts can determine if it completed successfully >> 2) Added diagnostic error message to help identify potential future >> problems if a nested repo is blocked for too long >> >> -Chris. >> >>> >>> David >>> >>> On 2/02/2013 12:40 AM, Chris Hegarty wrote: >>>> [ to build-dev and core-libs-dev, expect reviewer from either, but will >>>> integrate through jdk8/tl ] >>>> >>>> This issue is mainly of interest to Oracle engineers, but it effects >>>> the >>>> public hgforest script. >>>> >>>> When hgforest.sh is run with an addition argument to specify a closed >>>> server, there is a problem/race between the creation of the directories >>>> to hold nested repositories and the clone itself. These directories >>>> need >>>> to be created before the clone command is executed, otherwise it will >>>> fail, as below. >>>> >>>> The trivial fix is to back off these nested repos until their >>>> containing >>>> directory exists. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >>>> >>>> sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log >>>> # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed >>>> jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed >>>> hotspot/test/closed deploy install sponsors pubs >>>> >>>> Waiting 5 secs before spawning next background command. >>>> Waiting 5 secs before spawning next background command. >>>> Waiting 5 secs before spawning next background command. >>>> jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed >>>> jdk/src/closed: abort: No such file or directory: jdk/src/closed >>>> jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed >>>> jdk/make/closed: abort: No such file or directory: jdk/make/closed >>>> Waiting 5 secs before spawning next background command. >>>> .... >>>> >>>> >>>> -Chris. From Alan.Bateman at oracle.com Wed Feb 6 10:18:28 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 06 Feb 2013 10:18:28 +0000 Subject: RFR JDK-8007609 In-Reply-To: <3d9879ec-77e4-42f7-bc90-578d7c488054@default> References: <3d9879ec-77e4-42f7-bc90-578d7c488054@default> Message-ID: <51122DF4.4000409@oracle.com> On 05/02/2013 23:49, John Zavgren wrote: > Greetings: > > I modified the code in > src/windows/native/java/io/WinNTFileSystem_md.c > so that it checks the return value of realloc() and frees memory when there is an error. > > The webrev image of this change is visible at: > http://cr.openjdk.java.net/~jzavgren/8007609/webrev.01/ > > Thanks! > John Zavgren Formatting aside, it looks like the change means that a realloc fail will leave the file open. I think this is all that is needed: WCHAR* newResult = (WCHAR*)realloc(...); if (newResult != NULL) { len = (*GetFinalPathNameByHandle_func)( h, newResult, len, 0); } else { free(result); len = 0; } result = newResult; -Alan. From david.holmes at oracle.com Wed Feb 6 10:24:52 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 Feb 2013 20:24:52 +1000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <51122AC8.2070400@oracle.com> References: <510BD3E6.1090103@oracle.com> <5110A4EC.1050907@oracle.com> <51111228.5010707@oracle.com> <5111B7A4.8040902@oracle.com> <51122AC8.2070400@oracle.com> Message-ID: <51122F74.4000301@oracle.com> Thanks Chris. I missed a couple of obvious things there. :( One thing related to the repo name in the $(rc) variable. Somewhere the repo name gets mangled: + echo jdk/src/closed + sed -e s at ./@@ -e s@/@_ at g + repopidfile=jdsrc_closed the / to _ doesn't work for the first / (not part of your fix though). I must say though that this bug still has me perplexed. I ran with set -x and observed the following. Given: # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed hotspot/test/closed deploy install sponsors pubs The first clone I see is corba and the second is jdk/make/closed. The very last clone I see is jdk. BUT there was no error creating the sub-repos before the enclosing repo! ??? Makes no sense. David ----- On 6/02/2013 8:04 PM, Chris Hegarty wrote: > Thank for the review. comments inline... > > On 06/02/2013 01:53, David Holmes wrote: >> 204 # Terminate with exit 0 only if all subprocesses were successful >> 205 ec=0 >> 206 if [ -d ${tmp} ]; then >> 207 for rc in `ls ${tmp}/*.pid.rc` ; do >> >> I don't think you need to subshell an invocation of ls, simply do >> >> for rc in "${tmp}/*.pid.rc" ; do > > Yes this is better, but the quotes are incorrect. It should simply be > for rc in ${tmp}/*.pid.rc ; do > >> 208 exit_code=`cat ${rc} | tr -d ' \n\r'` >> 209 if [ "${exit_code}" != "0" ] ; then >> 210 echo "WARNING: ${rc} exited abnormally." >> >> Not sure printing ${rc} will be very informative there ?? > > It prints the file name which contains the subrepo name. Not pretty, but > this gives more information about which clone/pull failed. > >> 211 ec=1 >> >> Is there a "break" we can add here? > > Yes, we could break out/exit early, but I deliberately want to iterator > over all the child process exits codes to better highlight which ones, > if more than one, failed. > >> In get_source.sh >> >> # Get clones of all nested repositories >> ! sh ./common/bin/hgforest.sh clone "$@" || exit 1 >> >> # Update all existing repositories to the latest sources >> sh ./common/bin/hgforest.sh pull -u >> >> don't we want "|| exit 1" for the pull case as well? > > Since the pull is the last command there is no need for "|| exit 1", > since its exit code will be returned. > > -Chris. > >> >> Thanks, >> David >> >> On 6/02/2013 12:07 AM, Chris Hegarty wrote: >>> On 02/05/2013 06:21 AM, David Holmes wrote: >>>> Chris, >>>> >>>> When these failures occur does the failure get reflected in an error >>>> exit code? >>> >>> Not currently, good point. >>> >>>> I'm seeing hudson builds merilly buildinh OpenJDK instead of Oracle JDK >>>> because the closed repos were skipped due to this bug :( >>> >>> This is what I am seeing too, and the reason I proposed a patch to >>> resolve it. >>> >>> Updated webrev; >>> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >>> >>> 1) now checks, and returns, appropriate error code, so that higher >>> level scripts can determine if it completed successfully >>> 2) Added diagnostic error message to help identify potential future >>> problems if a nested repo is blocked for too long >>> >>> -Chris. >>> >>>> >>>> David >>>> >>>> On 2/02/2013 12:40 AM, Chris Hegarty wrote: >>>>> [ to build-dev and core-libs-dev, expect reviewer from either, but >>>>> will >>>>> integrate through jdk8/tl ] >>>>> >>>>> This issue is mainly of interest to Oracle engineers, but it effects >>>>> the >>>>> public hgforest script. >>>>> >>>>> When hgforest.sh is run with an addition argument to specify a closed >>>>> server, there is a problem/race between the creation of the >>>>> directories >>>>> to hold nested repositories and the clone itself. These directories >>>>> need >>>>> to be created before the clone command is executed, otherwise it will >>>>> fail, as below. >>>>> >>>>> The trivial fix is to back off these nested repos until their >>>>> containing >>>>> directory exists. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >>>>> >>>>> sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log >>>>> # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed >>>>> jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed >>>>> hotspot/test/closed deploy install sponsors pubs >>>>> >>>>> Waiting 5 secs before spawning next background command. >>>>> Waiting 5 secs before spawning next background command. >>>>> Waiting 5 secs before spawning next background command. >>>>> jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>>>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>>>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed >>>>> jdk/src/closed: abort: No such file or directory: jdk/src/closed >>>>> jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>>>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>>>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed >>>>> jdk/make/closed: abort: No such file or directory: jdk/make/closed >>>>> Waiting 5 secs before spawning next background command. >>>>> .... >>>>> >>>>> >>>>> -Chris. From david.holmes at oracle.com Wed Feb 6 10:38:08 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 Feb 2013 20:38:08 +1000 Subject: RFR JDK-8007609 In-Reply-To: <51122DF4.4000409@oracle.com> References: <3d9879ec-77e4-42f7-bc90-578d7c488054@default> <51122DF4.4000409@oracle.com> Message-ID: <51123290.8080904@oracle.com> On 6/02/2013 8:18 PM, Alan Bateman wrote: > On 05/02/2013 23:49, John Zavgren wrote: >> Greetings: >> >> I modified the code in >> src/windows/native/java/io/WinNTFileSystem_md.c >> so that it checks the return value of realloc() and frees memory when >> there is an error. >> >> The webrev image of this change is visible at: >> http://cr.openjdk.java.net/~jzavgren/8007609/webrev.01/ >> >> Thanks! >> John Zavgren > Formatting aside, it looks like the change means that a realloc fail > will leave the file open. I think this is all that is needed: > > WCHAR* newResult = (WCHAR*)realloc(...); > if (newResult != NULL) { > len = (*GetFinalPathNameByHandle_func)( h, newResult, len, 0); > } else { > free(result); > len = 0; > } > result = newResult; If you move the "result = newResult" inside the if then you don't even need to free in the else. But yes I missed the fact that the close logic at the end of the function has to be executed - so no early returns on error. Sorry about that. David > -Alan. From chris.hegarty at oracle.com Wed Feb 6 10:41:39 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 06 Feb 2013 10:41:39 +0000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <51122F74.4000301@oracle.com> References: <510BD3E6.1090103@oracle.com> <5110A4EC.1050907@oracle.com> <51111228.5010707@oracle.com> <5111B7A4.8040902@oracle.com> <51122AC8.2070400@oracle.com> <51122F74.4000301@oracle.com> Message-ID: <51123363.8080606@oracle.com> On 06/02/2013 10:24, David Holmes wrote: > Thanks Chris. I missed a couple of obvious things there. :( > > One thing related to the repo name in the $(rc) variable. Somewhere the > repo name gets mangled: > > + echo jdk/src/closed > + sed -e s at ./@@ -e s@/@_ at g > + repopidfile=jdsrc_closed > > the / to _ doesn't work for the first / (not part of your fix though). > > I must say though that this bug still has me perplexed. I ran with set > -x and observed the following. Given: > > # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed > jdk/make/closed jdk/test/closed hotspot/make/closed > hotspot/src/closed hotspot/test/closed deploy install sponsors pubs > > The first clone I see is corba and the second is jdk/make/closed. The > very last clone I see is jdk. BUT there was no error creating the > sub-repos before the enclosing repo! ??? Makes no sense. I only see the problem when running with old versions of hg. More recent ones seem to be immune to it. I guess they must do something equivalent to 'mkdir -p' on the destination directory. Blocking the clone of the nested repos until the enclosing repo creates the holding directory seems like a small price to pay for such an obscure bug. Also, now returning an error code when something fails should help avoid any future issues of missing or out of date repos. -Chris. > > David > ----- > > On 6/02/2013 8:04 PM, Chris Hegarty wrote: >> Thank for the review. comments inline... >> >> On 06/02/2013 01:53, David Holmes wrote: >>> 204 # Terminate with exit 0 only if all subprocesses were successful >>> 205 ec=0 >>> 206 if [ -d ${tmp} ]; then >>> 207 for rc in `ls ${tmp}/*.pid.rc` ; do >>> >>> I don't think you need to subshell an invocation of ls, simply do >>> >>> for rc in "${tmp}/*.pid.rc" ; do >> >> Yes this is better, but the quotes are incorrect. It should simply be >> for rc in ${tmp}/*.pid.rc ; do >> >>> 208 exit_code=`cat ${rc} | tr -d ' \n\r'` >>> 209 if [ "${exit_code}" != "0" ] ; then >>> 210 echo "WARNING: ${rc} exited abnormally." >>> >>> Not sure printing ${rc} will be very informative there ?? >> >> It prints the file name which contains the subrepo name. Not pretty, but >> this gives more information about which clone/pull failed. >> >>> 211 ec=1 >>> >>> Is there a "break" we can add here? >> >> Yes, we could break out/exit early, but I deliberately want to iterator >> over all the child process exits codes to better highlight which ones, >> if more than one, failed. >> >>> In get_source.sh >>> >>> # Get clones of all nested repositories >>> ! sh ./common/bin/hgforest.sh clone "$@" || exit 1 >>> >>> # Update all existing repositories to the latest sources >>> sh ./common/bin/hgforest.sh pull -u >>> >>> don't we want "|| exit 1" for the pull case as well? >> >> Since the pull is the last command there is no need for "|| exit 1", >> since its exit code will be returned. >> >> -Chris. >> >>> >>> Thanks, >>> David >>> >>> On 6/02/2013 12:07 AM, Chris Hegarty wrote: >>>> On 02/05/2013 06:21 AM, David Holmes wrote: >>>>> Chris, >>>>> >>>>> When these failures occur does the failure get reflected in an error >>>>> exit code? >>>> >>>> Not currently, good point. >>>> >>>>> I'm seeing hudson builds merilly buildinh OpenJDK instead of Oracle >>>>> JDK >>>>> because the closed repos were skipped due to this bug :( >>>> >>>> This is what I am seeing too, and the reason I proposed a patch to >>>> resolve it. >>>> >>>> Updated webrev; >>>> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >>>> >>>> 1) now checks, and returns, appropriate error code, so that higher >>>> level scripts can determine if it completed successfully >>>> 2) Added diagnostic error message to help identify potential future >>>> problems if a nested repo is blocked for too long >>>> >>>> -Chris. >>>> >>>>> >>>>> David >>>>> >>>>> On 2/02/2013 12:40 AM, Chris Hegarty wrote: >>>>>> [ to build-dev and core-libs-dev, expect reviewer from either, but >>>>>> will >>>>>> integrate through jdk8/tl ] >>>>>> >>>>>> This issue is mainly of interest to Oracle engineers, but it effects >>>>>> the >>>>>> public hgforest script. >>>>>> >>>>>> When hgforest.sh is run with an addition argument to specify a closed >>>>>> server, there is a problem/race between the creation of the >>>>>> directories >>>>>> to hold nested repositories and the clone itself. These directories >>>>>> need >>>>>> to be created before the clone command is executed, otherwise it will >>>>>> fail, as below. >>>>>> >>>>>> The trivial fix is to back off these nested repos until their >>>>>> containing >>>>>> directory exists. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >>>>>> >>>>>> sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log >>>>>> # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed >>>>>> jdk/make/closed jdk/test/closed hotspot/make/closed >>>>>> hotspot/src/closed >>>>>> hotspot/test/closed deploy install sponsors pubs >>>>>> >>>>>> Waiting 5 secs before spawning next background command. >>>>>> Waiting 5 secs before spawning next background command. >>>>>> Waiting 5 secs before spawning next background command. >>>>>> jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>>>>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>>>>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed >>>>>> jdk/src/closed: abort: No such file or directory: jdk/src/closed >>>>>> jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>>>>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>>>>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed >>>>>> jdk/make/closed: abort: No such file or directory: jdk/make/closed >>>>>> Waiting 5 secs before spawning next background command. >>>>>> .... >>>>>> >>>>>> >>>>>> -Chris. From chris.hegarty at oracle.com Wed Feb 6 11:37:15 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 06 Feb 2013 11:37:15 +0000 Subject: hg: jdk8/tl: 8007625: race with nested repos in /common/bin/hgforest.sh Message-ID: <20130206113715.E536A47880@hg.openjdk.java.net> Changeset: 8dd61906da5f Author: chegar Date: 2013-02-06 11:36 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8dd61906da5f 8007625: race with nested repos in /common/bin/hgforest.sh Reviewed-by: dholmes, ohair, ohrstrom ! common/bin/hgforest.sh ! get_source.sh From chris.hegarty at oracle.com Wed Feb 6 11:53:30 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 06 Feb 2013 11:53:30 +0000 Subject: JDK 8 code review request for 8005623: Retrofit FunctionalInterface annotations to core platform interfaces In-Reply-To: <5112205D.5020108@oracle.com> References: <511184BF.9040202@oracle.com> <51121775.7030701@oracle.com> <5112205D.5020108@oracle.com> Message-ID: <5112443A.5090907@oracle.com> On 06/02/2013 09:20, Joe Darcy wrote: > Not Thread itself, This was my first reaction too :-) > but the UncaughtExceptionHandler interface declared > inside thread :-) (I wasn't positive this was meaningfully a functional > interface though.) Maybe, but is does fit the description of a "functional interface". -Chris. > > -Joe > > On 2/6/2013 12:42 AM, David Holmes wrote: >> I don't think Thread belongs in there. ;-) >> >> David >> >> On 6/02/2013 8:16 AM, Joe Darcy wrote: >>> Hello, >>> >>> As a follow-up to adding the FunctionalInterface annotation type to the >>> platform, the time has come to annotate JDK classes with the annotation. >>> >>> I ran an annotation processor over the sources in the jdk repo to look >>> for candidates to be marked as FunctionalInterfaces and for a first cut >>> I have added the annotation to 34 types, including all of the types in >>> java.util.function: >>> >>> src/share/classes/java/io/Closeable.java >>> src/share/classes/java/io/FileFilter.java >>> src/share/classes/java/io/FilenameFilter.java >>> src/share/classes/java/io/Flushable.java >>> src/share/classes/java/lang/AutoCloseable.java >>> src/share/classes/java/lang/Comparable.java >>> src/share/classes/java/lang/Iterable.java >>> src/share/classes/java/lang/Readable.java >>> src/share/classes/java/lang/Runnable.java >>> src/share/classes/java/lang/Thread.java >>> src/share/classes/java/util/Comparator.java >>> src/share/classes/java/util/function/BinaryOperator.java >>> src/share/classes/java/util/function/Block.java >>> src/share/classes/java/util/function/DoubleBinaryOperator.java >>> src/share/classes/java/util/function/DoubleBlock.java >>> src/share/classes/java/util/function/DoubleFunction.java >>> src/share/classes/java/util/function/DoubleSupplier.java >>> src/share/classes/java/util/function/DoubleUnaryOperator.java >>> src/share/classes/java/util/function/Function.java >>> src/share/classes/java/util/function/IntBinaryOperator.java >>> src/share/classes/java/util/function/IntBlock.java >>> src/share/classes/java/util/function/IntFunction.java >>> src/share/classes/java/util/function/IntSupplier.java >>> src/share/classes/java/util/function/IntUnaryOperator.java >>> src/share/classes/java/util/function/LongBinaryOperator.java >>> src/share/classes/java/util/function/LongBlock.java >>> src/share/classes/java/util/function/LongFunction.java >>> src/share/classes/java/util/function/LongSupplier.java >>> src/share/classes/java/util/function/LongUnaryOperator.java >>> src/share/classes/java/util/function/Predicate.java >>> src/share/classes/java/util/function/Supplier.java >>> src/share/classes/java/util/function/UnaryOperator.java >>> src/share/classes/java/util/logging/Filter.java >>> src/share/classes/java/util/prefs/PreferenceChangeListener.java >>> >>> Webrev: >>> http://cr.openjdk.java.net/~darcy/8005623.0/ >>> >>> This review is both to cover the addition of @FunctionalInterface to the >>> types above and also to query if the annotation should be included in >>> any of the other types below under the same bug. The sub-areas I have >>> not annotated yet include: >>> >>> * xml >>> * jdbc >>> * JSR 310 >>> * JNDI >>> * RMI >>> * Beans >>> * networking >>> * JMX/management >>> * java.util.concurrent >>> >>> The annotation can be added in these areas separately later as well; if >>> that is done, I recommend sub-tasks of JDK-8005297 "Add >>> FunctionalInterface support to the platform" be used to track the work. >>> >>> I'll separately be sending email to the security and awt/swing teams >>> about the functional interface candidates in their areas. >>> >>> Thanks, >>> >>> -Joe >>> >>> misc core >>> ======== >>> >>> jdk/src/share/classes/java/lang/annotation/Annotation.java:40: Note: >>> Candidate functional interface >>> public interface Annotation { >>> ^ >>> jdk/src/share/classes/java/io/ObjectInputValidation.java:38: Note: >>> Candidate functional interface >>> public interface ObjectInputValidation { >>> ^ >>> jdk/src/share/classes/java/util/ResourceBundle.java:690: Note: Candidate >>> functional interface >>> private static interface CacheKeyReference { >>> ^ >>> jdk/src/share/classes/java/util/spi/ResourceBundleControlProvider.java:51: >>> >>> Note: Candidate functional interface >>> public interface ResourceBundleControlProvider { >>> ^ >>> jdk/src/share/classes/java/util/Formattable.java:119: Note: Candidate >>> functional interface >>> public interface Formattable { >>> ^ >>> jdk/src/share/classes/java/util/Observer.java:35: Note: Candidate >>> functional interface >>> public interface Observer { >>> ^ >>> jdk/src/share/classes/java/nio/file/WatchEvent.java:76: Note: Candidate >>> functional interface >>> public static interface Modifier { >>> ^ >>> jdk/src/share/classes/java/nio/file/attribute/AttributeView.java:38: >>> Note: Candidate functional interface >>> public interface AttributeView { >>> ^ >>> jdk/src/share/classes/java/nio/file/attribute/FileStoreAttributeView.java:35: >>> >>> Note: Candidate functional interface >>> public interface FileStoreAttributeView >>> ^ >>> jdk/src/share/classes/java/nio/file/attribute/FileAttributeView.java:39: >>> Note: Candidate functional interface >>> public interface FileAttributeView >>> ^ >>> jdk/src/share/classes/java/nio/file/attribute/UserPrincipal.java:54: >>> Note: Candidate functional interface >>> public interface UserPrincipal extends Principal { } >>> ^ >>> jdk/src/share/classes/java/nio/file/attribute/GroupPrincipal.java:42: >>> Note: Candidate functional interface >>> public interface GroupPrincipal extends UserPrincipal { } >>> ^ >>> jdk/src/share/classes/java/nio/file/PathMatcher.java:38: Note: Candidate >>> functional interface >>> public interface PathMatcher { >>> ^ >>> jdk/src/share/classes/java/nio/file/DirectoryStream.java:133: Note: >>> Candidate functional interface >>> public static interface Filter { >>> ^ >>> jdk/src/share/classes/javax/accessibility/Accessible.java:39: Note: >>> Candidate functional interface >>> public interface Accessible { >>> ^ >>> >>> jdk/src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheData.java:37: >>> Note: Candidate functional interface >>> public interface ApacheData extends Data { >>> >>> reflection >>> ============= >>> >>> jdk/src/share/classes/java/lang/reflect/GenericArrayType.java:33: Note: >>> Candidate functional interface >>> public interface GenericArrayType extends Type { >>> ^ >>> >>> jdk/src/share/classes/java/lang/reflect/GenericDeclaration.java:33: >>> Note: Candidate functional interface >>> public interface GenericDeclaration { >>> ^ >>> jdk/src/share/classes/java/lang/reflect/InvocationHandler.java:41: Note: >>> Candidate functional interface >>> public interface InvocationHandler { >>> ^ >>> >>> >>> xml >>> ===== >>> >>> jdk/src/share/classes/javax/xml/crypto/KeySelectorResult.java:46: Note: >>> Candidate functional interface >>> public interface KeySelectorResult { >>> ^ >>> jdk/src/share/classes/javax/xml/crypto/URIDereferencer.java:55: Note: >>> Candidate functional interface >>> public interface URIDereferencer { >>> ^ >>> jdk/src/share/classes/javax/xml/crypto/NodeSetData.java:42: Note: >>> Candidate functional interface >>> public interface NodeSetData extends Data { >>> ^ >>> jdk/src/share/classes/javax/xml/crypto/XMLStructure.java:39: Note: >>> Candidate functional interface >>> public interface XMLStructure { >>> ^ >>> >>> JDBC - Assuming this will be handled separately under JDBC maintenance >>> ====== >>> >>> jdk/src/share/classes/java/sql/RowId.java:63: Note: Candidate functional >>> interface >>> public interface RowId { >>> ^ >>> jdk/src/share/classes/javax/sql/RowSetReader.java:41: Note: Candidate >>> functional interface >>> public interface RowSetReader { >>> ^ >>> jdk/src/share/classes/javax/sql/RowSetWriter.java:49: Note: Candidate >>> functional interface >>> public interface RowSetWriter { >>> ^ >>> JSR 310 - Assuming this will be handled separately under JSR 310 >>> evolution >>> ========= >>> >>> jdk/src/share/classes/java/time/temporal/TemporalAdjuster.java:96: Note: >>> Candidate functional interface >>> public interface TemporalAdjuster { >>> ^ >>> jdk/src/share/classes/java/time/temporal/TemporalQuery.java:101: Note: >>> Candidate functional interface >>> public interface TemporalQuery { >>> ^ >>> jdk/src/share/classes/java/time/temporal/TemporalAdder.java:95: Note: >>> Candidate functional interface >>> public interface TemporalAdder { >>> ^ >>> jdk/src/share/classes/java/time/temporal/TemporalSubtractor.java:95: >>> Note: Candidate functional interface >>> public interface TemporalSubtractor { >>> ^ >>> >>> JNDI >>> ====== >>> >>> jdk/src/share/classes/javax/naming/event/NamingListener.java:57: Note: >>> Candidate functional interface >>> public interface NamingListener extends java.util.EventListener { >>> ^ >>> jdk/src/share/classes/javax/naming/ldap/HasControls.java:60: Note: >>> Candidate functional interface >>> public interface HasControls { >>> ^ >>> jdk/src/share/classes/javax/naming/Referenceable.java:49: Note: >>> Candidate functional interface >>> public interface Referenceable { >>> ^ >>> jdk/src/share/classes/javax/naming/NameParser.java:45: Note: Candidate >>> functional interface >>> public interface NameParser { >>> ^ >>> jdk/src/share/classes/javax/naming/spi/StateFactory.java:80: Note: >>> Candidate functional interface >>> public interface StateFactory { >>> ^ >>> jdk/src/share/classes/javax/naming/spi/ObjectFactoryBuilder.java:57: >>> Note: Candidate functional interface >>> public interface ObjectFactoryBuilder { >>> ^ >>> jdk/src/share/classes/javax/naming/spi/ObjectFactory.java:70: Note: >>> Candidate functional interface >>> public interface ObjectFactory { >>> ^ >>> jdk/src/share/classes/javax/naming/spi/InitialContextFactoryBuilder.java:54: >>> >>> Note: Candidate functional interface >>> public interface InitialContextFactoryBuilder { >>> ^ >>> jdk/src/share/classes/javax/naming/spi/InitialContextFactory.java:53: >>> Note: Candidate functional interface >>> public interface InitialContextFactory { >>> ^ >>> >>> RMI >>> ===== >>> >>> jdk/src/share/classes/java/rmi/activation/ActivationInstantiator.java:42: >>> Note: >>> Candidate functional interface >>> public interface ActivationInstantiator extends Remote { >>> ^ >>> jdk/src/share/classes/java/rmi/activation/Activator.java:64: Note: >>> Candidate functional interface >>> public interface Activator extends Remote { >>> ^ >>> jdk/src/share/classes/java/rmi/server/RMIServerSocketFactory.java:61: >>> Note: Candidate functional interface >>> public interface RMIServerSocketFactory { >>> ^ >>> jdk/src/share/classes/java/rmi/server/RMIFailureHandler.java:40: Note: >>> Candidate functional interface >>> public interface RMIFailureHandler { >>> ^ >>> jdk/src/share/classes/java/rmi/server/RMIClientSocketFactory.java:62: >>> Note: Candidate functional interface >>> public interface RMIClientSocketFactory { >>> ^ >>> jdk/src/share/classes/java/rmi/server/Unreferenced.java:37: Note: >>> Candidate functional interface >>> public interface Unreferenced { >>> ^ >>> Beans >>> ======== >>> >>> jdk/src/share/classes/java/beans/PropertyChangeListener.java:34: Note: >>> Candidate functional interface >>> public interface PropertyChangeListener extends >>> java.util.EventListener { >>> ^ >>> jdk/src/share/classes/java/beans/VetoableChangeListener.java:33: Note: >>> Candidate functional interface >>> public interface VetoableChangeListener extends >>> java.util.EventListener { >>> ^ >>> jdk/src/share/classes/java/beans/ExceptionListener.java:34: Note: >>> Candidate functional interface >>> public interface ExceptionListener { >>> ^ >>> jdk/src/share/classes/java/beans/beancontext/BeanContextServiceRevokedListener.java:37: >>> >>> Note: Candidate functional interface >>> public interface BeanContextServiceRevokedListener extends >>> EventListener { >>> ^ >>> jdk/src/share/classes/java/beans/beancontext/BeanContextProxy.java:76: >>> Note: Candidate functional interface >>> public interface BeanContextProxy { >>> ^ >>> jdk/src/share/classes/java/beans/beancontext/BeanContextContainerProxy.java:43: >>> >>> Note: Candidate functional interface >>> public interface BeanContextContainerProxy { >>> ^ >>> jdk/src/share/classes/java/beans/beancontext/BeanContextChildComponentProxy.java:44: >>> >>> Note: Candidate functional interface >>> public interface BeanContextChildComponentProxy { >>> ^ >>> networking >>> ========== >>> >>> jdk/src/share/classes/java/net/ContentHandlerFactory.java:41: Note: >>> Candidate functional interface >>> public interface ContentHandlerFactory { >>> ^ >>> jdk/src/share/classes/java/net/HttpCookie.java:855: Note: Candidate >>> functional interface >>> static interface CookieAttributeAssignor { >>> ^ >>> jdk/src/share/classes/java/net/SocketImplFactory.java:40: Note: >>> Candidate functional interface >>> interface SocketImplFactory { >>> ^ >>> jdk/src/share/classes/java/net/CookiePolicy.java:38: Note: Candidate >>> functional interface >>> public interface CookiePolicy { >>> ^ >>> jdk/src/share/classes/java/net/URLStreamHandlerFactory.java:40: Note: >>> Candidate functional interface >>> public interface URLStreamHandlerFactory { >>> ^ >>> jdk/src/share/classes/java/net/DatagramSocketImplFactory.java:38: Note: >>> Candidate functional interface >>> interface DatagramSocketImplFactory { >>> ^ >>> jdk/src/share/classes/java/net/FileNameMap.java:35: Note: Candidate >>> functional interface >>> public interface FileNameMap { >>> ^ >>> jdk/src/share/classes/java/net/ProtocolFamily.java:34: Note: Candidate >>> functional interface >>> public interface ProtocolFamily { >>> ^ >>> jdk/src/share/classes/javax/net/ssl/HostnameVerifier.java:46: Note: >>> Candidate functional interface >>> public interface HostnameVerifier { >>> ^ >>> jdk/src/share/classes/javax/net/ssl/HandshakeCompletedListener.java:44: >>> Note: Candidate functional interface >>> public interface HandshakeCompletedListener extends EventListener >>> ^ >>> jmx/management >>> ================ >>> >>> jdk/src/share/classes/java/lang/management/PlatformManagedObject.java:52: >>> Note: >>> Candidate functional interface >>> public interface PlatformManagedObject { >>> ^ >>> jdk/src/share/classes/java/lang/management/PlatformComponent.java:279: >>> Note: Candidate functional interface >>> interface MXBeanFetcher { >>> ^ >>> jdk/src/share/classes/java/lang/instrument/ClassFileTransformer.java:50: >>> Note: Candidate functional interface >>> public interface ClassFileTransformer { >>> ^ >>> jdk/src/share/classes/javax/management/openmbean/CompositeDataView.java:109: >>> >>> Note: Candidate functional interface >>> public interface CompositeDataView { >>> ^ >>> jdk/src/share/classes/javax/management/NotificationFilter.java:35: Note: >>> Candidate functional interface >>> public interface NotificationFilter extends java.io.Serializable { >>> ^ >>> jdk/src/share/classes/javax/management/remote/JMXAddressable.java:44: >>> Note: Candidate functional interface >>> public interface JMXAddressable { >>> ^ >>> jdk/src/share/classes/javax/management/remote/JMXAuthenticator.java:52: >>> Note: Candidate functional interface >>> public interface JMXAuthenticator { >>> ^ >>> jdk/src/share/classes/javax/management/remote/JMXConnectorServerProvider.java:42: >>> >>> Note: Candidate functional interface >>> public interface JMXConnectorServerProvider { >>> ^ >>> jdk/src/share/classes/javax/management/remote/JMXConnectorProvider.java:41: >>> >>> Note: Candidate functional interface >>> public interface JMXConnectorProvider { >>> ^ >>> jdk/src/share/classes/javax/management/NotificationListener.java:34: >>> Note: Candidate functional interface >>> public interface NotificationListener extends java.util.EventListener { >>> ^ >>> jdk/src/share/classes/javax/management/DescriptorRead.java:33: Note: >>> Candidate functional interface >>> public interface DescriptorRead { >>> ^ >>> concurrent - Assume this will be done first upstream in Doug's repos >>> ============ >>> >>> jdk/src/share/classes/java/util/concurrent/ThreadFactory.java:58: Note: >>> Candidate functional interface >>> public interface ThreadFactory { >>> ^ >>> jdk/src/share/classes/java/util/concurrent/ForkJoinPool.java:545: Note: >>> Candidate functional interface >>> public static interface ForkJoinWorkerThreadFactory { >>> ^ >>> jdk/src/share/classes/java/util/concurrent/RejectedExecutionHandler.java:44: >>> >>> Note: Candidate functional interface >>> public interface RejectedExecutionHandler { >>> ^ >>> jdk/src/share/classes/java/util/concurrent/Callable.java:57: Note: >>> Candidate functional interface >>> public interface Callable { >>> ^ >>> jdk/src/share/classes/java/util/concurrent/Executor.java:128: Note: >>> Candidate functional interface >>> public interface Executor { >>> > From Lance.Andersen at oracle.com Wed Feb 6 12:15:44 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 6 Feb 2013 07:15:44 -0500 Subject: review request: 8006505 additional updates for JSR 310 In-Reply-To: <5111A243.1070207@CoSoCo.de> References: <006D1601-CF80-476A-BC8A-C6B6B226C36F@oracle.com> <511190B7.2030703@CoSoCo.de> <24671E0D-2571-49A5-9873-B2471414096C@oracle.com> <5111A243.1070207@CoSoCo.de> Message-ID: <5BEA8602-1445-47A3-974B-E31E2D0AFB19@oracle.com> Thank you again for the feedback Ulf On Feb 5, 2013, at 7:22 PM, Ulf Zibis wrote: > Am 06.02.2013 00:54, schrieb Lance Andersen - Oracle: >> >> I can change that text and will do so before i put back. > > fine! I am going to change the message from "readObject not implemented" to "method readObject(Class) not implemented" As it was suggested to make it stand out from the other readObject method from another reviewer. I am just going to make the change then push later today > >>> Have you observed internal review ID of 2426775? >> I have not seen this come through as of yet but will let you know when I do. > > It was from 16.01.2013 15:19 +0100 That was for your comment with the SQLInput/OuputImpl classes: ... and starting idx by 0 instead -1 would not be so exotic I have not seen the issue in our internal tracking system (but have not gone looking for it either). And as I mentioned in my response to your suggestion, I will look at this after I wrap up other work for JDBC 4.2 and RowSet 1.2 Best Lance > > > -Ulf > -------------- 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 dmitry.samersoff at oracle.com Wed Feb 6 12:55:07 2013 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Wed, 06 Feb 2013 12:55:07 +0000 Subject: hg: jdk8/tl/jdk: 8007277: JDK-8002048 testcase fails to compile Message-ID: <20130206125528.1ADF547884@hg.openjdk.java.net> Changeset: 0e7d5dd84fdf Author: dsamersoff Date: 2013-02-06 16:53 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0e7d5dd84fdf 8007277: JDK-8002048 testcase fails to compile Summary: sun.* classes is not included to ct.sym file and symbol file have to be ignored Reviewed-by: alanb ! test/sun/management/jdp/JdpTest.sh From maurizio.cimadamore at oracle.com Wed Feb 6 14:05:34 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 06 Feb 2013 14:05:34 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20130206140542.3C41747886@hg.openjdk.java.net> Changeset: 1df20330f6bd Author: mcimadamore Date: 2013-02-06 14:03 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1df20330f6bd 8007463: Cleanup inference related classes Summary: Make Infer.InferenceContext an inner class; adjust bound replacement logic in Type.UndetVar Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.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/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/util/List.java ! test/tools/javac/generics/inference/7154127/T7154127.out ! test/tools/javac/lib/DPrinter.java Changeset: 8cdd96f2fdb9 Author: mcimadamore Date: 2013-02-06 14:04 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8cdd96f2fdb9 8007479: Refactor DeferredAttrContext so that it points to parent context Summary: Move DeferredAttrNode out of DeferredAttrContext; add support for nested deferred contexts Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java From Ulf.Zibis at CoSoCo.de Wed Feb 6 14:26:02 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Wed, 06 Feb 2013 15:26:02 +0100 Subject: review request: 8006505 additional updates for JSR 310 In-Reply-To: <5BEA8602-1445-47A3-974B-E31E2D0AFB19@oracle.com> References: <006D1601-CF80-476A-BC8A-C6B6B226C36F@oracle.com> <511190B7.2030703@CoSoCo.de> <24671E0D-2571-49A5-9873-B2471414096C@oracle.com> <5111A243.1070207@CoSoCo.de> <5BEA8602-1445-47A3-974B-E31E2D0AFB19@oracle.com> Message-ID: <511267FA.7080007@CoSoCo.de> Am 06.02.2013 13:15, schrieb Lance Andersen - Oracle: > I am going to change the message from > > "readObject not implemented" > > to "method readObject(Class) not implemented" There is 1 % missing to be perfect: "method T readObject(Class type) not implemented" ;-) I was also thinking about this 100 % message, but I thought, exception messages should not be so talkative/verbose. Additionally reduces class footprint and CPU cycles. > As it was suggested to make it stand out from the other readObject method from another reviewer. And thinking again, I think, that: "SQLFeatureNotSupportedException at package.MyClass.callsite(MyClass.java:123) would be clear enough, no big difference between "...NotSupported..." and "... not implemented". In any case, the developer has to look at the call site at MyClass.java:123, where he clearly will see, which method is not supported/implemented, ... so empty exception message should suffice here. > I am just going to make the change then push later today >>>> Have you observed internal review ID of 2426775? >>> I have not seen this come through as of yet but will let you know when I do. >> It was from 16.01.2013 15:19 +0100 > That was for your comment with the SQLInput/OuputImpl classes: > > > ... and starting idx by 0 instead -1 would not be so exotic This was only an aside remark, the main justification for my bug report is, that I still think, method T readObject(Class type) is completely superfluous, if we generify the existing method. > I have not seen the issue in our internal tracking system (but have not gone looking for it either). And as I mentioned in my response to your suggestion, I will look at this after I wrap up other work for JDBC 4.2 and RowSet 1.2 OK, I attach the report here: Date Created: Wed Jan 16 07:19:27 MST 2013 Type: rfe Customer Name: Ulf Zibis Customer Email:Ulf.Zibis at CoSoCo.de SDN ID: status: Waiting Category: java Subcategory: jdbc Company: CoSoCo release: 7 hardware: x86 OSversion: win_xp priority: 4 Synopsis: Generic accessors to SQLInput, SQLOutput Description: A DESCRIPTION OF THE REQUEST : Currently, interfaces SQLInput, SQLOutput provide plenty accessors for distinct type, and one general read/writeObject(). The latter could be generified to cover all other non-primitive types, with the effect pushing the root of a possible ClassCastException to the call site layer. The non-primitive distinct ones could be deprecated. JUSTIFICATION : - general convenience - save the additional external cast for readObject() - in the javax.sql.rowset.serial implementation, the dictinct accessors could internally cause a ClassCastException, which would be unfathomable for users - less code to maintain, especially for future extensions EXPECTED VERSUS ACTUAL BEHAVIOR : EXPECTED - E.G.: boolean bb = sqlInput.readBoolean(); Boolean b = sqlInput.readObject(); String s = sqlInput.readObject(); Blob bl = sqlInput.readObject(); ... ACTUAL - E.G.: boolean bb = sqlInput.readBoolean(); Boolean b = (Boolean)sqlInput.readObject(); String s = sqlInput.readString(); Blob bl = sqlInput.readBlob(); ... ---------- BEGIN SOURCE ---------- proposed source changes for javax.sql.rowset.serial.SQLInputImpl private int idx = 0; // init with 0 instead -1 private Object attribs[]; // rename attrib to attribs public boolean readBoolean() throws SQLException { Boolean attrib = readObject(); // replace old (Boolean)getNextAttribute() return (attrib == null) ? false : attrib.booleanValue(); } public T readObject() throws SQLException { if (idx >= attribs.length) { throw new SQLException("SQLInputImpl exception: Invalid read " + "position"); } T attrib = (T)attribs[idx++]; lastValueWasNull = attrib == null; if (attrib instanceof Struct) { ... // maybe move to extra method to enhance possibility ... // for JIT to compile + inline the main path ... } return attrib; } ---------- END SOURCE ---------- workaround: comments: (company - CoSoCo , email -Ulf.Zibis at CoSoCo.de) -Ulf From john.zavgren at oracle.com Wed Feb 6 14:57:03 2013 From: john.zavgren at oracle.com (John Zavgren) Date: Wed, 6 Feb 2013 06:57:03 -0800 (PST) Subject: RFR JDK-8007609 Message-ID: Alan: I like your change, but I think the free(result) statement would need to be eliminated, otherwise the block a few lines later: /* Unable to get final path. */ if(len == 0 && result != NULL) { free(result); result = NULL; } would cause result to be freed twice.
----- Original Message -----
From: Alan.Bateman at oracle.com
To: john.zavgren at oracle.com
Cc: core-libs-dev at openjdk.java.net
Sent: Wednesday, February 6, 2013 5:18:28 AM GMT -05:00 US/Canada Eastern
Subject: Re: RFR JDK-8007609

On 05/02/2013 23:49, John Zavgren wrote: 
Greetings:

I modified the code in 
src/windows/native/java/io/WinNTFileSystem_md.c
so that it checks the return value of realloc() and frees memory when there is an error.

The webrev image of this change is visible at:
http://cr.openjdk.java.net/~jzavgren/8007609/webrev.01/

Thanks!
John Zavgren
Formatting aside, it looks like the change means that a realloc fail will leave the file open. I think this is all that is needed:

WCHAR* newResult = (WCHAR*)realloc(...);
if (newResult != NULL) {
    len = (*GetFinalPathNameByHandle_func)( h, newResult, len, 0);
} else {
    free(result);
    len = 0;
}
result = newResult;

-Alan.
From john.zavgren at oracle.com Wed Feb 6 14:59:54 2013 From: john.zavgren at oracle.com (John Zavgren) Date: Wed, 6 Feb 2013 06:59:54 -0800 (PST) Subject: RFR JDK-8007609 Message-ID: <6c95a4ea-d5fa-4e8f-9e94-9dab3962930c@default> Alan: I apologize... I read the code again and I don't see any issues with your change. John ----- Original Message ----- From: john.zavgren at oracle.com To: Alan.Bateman at oracle.com Cc: core-libs-dev at openjdk.java.net Sent: Wednesday, February 6, 2013 9:57:03 AM GMT -05:00 US/Canada Eastern Subject: Re: RFR JDK-8007609 Alan: I like your change, but I think the free(result) statement would need to be eliminated, otherwise the block a few lines later: /* Unable to get final path. */ if(len == 0 && result != NULL) { free(result); result = NULL; } would cause result to be freed twice. ----- Original Message ----- From: Alan.Bateman at oracle.com To: john.zavgren at oracle.com Cc: core-libs-dev at openjdk.java.net Sent: Wednesday, February 6, 2013 5:18:28 AM GMT -05:00 US/Canada Eastern Subject: Re: RFR JDK-8007609 On 05/02/2013 23:49, John Zavgren wrote: Greetings: I modified the code in src/windows/native/java/io/WinNTFileSystem_md.c so that it checks the return value of realloc() and frees memory when there is an error. The webrev image of this change is visible at: http://cr.openjdk.java.net/~jzavgren/8007609/webrev.01/ Thanks! John Zavgren Formatting aside, it looks like the change means that a realloc fail will leave the file open. I think this is all that is needed: WCHAR* newResult = (WCHAR*)realloc(...); if (newResult != NULL) { len = (*GetFinalPathNameByHandle_func)( h, newResult, len, 0); } else { free(result); len = 0; } result = newResult; -Alan. From Alan.Bateman at oracle.com Wed Feb 6 15:02:28 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 06 Feb 2013 15:02:28 +0000 Subject: RFR JDK-8007609 In-Reply-To: References: Message-ID: <51127084.3080206@oracle.com> On 06/02/2013 14:57, John Zavgren wrote: > Alan: I like your change, but I think the free(result) statement would > need to be eliminated, otherwise the block a few lines later: /* > Unable to get final path. */ if(len == 0 && result != NULL) { > free(result); result = NULL; } would cause result to be freed twice. Shouldn't do because result = newResult and so will be NULL. An alternative would be: WCHAR* newResult = (WCHAR*)realloc(...); if (newResult != NULL) { result = newResult; len = (*GetFinalPathNameByHandle_func)( h, result, len, 0); } else { len = 0; } which might be clearer. -Alan. From Lance.Andersen at oracle.com Wed Feb 6 15:20:49 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 6 Feb 2013 10:20:49 -0500 Subject: review request: 8006505 additional updates for JSR 310 In-Reply-To: <511267FA.7080007@CoSoCo.de> References: <006D1601-CF80-476A-BC8A-C6B6B226C36F@oracle.com> <511190B7.2030703@CoSoCo.de> <24671E0D-2571-49A5-9873-B2471414096C@oracle.com> <5111A243.1070207@CoSoCo.de> <5BEA8602-1445-47A3-974B-E31E2D0AFB19@oracle.com> <511267FA.7080007@CoSoCo.de> Message-ID: On Feb 6, 2013, at 9:26 AM, Ulf Zibis wrote: > > Am 06.02.2013 13:15, schrieb Lance Andersen - Oracle: >> I am going to change the message from >> >> "readObject not implemented" >> >> to "method readObject(Class) not implemented" > > There is 1 % missing to be perfect: "method T readObject(Class type) not implemented" ;-) Yes I was aware of that :-) > I was also thinking about this 100 % message, but I thought, exception messages should not be so talkative/verbose. Additionally reduces class footprint and CPU cycles. > >> As it was suggested to make it stand out from the other readObject method from another reviewer. > > And thinking again, I think, that: > "SQLFeatureNotSupportedException at package.MyClass.callsite(MyClass.java:123) > would be clear enough, no big difference between "...NotSupported..." and "... not implemented". > > In any case, the developer has to look at the call site at MyClass.java:123, where he clearly will see, which method is not supported/implemented, ... so empty exception message should suffice here. I do not have a strong preference here so to keep things simple, I will remove the message and move on. > >> I am just going to make the change then push later today >>>>> Have you observed internal review ID of 2426775? >>>> I have not seen this come through as of yet but will let you know when I do. >>> It was from 16.01.2013 15:19 +0100 >> That was for your comment with the SQLInput/OuputImpl classes: >> >> >> ... and starting idx by 0 instead -1 would not be so exotic > > This was only an aside remark, the main justification for my bug report is, that I still think, method T readObject(Class type) is completely superfluous, if we generify the existing method. There is a difference between the *Impl classes which is used only by RowSet RI and these interfaces. And in all actuality, the original RowSet authors made a mistake to not put the impl method in the com.sun.rowset namespace. > >> I have not seen the issue in our internal tracking system (but have not gone looking for it either). And as I mentioned in my response to your suggestion, I will look at this after I wrap up other work for JDBC 4.2 and RowSet 1.2 > > OK, I attach the report here: Thanks for including, I will revisit this later as I mentioned. Best Lance > > Date Created: Wed Jan 16 07:19:27 MST 2013 > Type: rfe > Customer Name: Ulf Zibis > Customer Email:Ulf.Zibis at CoSoCo.de > SDN ID: > status: Waiting > Category: java > Subcategory: jdbc > Company: CoSoCo > release: 7 > hardware: x86 > OSversion: win_xp > priority: 4 > Synopsis: Generic accessors to SQLInput, SQLOutput > Description: > A DESCRIPTION OF THE REQUEST : > Currently, interfaces SQLInput, SQLOutput provide plenty accessors for distinct type, and one general read/writeObject(). > The latter could be generified to cover all other non-primitive types, with the effect pushing the root of a possible ClassCastException to the call site layer. > The non-primitive distinct ones could be deprecated. > > JUSTIFICATION : > - general convenience > - save the additional external cast for readObject() > - in the javax.sql.rowset.serial implementation, the dictinct accessors could internally cause a ClassCastException, which would be unfathomable for users > - less code to maintain, especially for future extensions > > > EXPECTED VERSUS ACTUAL BEHAVIOR : > EXPECTED - > E.G.: > boolean bb = sqlInput.readBoolean(); > Boolean b = sqlInput.readObject(); > String s = sqlInput.readObject(); > Blob bl = sqlInput.readObject(); > ... > > ACTUAL - > E.G.: > boolean bb = sqlInput.readBoolean(); > Boolean b = (Boolean)sqlInput.readObject(); > String s = sqlInput.readString(); > Blob bl = sqlInput.readBlob(); > ... > > > ---------- BEGIN SOURCE ---------- > proposed source changes for javax.sql.rowset.serial.SQLInputImpl > > private int idx = 0; // init with 0 instead -1 > > private Object attribs[]; // rename attrib to attribs > > public boolean readBoolean() throws SQLException { > Boolean attrib = readObject(); // replace old (Boolean)getNextAttribute() > return (attrib == null) ? false : attrib.booleanValue(); > } > > public T readObject() throws SQLException { > if (idx >= attribs.length) { > throw new SQLException("SQLInputImpl exception: Invalid read " + > "position"); > } > T attrib = (T)attribs[idx++]; > lastValueWasNull = attrib == null; > if (attrib instanceof Struct) { > ... // maybe move to extra method to enhance possibility > ... // for JIT to compile + inline the main path > ... > } > return attrib; > } > > > ---------- END SOURCE ---------- > workaround: > comments: (company - CoSoCo , email -Ulf.Zibis at CoSoCo.de) > > > > -Ulf > > -------------- 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 Alan.Bateman at oracle.com Wed Feb 6 15:37:28 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 06 Feb 2013 15:37:28 +0000 Subject: RFR : 8006594/8006595 : Define jdk_core test set In-Reply-To: <80B155BF-B2E3-40C5-BE86-B0D29F1C4F5C@oracle.com> References: <216D5987-F917-473E-98EF-C84BAB302C53@oracle.com> <50FFF51B.1030809@oracle.com> <04B58247-CBCC-4825-8CC8-38236442E24A@oracle.com> <510FBD81.4050709@oracle.com> <71B03773-1288-40C0-98E5-137EC2B7F509@oracle.com> <510FE2BD.4080401@oracle.com> <80B155BF-B2E3-40C5-BE86-B0D29F1C4F5C@oracle.com> Message-ID: <511278B8.3080908@oracle.com> On 05/02/2013 20:10, Mike Duigou wrote: > On Feb 4 2013, at 08:33 , Alan Bateman wrote: > >> On 04/02/2013 16:02, Mike Duigou wrote: >>> : >>>> If so then I think we have to careful because -concurrency means a lot of virtual memory and I'm not convinced that we limit it via -vmoption in jdk/test/Makefile >>>> I could see us wanting to dial this down on 32-bit Windows for example. >>> We do limit the max size via -Xmx512M which does seem quite small and is generally well balanced with the number of cores. >>> >>> I opened a build/infrastructure issue to have MEMORY_SIZE and perhaps some suggested VM sizes recorded to the spec.gmk I planned to revisit this again once only new build is supported. >> My reading of the make file is that -J-Xmx512m is passed to jtreg and so it's the maximum heap size of the jtreg process, not the agent VMs running tests. If we are turning on concurrency then it will need -vmoption:-Xmx512m too, otherwise you risk each agent reserving 1/4 of physical memory. In addition, limited virtual memory on Windows 32-bit will limit the number of agent VMs that you can run and so $(JOBS) may be too much. You might need to limit it to 2 or 3 on Windows 32-bit. > OK, that is my misunderstanding. I thought it was being applied to both the jtreg vm and the test vms. I think for now I will just remove concurrent rather than try to set VM sizing. > No problem, it's not obvious. Maurizio and I were looking at the Makefile in langtools recently and we noticed the same thing, since then it has been updated by Vincente to specify -vmoption. I think we should do the same in jdk/test/Makefile and I think 512m is about right (the temptation is to set it higher but there are a lot of tests in the jdk repo that are othervm tests so actual number of VMs running can be *2, or even more when multi-process tests are run. This can of course be something for another update, and I'm okay with the other changes in the last webrev. -Alan From yekaterina.kantserova at oracle.com Wed Feb 6 15:40:23 2013 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 06 Feb 2013 16:40:23 +0100 Subject: RFR (S) 8007142: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <5110F304.4080602@oracle.com> References: <510BB12C.2030802@oracle.com> <510BB5CC.6050604@oracle.com> <510BC3E0.6020107@oracle.com> <510BCF1B.3010704@oracle.com> <510BD9EF.1050202@oracle.com> <510BDCAA.1080909@oracle.com> <510F8E6C.2090301@oracle.com> <510F9393.8080509@oracle.com> <510F9596.8060503@oracle.com> <510FB531.8040407@oracle.com> <5110E434.40600@oracle.com> <5110F304.4080602@oracle.com> Message-ID: <51127967.6040908@oracle.com> Alan, thanks for the review! // Katja On 02/05/2013 12:54 PM, Alan Bateman wrote: > On 05/02/2013 10:51, Yekaterina Kantserova wrote: >> On 02/04/2013 02:18 PM, Alan Bateman wrote: >>> On 04/02/2013 11:03, Yekaterina Kantserova wrote: >>>> >>>> But JDKToolFinder.getJDKTool is used even for finding java, e.g. I >>>> need to fork a java process - JDKToolFinder.getJDKTool("java") for >>>> some JRE tests? >>> It might be better to rename JDKToolFinder to something like >>> JdkFinder and have it define getJavaLauncher() and getTool(String >>> tool) methods. >> I think it's good idea to separate java launcher and tools. Here is >> the new JdkFinder: >> http://cr.openjdk.java.net/~ykantser/8007142/webrev.02/test/lib/testlibrary/jdk/testlibrary/JdkFinder.java.html. >> It now possible to retrieve java/tools both from the test.jdk and >> compile.jdk. >> >>> If you don't agree then you could at least change >>> ProcessTools.createJavaProcessBuilder so that it looks like "java" >>> in the JDK/JRE under test. >>> >> JDKToolFinder.getJDKTool("java") became JdkFinder.getJavaLauncher in >> the createJavaProcessBuilder >> (http://cr.openjdk.java.net/~ykantser/8007142/webrev.02/test/lib/testlibrary/jdk/testlibrary/ProcessTools.java.html). >>> -Alan. >> > It looks right to me now. > > -Alan From jonathan.gibbons at oracle.com Wed Feb 6 15:49:53 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 06 Feb 2013 15:49:53 +0000 Subject: hg: jdk8/tl/langtools: 8007566: DocLint too aggressive with not allowed here:

Message-ID: <20130206154958.3AFE04788A@hg.openjdk.java.net> Changeset: 153d20d0cac5 Author: jjg Date: 2013-02-06 07:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/153d20d0cac5 8007566: DocLint too aggressive with not allowed here:

Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/doclint/Checker.java + test/tools/doclint/ParaTagTest.java From fweimer at redhat.com Wed Feb 6 16:20:34 2013 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 06 Feb 2013 17:20:34 +0100 Subject: geteuid(2) in java? In-Reply-To: <510F84A0.1000903@oracle.com> References: <510F576D.6060805@oracle.com> <510F84A0.1000903@oracle.com> Message-ID: <511282D2.3050609@redhat.com> On 02/04/2013 10:51 AM, Alan Bateman wrote: > On 04/02/2013 06:38, Weijun Wang wrote: >> Need an equivalence of the geteuid() function that returns the >> effective user ID of the calling process. > There isn't an API for this. And Hotspot really shouldn't be used from processes with EUID != UID. -- Florian Weimer / Red Hat Product Security Team From christos at zoulas.com Wed Feb 6 16:26:27 2013 From: christos at zoulas.com (Christos Zoulas) Date: Wed, 6 Feb 2013 11:26:27 -0500 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <51122AC8.2070400@oracle.com> from Chris Hegarty (Feb 6, 10:04am) Message-ID: <20130206162627.4080E97129@rebar.astron.com> On Feb 6, 10:04am, chris.hegarty at oracle.com (Chris Hegarty) wrote: -- Subject: Re: RFR: race with nested repos in hgforest.sh | Yes this is better, but the quotes are incorrect. It should simply be | for rc in ${tmp}/*.pid.rc ; do This will break if there is no match. christos From neil.richards at ngmr.net Wed Feb 6 16:51:15 2013 From: neil.richards at ngmr.net (Neil Richards) Date: Wed, 06 Feb 2013 16:51:15 +0000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <51123363.8080606@oracle.com> References: <510BD3E6.1090103@oracle.com> <5110A4EC.1050907@oracle.com> <51111228.5010707@oracle.com> <5111B7A4.8040902@oracle.com> <51122AC8.2070400@oracle.com> <51122F74.4000301@oracle.com> <51123363.8080606@oracle.com> Message-ID: <1360169475.24601.185.camel@chalkhill> fwiw, I've always found the attempts by hg_forest to process things in parallel cause me more pain than it's worth. Marching through the repo locations serially in order might take a few moments longer elapsed time, but creates instantly understandable status / output / log and points for returning sensible errors when things don't succeed. Doing so also reduces the burst load on the server (it has to deal with one request per invocation at any time, rather than five? (or more)), which also strikes me as a win. (There are times that my 'hg pull' requests get momentarily rebuffed by the OpenJDK server, in a manner that suggests to me it's getting flooded by such requests). Obviously, figuring out how to do everything properly in parallel is a lot more fun :) ... but I don't think this script is there yet, and I wonder if the KISS principle shouldn't apply here. Regards, Neil On Wed, 2013-02-06 at 10:41 +0000, Chris Hegarty wrote: > > On 06/02/2013 10:24, David Holmes wrote: > > Thanks Chris. I missed a couple of obvious things there. :( > > > > One thing related to the repo name in the $(rc) variable. Somewhere the > > repo name gets mangled: > > > > + echo jdk/src/closed > > + sed -e s at ./@@ -e s@/@_ at g > > + repopidfile=jdsrc_closed > > > > the / to _ doesn't work for the first / (not part of your fix though). > > > > I must say though that this bug still has me perplexed. I ran with set > > -x and observed the following. Given: > > > > # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed > > jdk/make/closed jdk/test/closed hotspot/make/closed > > hotspot/src/closed hotspot/test/closed deploy install sponsors pubs > > > > The first clone I see is corba and the second is jdk/make/closed. The > > very last clone I see is jdk. BUT there was no error creating the > > sub-repos before the enclosing repo! ??? Makes no sense. > > I only see the problem when running with old versions of hg. More recent > ones seem to be immune to it. I guess they must do something equivalent > to 'mkdir -p' on the destination directory. > > Blocking the clone of the nested repos until the enclosing repo creates > the holding directory seems like a small price to pay for such an > obscure bug. > > Also, now returning an error code when something fails should help avoid > any future issues of missing or out of date repos. > > -Chris. > > > > > David > > ----- > > > > On 6/02/2013 8:04 PM, Chris Hegarty wrote: > >> Thank for the review. comments inline... > >> > >> On 06/02/2013 01:53, David Holmes wrote: > >>> 204 # Terminate with exit 0 only if all subprocesses were successful > >>> 205 ec=0 > >>> 206 if [ -d ${tmp} ]; then > >>> 207 for rc in `ls ${tmp}/*.pid.rc` ; do > >>> > >>> I don't think you need to subshell an invocation of ls, simply do > >>> > >>> for rc in "${tmp}/*.pid.rc" ; do > >> > >> Yes this is better, but the quotes are incorrect. It should simply be > >> for rc in ${tmp}/*.pid.rc ; do > >> > >>> 208 exit_code=`cat ${rc} | tr -d ' \n\r'` > >>> 209 if [ "${exit_code}" != "0" ] ; then > >>> 210 echo "WARNING: ${rc} exited abnormally." > >>> > >>> Not sure printing ${rc} will be very informative there ?? > >> > >> It prints the file name which contains the subrepo name. Not pretty, but > >> this gives more information about which clone/pull failed. > >> > >>> 211 ec=1 > >>> > >>> Is there a "break" we can add here? > >> > >> Yes, we could break out/exit early, but I deliberately want to iterator > >> over all the child process exits codes to better highlight which ones, > >> if more than one, failed. > >> > >>> In get_source.sh > >>> > >>> # Get clones of all nested repositories > >>> ! sh ./common/bin/hgforest.sh clone "$@" || exit 1 > >>> > >>> # Update all existing repositories to the latest sources > >>> sh ./common/bin/hgforest.sh pull -u > >>> > >>> don't we want "|| exit 1" for the pull case as well? > >> > >> Since the pull is the last command there is no need for "|| exit 1", > >> since its exit code will be returned. > >> > >> -Chris. > >> > >>> > >>> Thanks, > >>> David > >>> > >>> On 6/02/2013 12:07 AM, Chris Hegarty wrote: > >>>> On 02/05/2013 06:21 AM, David Holmes wrote: > >>>>> Chris, > >>>>> > >>>>> When these failures occur does the failure get reflected in an error > >>>>> exit code? > >>>> > >>>> Not currently, good point. > >>>> > >>>>> I'm seeing hudson builds merilly buildinh OpenJDK instead of Oracle > >>>>> JDK > >>>>> because the closed repos were skipped due to this bug :( > >>>> > >>>> This is what I am seeing too, and the reason I proposed a patch to > >>>> resolve it. > >>>> > >>>> Updated webrev; > >>>> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ > >>>> > >>>> 1) now checks, and returns, appropriate error code, so that higher > >>>> level scripts can determine if it completed successfully > >>>> 2) Added diagnostic error message to help identify potential future > >>>> problems if a nested repo is blocked for too long > >>>> > >>>> -Chris. > >>>> > >>>>> > >>>>> David > >>>>> > >>>>> On 2/02/2013 12:40 AM, Chris Hegarty wrote: > >>>>>> [ to build-dev and core-libs-dev, expect reviewer from either, but > >>>>>> will > >>>>>> integrate through jdk8/tl ] > >>>>>> > >>>>>> This issue is mainly of interest to Oracle engineers, but it effects > >>>>>> the > >>>>>> public hgforest script. > >>>>>> > >>>>>> When hgforest.sh is run with an addition argument to specify a closed > >>>>>> server, there is a problem/race between the creation of the > >>>>>> directories > >>>>>> to hold nested repositories and the clone itself. These directories > >>>>>> need > >>>>>> to be created before the clone command is executed, otherwise it will > >>>>>> fail, as below. > >>>>>> > >>>>>> The trivial fix is to back off these nested repos until their > >>>>>> containing > >>>>>> directory exists. > >>>>>> > >>>>>> Webrev: > >>>>>> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ > >>>>>> > >>>>>> sh ./get_source.sh http://xxx.yyy.oracle.com | & tee clone.log > >>>>>> # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed > >>>>>> jdk/make/closed jdk/test/closed hotspot/make/closed > >>>>>> hotspot/src/closed > >>>>>> hotspot/test/closed deploy install sponsors pubs > >>>>>> > >>>>>> Waiting 5 secs before spawning next background command. > >>>>>> Waiting 5 secs before spawning next background command. > >>>>>> Waiting 5 secs before spawning next background command. > >>>>>> jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u > >>>>>> /java/devtools/sparc/mercurial/latest/bin/hg clone > >>>>>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed > >>>>>> jdk/src/closed: abort: No such file or directory: jdk/src/closed > >>>>>> jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u > >>>>>> /java/devtools/sparc/mercurial/latest/bin/hg clone > >>>>>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed > >>>>>> jdk/make/closed: abort: No such file or directory: jdk/make/closed > >>>>>> Waiting 5 secs before spawning next background command. > >>>>>> .... > >>>>>> > >>>>>> > >>>>>> -Chris. -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From chris.hegarty at oracle.com Wed Feb 6 17:03:36 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 06 Feb 2013 17:03:36 +0000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <1360169475.24601.185.camel@chalkhill> References: <510BD3E6.1090103@oracle.com> <5110A4EC.1050907@oracle.com> <51111228.5010707@oracle.com> <5111B7A4.8040902@oracle.com> <51122AC8.2070400@oracle.com> <51122F74.4000301@oracle.com> <51123363.8080606@oracle.com> <1360169475.24601.185.camel@chalkhill> Message-ID: <51128CE8.7090606@oracle.com> Neil, I think a wider discussion needs to be had around how this script should operate, but I didn't want this specific issue to get side tracked by that. The hgforest script already clones/pulls in parallel, the problem here is that it just doesn't work with older versions of hg. And worse than that doesn't even return an error. I simply want to resolve this issue so that the script is once again useable. If there is an issue with parallel clones/pulls, then we should consider that separately. -Chris. On 06/02/2013 16:51, Neil Richards wrote: > fwiw, I've always found the attempts by hg_forest to process things in > parallel cause me more pain than it's worth. > > Marching through the repo locations serially in order might take a few > moments longer elapsed time, but creates instantly understandable > status / output / log and points for returning sensible errors when > things don't succeed. > > Doing so also reduces the burst load on the server (it has to deal with > one request per invocation at any time, rather than five? (or more)), > which also strikes me as a win. > > (There are times that my 'hg pull' requests get momentarily rebuffed by > the OpenJDK server, in a manner that suggests to me it's getting flooded > by such requests). > > Obviously, figuring out how to do everything properly in parallel is a > lot more fun :) ... > but I don't think this script is there yet, and I wonder if the KISS > principle shouldn't apply here. > > Regards, > Neil > > On Wed, 2013-02-06 at 10:41 +0000, Chris Hegarty wrote: >> >> On 06/02/2013 10:24, David Holmes wrote: >>> Thanks Chris. I missed a couple of obvious things there. :( >>> >>> One thing related to the repo name in the $(rc) variable. Somewhere the >>> repo name gets mangled: >>> >>> + echo jdk/src/closed >>> + sed -e s at ./@@ -e s@/@_ at g >>> + repopidfile=jdsrc_closed >>> >>> the / to _ doesn't work for the first / (not part of your fix though). >>> >>> I must say though that this bug still has me perplexed. I ran with set >>> -x and observed the following. Given: >>> >>> # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed >>> jdk/make/closed jdk/test/closed hotspot/make/closed >>> hotspot/src/closed hotspot/test/closed deploy install sponsors pubs >>> >>> The first clone I see is corba and the second is jdk/make/closed. The >>> very last clone I see is jdk. BUT there was no error creating the >>> sub-repos before the enclosing repo! ??? Makes no sense. >> >> I only see the problem when running with old versions of hg. More recent >> ones seem to be immune to it. I guess they must do something equivalent >> to 'mkdir -p' on the destination directory. >> >> Blocking the clone of the nested repos until the enclosing repo creates >> the holding directory seems like a small price to pay for such an >> obscure bug. >> >> Also, now returning an error code when something fails should help avoid >> any future issues of missing or out of date repos. >> >> -Chris. >> >>> >>> David >>> ----- >>> >>> On 6/02/2013 8:04 PM, Chris Hegarty wrote: >>>> Thank for the review. comments inline... >>>> >>>> On 06/02/2013 01:53, David Holmes wrote: >>>>> 204 # Terminate with exit 0 only if all subprocesses were successful >>>>> 205 ec=0 >>>>> 206 if [ -d ${tmp} ]; then >>>>> 207 for rc in `ls ${tmp}/*.pid.rc` ; do >>>>> >>>>> I don't think you need to subshell an invocation of ls, simply do >>>>> >>>>> for rc in "${tmp}/*.pid.rc" ; do >>>> >>>> Yes this is better, but the quotes are incorrect. It should simply be >>>> for rc in ${tmp}/*.pid.rc ; do >>>> >>>>> 208 exit_code=`cat ${rc} | tr -d ' \n\r'` >>>>> 209 if [ "${exit_code}" != "0" ] ; then >>>>> 210 echo "WARNING: ${rc} exited abnormally." >>>>> >>>>> Not sure printing ${rc} will be very informative there ?? >>>> >>>> It prints the file name which contains the subrepo name. Not pretty, but >>>> this gives more information about which clone/pull failed. >>>> >>>>> 211 ec=1 >>>>> >>>>> Is there a "break" we can add here? >>>> >>>> Yes, we could break out/exit early, but I deliberately want to iterator >>>> over all the child process exits codes to better highlight which ones, >>>> if more than one, failed. >>>> >>>>> In get_source.sh >>>>> >>>>> # Get clones of all nested repositories >>>>> ! sh ./common/bin/hgforest.sh clone "$@" || exit 1 >>>>> >>>>> # Update all existing repositories to the latest sources >>>>> sh ./common/bin/hgforest.sh pull -u >>>>> >>>>> don't we want "|| exit 1" for the pull case as well? >>>> >>>> Since the pull is the last command there is no need for "|| exit 1", >>>> since its exit code will be returned. >>>> >>>> -Chris. >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 6/02/2013 12:07 AM, Chris Hegarty wrote: >>>>>> On 02/05/2013 06:21 AM, David Holmes wrote: >>>>>>> Chris, >>>>>>> >>>>>>> When these failures occur does the failure get reflected in an error >>>>>>> exit code? >>>>>> >>>>>> Not currently, good point. >>>>>> >>>>>>> I'm seeing hudson builds merilly buildinh OpenJDK instead of Oracle >>>>>>> JDK >>>>>>> because the closed repos were skipped due to this bug :( >>>>>> >>>>>> This is what I am seeing too, and the reason I proposed a patch to >>>>>> resolve it. >>>>>> >>>>>> Updated webrev; >>>>>> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >>>>>> >>>>>> 1) now checks, and returns, appropriate error code, so that higher >>>>>> level scripts can determine if it completed successfully >>>>>> 2) Added diagnostic error message to help identify potential future >>>>>> problems if a nested repo is blocked for too long >>>>>> >>>>>> -Chris. >>>>>> >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On 2/02/2013 12:40 AM, Chris Hegarty wrote: >>>>>>>> [ to build-dev and core-libs-dev, expect reviewer from either, but >>>>>>>> will >>>>>>>> integrate through jdk8/tl ] >>>>>>>> >>>>>>>> This issue is mainly of interest to Oracle engineers, but it effects >>>>>>>> the >>>>>>>> public hgforest script. >>>>>>>> >>>>>>>> When hgforest.sh is run with an addition argument to specify a closed >>>>>>>> server, there is a problem/race between the creation of the >>>>>>>> directories >>>>>>>> to hold nested repositories and the clone itself. These directories >>>>>>>> need >>>>>>>> to be created before the clone command is executed, otherwise it will >>>>>>>> fail, as below. >>>>>>>> >>>>>>>> The trivial fix is to back off these nested repos until their >>>>>>>> containing >>>>>>>> directory exists. >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~chegar/hgforest_nestedRepos/webrev/ >>>>>>>> >>>>>>>> sh ./get_source.sh http://xxx.yyy.oracle.com |& tee clone.log >>>>>>>> # Repositories: corba jaxp jaxws langtools jdk hotspot jdk/src/closed >>>>>>>> jdk/make/closed jdk/test/closed hotspot/make/closed >>>>>>>> hotspot/src/closed >>>>>>>> hotspot/test/closed deploy install sponsors pubs >>>>>>>> >>>>>>>> Waiting 5 secs before spawning next background command. >>>>>>>> Waiting 5 secs before spawning next background command. >>>>>>>> Waiting 5 secs before spawning next background command. >>>>>>>> jdk/src/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>>>>>>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>>>>>>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/src/closed jdk/src/closed >>>>>>>> jdk/src/closed: abort: No such file or directory: jdk/src/closed >>>>>>>> jdk/make/closed: /java/devtools/sparc/mercurial/0.9.5/bin/python -u >>>>>>>> /java/devtools/sparc/mercurial/latest/bin/hg clone >>>>>>>> http://xxx.yyy.oracle.com/jdk8/tl/jdk/make/closed jdk/make/closed >>>>>>>> jdk/make/closed: abort: No such file or directory: jdk/make/closed >>>>>>>> Waiting 5 secs before spawning next background command. >>>>>>>> .... >>>>>>>> >>>>>>>> >>>>>>>> -Chris. > > From chris.hegarty at oracle.com Wed Feb 6 17:59:00 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 6 Feb 2013 17:59:00 +0000 Subject: RFR: race with nested repos in hgforest.sh In-Reply-To: <20130206162627.4080E97129@rebar.astron.com> References: <20130206162627.4080E97129@rebar.astron.com> Message-ID: <87AF0D9E-8DEB-4CC0-84F3-83B83A1774DD@oracle.com> On 6 Feb 2013, at 16:26, christos at zoulas.com wrote: > On Feb 6, 10:04am, chris.hegarty at oracle.com (Chris Hegarty) wrote: > -- Subject: Re: RFR: race with nested repos in hgforest.sh > > | Yes this is better, but the quotes are incorrect. It should simply be > | for rc in ${tmp}/*.pid.rc ; do > > This will break if there is no match. This should never happen, but I agree the code could be more robust. -Chris > > christos From mike.duigou at oracle.com Wed Feb 6 19:10:06 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 06 Feb 2013 19:10:06 +0000 Subject: hg: jdk8/tl: 8004726: Link bug ids to jbs rather than monaco. Message-ID: <20130206191006.2B1DB47894@hg.openjdk.java.net> Changeset: 168dd033604a Author: mduigou Date: 2013-02-06 11:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/168dd033604a 8004726: Link bug ids to jbs rather than monaco. Reviewed-by: ohair, chegar, katleman ! make/scripts/webrev.ksh From lance.andersen at oracle.com Wed Feb 6 19:15:39 2013 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Wed, 06 Feb 2013 19:15:39 +0000 Subject: hg: jdk8/tl/jdk: 8006505: additional changes for JSR 310 support Message-ID: <20130206191600.8C06347896@hg.openjdk.java.net> Changeset: 1574fa3df1c0 Author: lancea Date: 2013-02-06 14:15 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1574fa3df1c0 8006505: additional changes for JSR 310 support Reviewed-by: naoto, ulfzibis ! src/share/classes/java/sql/JDBCType.java ! src/share/classes/java/sql/SQLInput.java ! src/share/classes/java/sql/SQLOutput.java ! src/share/classes/java/sql/Types.java From joe.darcy at oracle.com Wed Feb 6 19:19:56 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 06 Feb 2013 11:19:56 -0800 Subject: JDK 8 code review request for 8005623: Retrofit FunctionalInterface annotations to core platform interfaces In-Reply-To: <51121A4D.3070207@oracle.com> References: <511184BF.9040202@oracle.com> <51121A4D.3070207@oracle.com> Message-ID: <5112ACDC.4000800@oracle.com> On 2/6/2013 12:54 AM, Alan Bateman wrote: > On 05/02/2013 22:16, Joe Darcy wrote: >> : >> >> Webrev: >> http://cr.openjdk.java.net/~darcy/8005623.0/ >> >> This review is both to cover the addition of @FunctionalInterface to >> the types above and also to query if the annotation should be >> included in any of the other types below under the same bug. > Looks good to me. I would also include PathMatcher and > DirectoryStream.Filter in this first cut. Will do; I'll add these to the set of impacted types and call that a day for round 1. > > BTW: You mentioned XML as an area that you plan to look at it. One > issue to be aware of is that they are currently compiled with the boot > JDK so they can't make use of new APIs (this is true of the new build > too, at least at this time). > > Actually I had planned for the component teams to look at their own areas now that the candidates have been identified and the core interfaces annotated. Thanks, -Joe From pbenedict at apache.org Wed Feb 6 22:10:56 2013 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 6 Feb 2013 16:10:56 -0600 Subject: Missing @since tags Message-ID: This is very minor. Browsing the jdk8b75 javadoc, I noticed these classes are missing their @since tags. ProcessBuilder.Redirect.Type Formatter.BigDecimalLayoutForm Paul From martinrb at google.com Wed Feb 6 22:13:38 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 6 Feb 2013 14:13:38 -0800 Subject: Missing @since tags In-Reply-To: References: Message-ID: Please find and resurrect the script I wrote many years ago to find missing @since tags in a semi-automated fashion, and fix all of the jdk8 javadocs. On Wed, Feb 6, 2013 at 2:10 PM, Paul Benedict wrote: > This is very minor. Browsing the jdk8b75 javadoc, I noticed these classes > are missing their @since tags. > > ProcessBuilder.Redirect.Type > Formatter.BigDecimalLayoutForm > > Paul > From james.holmlund at oracle.com Wed Feb 6 23:11:09 2013 From: james.holmlund at oracle.com (james.holmlund at oracle.com) Date: Wed, 06 Feb 2013 23:11:09 +0000 Subject: hg: jdk8/tl/langtools: 8007698: jtreg test T6306137.java won't compile with ASCII encoding Message-ID: <20130206231115.68C24478A3@hg.openjdk.java.net> Changeset: b386b8c45387 Author: jjh Date: 2013-02-06 23:10 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b386b8c45387 8007698: jtreg test T6306137.java won't compile with ASCII encoding Reviewed-by: ksrini ! test/tools/javac/api/T6306137.java From scolebourne at joda.org Wed Feb 6 23:16:37 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 6 Feb 2013 23:16:37 +0000 Subject: RFR - 6480539: BigDecimal.stripTrailingZeros() should specify no-op on zero BigDecimals In-Reply-To: <1BA5F227-8369-4AC4-A108-165A094BD763@oracle.com> References: <51100C97.4040504@oracle.com> <51104CE4.10506@oracle.com> <1BA5F227-8369-4AC4-A108-165A094BD763@oracle.com> Message-ID: On 5 February 2013 09:09, Paul Sandoz wrote: > This is one of those unfortunate cases where a bug can become a feature. I *really* don't see how. The method name is absolutely clear about its purpose. "Strip trailing zeros". Anyone relying on it not stripping zeroes for zero needs their head examining. This particular one just happens to be one that I've run across twice and in both cases it required a workaround. I'd argue that there are more people with undiscovered bugs in their code because the method is buggy than people who would break were the method fixed. What bothers me even more is the desire expressed in this thread to simply wish away bugs by redefining the documentation. If the method name is clear enough, like in this case, then its a bug, and a documentation change simply isn't the right solution. Stephen From martinrb at google.com Thu Feb 7 01:55:39 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 6 Feb 2013 17:55:39 -0800 Subject: zip64 compatibility problems In-Reply-To: References: <50F6010D.5000806@oracle.com> <5100C3D2.6040604@oracle.com> Message-ID: Following up, please review the backward compatiblitiy support in: http://cr.openjdk.java.net/~martin/webrevs/openjdk8/useZip64For64kEntries/ (ideally users would have even more control via the API, but I ain't gonna try to touch that) From martinrb at google.com Thu Feb 7 02:03:22 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 6 Feb 2013 18:03:22 -0800 Subject: zip64 compatibility problems In-Reply-To: <510662CE.4050305@oracle.com> References: <50F60532.80306@oracle.com> <510662CE.4050305@oracle.com> Message-ID: Pushed into tl8. Thanks for the reviews! On Mon, Jan 28, 2013 at 3:36 AM, Alan Bateman wrote: > On 26/01/2013 17:14, Martin Buchholz wrote: > >> : >> Following up on this, I have a simple webrev: >> >> http://cr.openjdk.java.net/~**martin/webrevs/openjdk8/**LARGEFILE/ >> >> with an "obviously correct" fix. However: >> >> - we need a bug filed >> - This change is completely untested. I no longer have access to native >> 32-bit systems where this bug might be manifested. I have not tried to >> actually provoke a failure, although it should not be too hard to create a >> 3GB jar file with the contents of interest at the end, on a system where >> off_t is signed 32-bit. >> - As we discussed, it might be better to have a JLI_Open (or even better, >> common C-level infrastructure for the whole project) but only you guys >> have >> access to the variety of systems to write and test such a thing, even if >> it >> is just a few lines of code. >> >> So next step here is up to you. >> > I've created a bug to track this first installation: > > 8006995: java launcher fails top en executable JAR > 2GB > > I think the proposed changes are okay, a no-brainer really. It would be > nice if the open were moved to platform specific code, then we could use > open64 and drop O_LARGEFILE flag. That might be something for future > refactoring (I think JLI_Open was suggested in an earlier mail). > > Ideally we should have a test but we've had a lot of bad experience with > files that need multi-GB zip files (slow, need lots of disk space) so I > think it would be saner to leave it out this time. > > -Alan. > From martinrb at google.com Thu Feb 7 02:02:32 2013 From: martinrb at google.com (martinrb at google.com) Date: Thu, 07 Feb 2013 02:02:32 +0000 Subject: hg: jdk8/tl/jdk: 8006995: java launcher fails to open executable JAR > 2GB Message-ID: <20130207020243.8E8CA478AF@hg.openjdk.java.net> Changeset: 2f1505c49e79 Author: martin Date: 2013-02-06 17:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2f1505c49e79 8006995: java launcher fails to open executable JAR > 2GB Summary: Use O_LARGEFILE consistently when opening jar files Reviewed-by: alanb, sherman ! src/share/bin/parse_manifest.c From joe.darcy at oracle.com Thu Feb 7 02:12:24 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 06 Feb 2013 18:12:24 -0800 Subject: JDK 8 code review request for 8005623: Retrofit FunctionalInterface annotations to core platform interfaces In-Reply-To: <5112ACDC.4000800@oracle.com> References: <511184BF.9040202@oracle.com> <51121A4D.3070207@oracle.com> <5112ACDC.4000800@oracle.com> Message-ID: <51130D88.309@oracle.com> On 02/06/2013 11:19 AM, Joe Darcy wrote: > On 2/6/2013 12:54 AM, Alan Bateman wrote: >> On 05/02/2013 22:16, Joe Darcy wrote: >>> : >>> >>> Webrev: >>> http://cr.openjdk.java.net/~darcy/8005623.0/ >>> >>> This review is both to cover the addition of @FunctionalInterface to >>> the types above and also to query if the annotation should be >>> included in any of the other types below under the same bug. >> Looks good to me. I would also include PathMatcher and >> DirectoryStream.Filter in this first cut. > > Will do; I'll add these to the set of impacted types and call that a > day for round 1. > > Updated webrev at http://cr.openjdk.java.net/~darcy/8005623.1/ I'll push this once the internal ccc request clears. Thanks for the reviews, -Joe From joe.darcy at oracle.com Thu Feb 7 05:09:33 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 06 Feb 2013 21:09:33 -0800 Subject: Review request for JDK-8007405: Update parameter reflection API in accordance with spec changes In-Reply-To: <51116E29.8020600@oracle.com> References: <51116448.8050300@oracle.com> <51116E29.8020600@oracle.com> Message-ID: <5113370D.6000706@oracle.com> Hi Eric, The code changes look okay, but some tests for isImplicit should be written as soon as there is compiler support for the feature. Cheers, -Joe On 02/05/2013 12:40 PM, Eric McCorkle wrote: > Clarification here: the issue's title is a bit more narrow than the > scope of the fix. It addresses some javadoc comments and handling of > nameless parameters as well. > > On 02/05/13 14:58, Eric McCorkle wrote: >> Hello, please review this patch, which implements some spec changes for >> parameter reflection in the java.lang.reflect API. >> >> This patch changes the SYNTHESIZED flag to MANDATED, and changes the >> associated methods. It also updates some javadoc comments. >> >> The webrev is here: >> http://cr.openjdk.java.net/~emc/8007405/ >> >> The bug report is here: >> http://bugs.sun.com/view_bug.do?bug_id=8007405 >> >> The latest version of the spec is here: >> http://cr.openjdk.java.net/~abuckley/8misc.pdf >> >> Thanks, >> Eric From brucechapman at paradise.net.nz Thu Feb 7 07:32:50 2013 From: brucechapman at paradise.net.nz (Bruce Chapman) Date: Thu, 07 Feb 2013 20:32:50 +1300 Subject: RFR - 6480539: BigDecimal.stripTrailingZeros() should specify no-op on zero BigDecimals In-Reply-To: References: <51100C97.4040504@oracle.com> <51104CE4.10506@oracle.com> <1BA5F227-8369-4AC4-A108-165A094BD763@oracle.com> Message-ID: <511358A2.9090408@paradise.net.nz> Stephen, In your case(s) would the workaround fail to work if the bug was fixed? Working around a bug is quite different to taking advantage of the buggy behaviour. If fixing the bug would break code that works around it that can be seen as a problem, while breaking code that relies on the bug is IMHO much less of an issue since anyone that does that is taking a known risk, or a risk that should reasonably be expected to be known. I am finding it hard to imagine a genuine attempt at a workaround that would not still work (though redundantly) if the bug was fixed. Also bear in mind that there are other implementations, and the signature and the javadoc are the spec. If you find behaviour that differs and take advantage of that behaviour then you are opening the possibility of it changing if either: you run with another implementation, or the bug gets fixed. While it is easy to contrive an example that would break if this bug were fixed, and it is possible (on the grounds that I cannot prove it is impossible) that some real code might break, it is hard to imagine a scenario where the author/owner of that broken code has any morally legitimate grounds for complaint in that case. I guess if you take the "This is one of those unfortunate cases where a bug can become a feature." approach to its logical conclusion then no bugs get fixed because there are no bugs, just a nice online list of newly discovered unexpected features. Bruce On 7/02/2013 12:16 p.m., Stephen Colebourne wrote: > On 5 February 2013 09:09, Paul Sandoz wrote: >> This is one of those unfortunate cases where a bug can become a feature. > I *really* don't see how. > > The method name is absolutely clear about its purpose. "Strip trailing > zeros". Anyone relying on it not stripping zeroes for zero needs their > head examining. > > This particular one just happens to be one that I've run across twice > and in both cases it required a workaround. I'd argue that there are > more people with undiscovered bugs in their code because the method is > buggy than people who would break were the method fixed. > > What bothers me even more is the desire expressed in this thread to > simply wish away bugs by redefining the documentation. If the method > name is clear enough, like in this case, then its a bug, and a > documentation change simply isn't the right solution. > Stephen > From scolebourne at joda.org Thu Feb 7 10:06:22 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 7 Feb 2013 10:06:22 +0000 Subject: RFR - 6480539: BigDecimal.stripTrailingZeros() should specify no-op on zero BigDecimals In-Reply-To: <511358A2.9090408@paradise.net.nz> References: <51100C97.4040504@oracle.com> <51104CE4.10506@oracle.com> <1BA5F227-8369-4AC4-A108-165A094BD763@oracle.com> <511358A2.9090408@paradise.net.nz> Message-ID: On 7 February 2013 07:32, Bruce Chapman wrote: > Stephen, In your case(s) would the workaround fail to work if the bug was > fixed? No. The workaround would handle the fixed implementation just fine. And all workarounds would ultimately be similar to mine. https://github.com/OpenGamma/OG-Platform/blob/master/projects/OG-Util/src/main/java/com/opengamma/util/JdkUtils.java#L26 > I guess if you take the "This is one of those unfortunate cases where a bug > can become a feature." approach to its logical conclusion then no bugs get > fixed because there are no bugs, just a nice online list of newly discovered > unexpected features. Thats the underlying part of the issue here that concerns me. Stephen From chris.hegarty at oracle.com Thu Feb 7 10:44:23 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 07 Feb 2013 10:44:23 +0000 Subject: RFR JDK-8007609 In-Reply-To: <51127084.3080206@oracle.com> References: <51127084.3080206@oracle.com> Message-ID: <51138587.1010801@oracle.com> On 02/06/2013 03:02 PM, Alan Bateman wrote: > On 06/02/2013 14:57, John Zavgren wrote: >> Alan: I like your change, but I think the free(result) statement would >> need to be eliminated, otherwise the block a few lines later: /* >> Unable to get final path. */ if(len == 0 && result != NULL) { >> free(result); result = NULL; } would cause result to be freed twice. > Shouldn't do because result = newResult and so will be NULL. > > An alternative would be: > > WCHAR* newResult = (WCHAR*)realloc(...); > if (newResult != NULL) { > result = newResult; > len = (*GetFinalPathNameByHandle_func)( h, result, len, 0); > } else { > len = 0; > } > > which might be clearer. This looks like the best proposed change I've seen on this thread. Also, there may be another potential leak here. I think the 'len == 0 && ' needs to be removed from the following: 160 /* unable to get final path */ 161 if (len == 0 && result != NULL) { 162 free(result); 163 result = NULL; 164 } If the malloc previous to this, "WCHAR *tmp = (WCHAR*)malloc(resultLen * sizeof(WCHAR));", fails it sets len = 0, which will cause result to leak. -Chris > > -Alan. > From david.holmes at oracle.com Thu Feb 7 11:49:20 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 07 Feb 2013 21:49:20 +1000 Subject: RFR JDK-8007609 In-Reply-To: <51138587.1010801@oracle.com> References: <51127084.3080206@oracle.com> <51138587.1010801@oracle.com> Message-ID: <511394C0.6040908@oracle.com> On 7/02/2013 8:44 PM, Chris Hegarty wrote: > On 02/06/2013 03:02 PM, Alan Bateman wrote: >> On 06/02/2013 14:57, John Zavgren wrote: >>> Alan: I like your change, but I think the free(result) statement would >>> need to be eliminated, otherwise the block a few lines later: /* >>> Unable to get final path. */ if(len == 0 && result != NULL) { >>> free(result); result = NULL; } would cause result to be freed twice. >> Shouldn't do because result = newResult and so will be NULL. >> >> An alternative would be: >> >> WCHAR* newResult = (WCHAR*)realloc(...); >> if (newResult != NULL) { >> result = newResult; >> len = (*GetFinalPathNameByHandle_func)( h, result, len, 0); >> } else { >> len = 0; >> } >> >> which might be clearer. > > This looks like the best proposed change I've seen on this thread. > > Also, there may be another potential leak here. I think the 'len == 0 && > ' needs to be removed from the following: > > 160 /* unable to get final path */ > 161 if (len == 0 && result != NULL) { > 162 free(result); > 163 result = NULL; > 164 } > > If the malloc previous to this, "WCHAR *tmp = (WCHAR*)malloc(resultLen * > sizeof(WCHAR));", fails it sets len = 0, which will cause result to leak. AFAICS setting len=0 means len==0 will be true and so we will free(result). David > -Chris > >> >> -Alan. >> From david.holmes at oracle.com Thu Feb 7 11:54:34 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 07 Feb 2013 21:54:34 +1000 Subject: RFR JDK-8007609 In-Reply-To: <511394C0.6040908@oracle.com> References: <51127084.3080206@oracle.com> <51138587.1010801@oracle.com> <511394C0.6040908@oracle.com> Message-ID: <511395FA.8060108@oracle.com> On 7/02/2013 9:49 PM, David Holmes wrote: > On 7/02/2013 8:44 PM, Chris Hegarty wrote: >> On 02/06/2013 03:02 PM, Alan Bateman wrote: >>> On 06/02/2013 14:57, John Zavgren wrote: >>>> Alan: I like your change, but I think the free(result) statement would >>>> need to be eliminated, otherwise the block a few lines later: /* >>>> Unable to get final path. */ if(len == 0 && result != NULL) { >>>> free(result); result = NULL; } would cause result to be freed twice. >>> Shouldn't do because result = newResult and so will be NULL. >>> >>> An alternative would be: >>> >>> WCHAR* newResult = (WCHAR*)realloc(...); >>> if (newResult != NULL) { >>> result = newResult; >>> len = (*GetFinalPathNameByHandle_func)( h, result, len, 0); >>> } else { >>> len = 0; >>> } >>> >>> which might be clearer. >> >> This looks like the best proposed change I've seen on this thread. >> >> Also, there may be another potential leak here. I think the 'len == 0 && >> ' needs to be removed from the following: >> >> 160 /* unable to get final path */ >> 161 if (len == 0 && result != NULL) { >> 162 free(result); >> 163 result = NULL; >> 164 } >> >> If the malloc previous to this, "WCHAR *tmp = (WCHAR*)malloc(resultLen * >> sizeof(WCHAR));", fails it sets len = 0, which will cause result to leak. > > AFAICS setting len=0 means len==0 will be true and so we will free(result). And if len != 0 then we will have already freed result, so avoiding a double-free. David > David > >> -Chris >> >>> >>> -Alan. >>> From staffan.larsen at oracle.com Thu Feb 7 12:35:33 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Thu, 07 Feb 2013 12:35:33 +0000 Subject: hg: jdk8/tl/jdk: 8007142: Add utility classes for writing better multiprocess tests in jtreg Message-ID: <20130207123555.40E7A478D5@hg.openjdk.java.net> Changeset: 2de8c6c2d652 Author: ykantser Date: 2013-02-07 11:22 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2de8c6c2d652 8007142: Add utility classes for writing better multiprocess tests in jtreg Reviewed-by: alanb, rbackman + test/lib/testlibrary/OutputAnalyzerTest.java + test/lib/testlibrary/jdk/testlibrary/JcmdBase.java + test/lib/testlibrary/jdk/testlibrary/JdkFinder.java + test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java + test/lib/testlibrary/jdk/testlibrary/OutputBuffer.java + test/lib/testlibrary/jdk/testlibrary/ProcessTools.java + test/lib/testlibrary/jdk/testlibrary/StreamPumper.java From chris.hegarty at oracle.com Thu Feb 7 12:54:26 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 07 Feb 2013 12:54:26 +0000 Subject: RFR JDK-8007609 In-Reply-To: <511395FA.8060108@oracle.com> References: <51127084.3080206@oracle.com> <51138587.1010801@oracle.com> <511394C0.6040908@oracle.com> <511395FA.8060108@oracle.com> Message-ID: <5113A402.6050905@oracle.com> On 02/07/2013 11:54 AM, David Holmes wrote: > .... >> AFAICS setting len=0 means len==0 will be true and so we will >> free(result). > > And if len != 0 then we will have already freed result, so avoiding a > double-free. Here's the code as it stands today. 113 result = (WCHAR*)malloc(MAX_PATH * sizeof(WCHAR)); 114 if (result != NULL) { 115 DWORD len = (*GetFinalPathNameByHandle_func)(h, result, MAX_PATH, 0); 116 if (len >= MAX_PATH) { 117 /* retry with a buffer of the right size */ 118 result = (WCHAR*)realloc(result, (len+1) * sizeof(WCHAR)); 119 if (result != NULL) { 120 len = (*GetFinalPathNameByHandle_func)(h, result, len, 0); 121 } else { 122 len = 0; 123 } 124 } 125 if (len > 0) { 126 /** 127 * Strip prefix (should be \\?\ or \\?\UNC) 128 */ 129 if (result[0] == L'\\' && result[1] == L'\\' && 130 result[2] == L'?' && result[3] == L'\\') 131 { 132 int isUnc = (result[4] == L'U' && 133 result[5] == L'N' && 134 result[6] == L'C'); 135 int prefixLen = (isUnc) ? 7 : 4; 136 /* actual result length (includes terminator) */ 137 int resultLen = len - prefixLen + (isUnc ? 1 : 0) + 1; 138 139 /* copy result without prefix into new buffer */ 140 WCHAR *tmp = (WCHAR*)malloc(resultLen * sizeof(WCHAR)); 141 if (tmp == NULL) { 142 len = 0; <<<<<<<<<<<<<<<<<<< HERE 143 } else { 144 WCHAR *p = result; 145 p += prefixLen; 146 if (isUnc) { 147 WCHAR *p2 = tmp; 148 p2[0] = L'\\'; 149 p2++; 150 wcscpy(p2, p); 151 } else { 152 wcscpy(tmp, p); 153 } 154 free(result); 155 result = tmp; 156 } 157 } 158 } 159 160 /* unable to get final path */ 161 if (len == 0 && result != NULL) { 162 free(result); 163 result = NULL; 164 } 165 } -Chris. From pbenedict at apache.org Thu Feb 7 15:15:36 2013 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 7 Feb 2013 09:15:36 -0600 Subject: RFR - 6480539: BigDecimal.stripTrailingZeros() should specify no-op on zero BigDecimals Message-ID: I am chiming in to agree with Stephen. About a year ago, I encountered the same issue and was extremely dissatisfied with the behavior. I was forced to create a utility method to check for "0" before passing it onto stripTrailingZeros(). The current behavior is useless; the spec is clear stripping extra zeros means exactly that. From Alan.Bateman at oracle.com Thu Feb 7 16:15:13 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 07 Feb 2013 16:15:13 +0000 Subject: zip64 compatibility problems In-Reply-To: References: <50F6010D.5000806@oracle.com> <5100C3D2.6040604@oracle.com> Message-ID: <5113D311.7060006@oracle.com> On 07/02/2013 01:55, Martin Buchholz wrote: > Following up, please review the backward compatiblitiy support in: > > http://cr.openjdk.java.net/~martin/webrevs/openjdk8/useZip64For64kEntries/ > > (ideally users would have even more control via the API, but I ain't gonna > try to touch that) No objection to adding a knob for this but do we need changes for reading too? I'm just concerned that someone could use ZipOutputStream to create a zip or JAR file that is not readable (in the same VM). On the property name then we've started using jdk.* for JDK-specific properties. Also as the default is to support ZIP64 when writing then maybe this should have a disable* name so someone can specify -Djdk.util.zip.disableZip64 on the command line without specifying a value. -Alan. From eric.mccorkle at oracle.com Thu Feb 7 16:41:31 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 07 Feb 2013 11:41:31 -0500 Subject: Review request for JDK-8007405: Update parameter reflection API in accordance with spec changes In-Reply-To: <5113370D.6000706@oracle.com> References: <51116448.8050300@oracle.com> <51116E29.8020600@oracle.com> <5113370D.6000706@oracle.com> Message-ID: <5113D93B.7030002@oracle.com> There is an extensive test suite being developed by Peter Jensen, which will go in after I push the compiler side. On 02/07/13 00:09, Joe Darcy wrote: > Hi Eric, > > The code changes look okay, but some tests for isImplicit should be > written as soon as there is compiler support for the feature. > > Cheers, > > -Joe > > On 02/05/2013 12:40 PM, Eric McCorkle wrote: >> Clarification here: the issue's title is a bit more narrow than the >> scope of the fix. It addresses some javadoc comments and handling of >> nameless parameters as well. >> >> On 02/05/13 14:58, Eric McCorkle wrote: >>> Hello, please review this patch, which implements some spec changes for >>> parameter reflection in the java.lang.reflect API. >>> >>> This patch changes the SYNTHESIZED flag to MANDATED, and changes the >>> associated methods. It also updates some javadoc comments. >>> >>> The webrev is here: >>> http://cr.openjdk.java.net/~emc/8007405/ >>> >>> The bug report is here: >>> http://bugs.sun.com/view_bug.do?bug_id=8007405 >>> >>> The latest version of the spec is here: >>> http://cr.openjdk.java.net/~abuckley/8misc.pdf >>> >>> Thanks, >>> Eric > From chris.hegarty at oracle.com Thu Feb 7 16:49:46 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 07 Feb 2013 16:49:46 +0000 Subject: Missing @since tags In-Reply-To: References: Message-ID: <5113DB2A.1000001@oracle.com> Martin, I have finally located the script, findMissingSince ;-) I will run it once I have a clean, up to date, jdk8 build. I think it may be a candidate to propose to add to the common scripts in the top-level repo. -Chris. On 02/06/2013 10:13 PM, Martin Buchholz wrote: > Please find and resurrect the script I wrote many years ago to find missing > @since tags in a semi-automated fashion, and fix all of the jdk8 javadocs. > > On Wed, Feb 6, 2013 at 2:10 PM, Paul Benedict wrote: > >> This is very minor. Browsing the jdk8b75 javadoc, I noticed these classes >> are missing their @since tags. >> >> ProcessBuilder.Redirect.Type >> Formatter.BigDecimalLayoutForm >> >> Paul >> From pisymbol at gmail.com Thu Feb 7 16:54:56 2013 From: pisymbol at gmail.com (Alexander Sack) Date: Thu, 7 Feb 2013 11:54:56 -0500 Subject: JDK7's java.util.zip breakage with very large files Message-ID: Folks: What I am trying to do is generate Zip64 extensions within a JAR file and then dissect the zip contents (end of directory records, file headers, etc.). However, when I use jar or a small program that I wrote which uses java.util.zip to zip up a very large file >12G, I do not get the expected output. Despite the fact that jar succeeds, the zip binary created does not have an End of Directory (EoD) record at all! (like ZipOutStream.finish() was never called). I am able to extract the large file and verify its MD5 which is correct. So I am doing this (data is 12G): - md5sum data - jar cvf data.jar data [wait a while, out is around 2.3G, return code is 0] - bvi data.jar (look for EoD at end of jar file, magic 0x06054B50 or even the zip64 (EoD) locator/record signatures) Not found! (bummer) Extract: - jar tvf data.jar -> I see the correct size which means jar is reading the 64-bit sizes correctly, earlier builds ( References: <5113DB2A.1000001@oracle.com> Message-ID: On Thu, Feb 7, 2013 at 8:49 AM, Chris Hegarty wrote: > Martin, > > I have finally located the script, findMissingSince ;-) I will run it once > I have a clean, up to date, jdk8 build. I think it may be a candidate to > propose to add to the common scripts in the top-level repo. Because the script won't work out-of-the-box, I suggest an alternative order. *First* open-source it, then get someone who understands Martin-perl to do the inevitable fixups required for the script to understand javadoc 8 output (I am unusually qualified), and then fix the missing @since in a single Shazam! change. Don't fix the ones identified by Paul right away - leave those as a test case for the script. From Alan.Bateman at oracle.com Thu Feb 7 17:49:17 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 07 Feb 2013 17:49:17 +0000 Subject: Missing @since tags In-Reply-To: References: <5113DB2A.1000001@oracle.com> Message-ID: <5113E91D.8060608@oracle.com> On 07/02/2013 17:40, Martin Buchholz wrote: > On Thu, Feb 7, 2013 at 8:49 AM, Chris Hegartywrote: > >> Martin, >> >> I have finally located the script, findMissingSince ;-) I will run it once >> I have a clean, up to date, jdk8 build. I think it may be a candidate to >> propose to add to the common scripts in the top-level repo. > > Because the script won't work out-of-the-box, I suggest an alternative > order. > > *First* open-source it, then get someone who understands Martin-perl to do > the inevitable fixups required for the script to understand javadoc 8 > output (I am unusually qualified), and then fix the missing @since in a > single Shazam! change. Don't fix the ones identified by Paul right away - > leave those as a test case for the script. Alternatively, maybe this is a job for an annotation processor. -Alan. From martinrb at google.com Thu Feb 7 17:51:27 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 7 Feb 2013 09:51:27 -0800 Subject: zip64 compatibility problems In-Reply-To: <5113D311.7060006@oracle.com> References: <50F6010D.5000806@oracle.com> <5100C3D2.6040604@oracle.com> <5113D311.7060006@oracle.com> Message-ID: On Thu, Feb 7, 2013 at 8:15 AM, Alan Bateman wrote: > On 07/02/2013 01:55, Martin Buchholz wrote: > >> Following up, please review the backward compatiblitiy support in: >> >> http://cr.openjdk.java.net/~**martin/webrevs/openjdk8/** >> useZip64For64kEntries/ >> >> (ideally users would have even more control via the API, but I ain't gonna >> try to touch that) >> > No objection to adding a knob for this but do we need changes for reading > too? I'm just concerned that someone could use ZipOutputStream to create a > zip or JAR file that is not readable (in the same VM). > > Such zip files have always been readable by the JDK's (and other folks') zip implementations, so no changes should be needed (in theory). I've already fixed a case where the zip implementation in langtools regressed to not be able to read such files. That said, we could use more testing. > On the property name then we've started using jdk.* for JDK-specific > properties. Also as the default is to support ZIP64 when writing then maybe > this should have a disable* name so someone can specify > -Djdk.util.zip.disableZip64 on the command line without specifying a value. Can you point me at exemplar code for reading such a system property? 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". From martinrb at google.com Thu Feb 7 18:29:33 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 7 Feb 2013 10:29:33 -0800 Subject: Missing @since tags In-Reply-To: <5113E91D.8060608@oracle.com> References: <5113DB2A.1000001@oracle.com> <5113E91D.8060608@oracle.com> Message-ID: On Thu, Feb 7, 2013 at 9:49 AM, Alan Bateman wrote: > On 07/02/2013 17:40, Martin Buchholz wrote: > >> Alternatively, maybe this is a job for an annotation processor. > > IIRC, we considered that 6 years ago. It might be possible, but consider that you need to diff multiple jdk implementations, and the annotation processor needs to be able to grok javadoc comments. Also, there are no "annotations" being processed, so it's weird to use an annotation processor. Writing a javadoc doclet is another approach that might work. From martinrb at google.com Thu Feb 7 18:32:14 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 7 Feb 2013 10:32:14 -0800 Subject: JDK7's java.util.zip breakage with very large files In-Reply-To: References: Message-ID: It's probably a bug, but ... - it would help to have a clear reproducible test case - take a look at my vaguely related webrev from yesterday to this mailing list - I don't call zos.finish; I call zos.close which Works For Me. Martin On Thu, Feb 7, 2013 at 8:54 AM, Alexander Sack wrote: > Folks: > > What I am trying to do is generate Zip64 extensions within a JAR file > and then dissect the zip contents (end of directory records, file > headers, etc.). > > However, when I use jar or a small program that I wrote which uses > java.util.zip to zip up a very large file >12G, I do not get the > expected output. > > Despite the fact that jar succeeds, the zip binary created does not > have an End of Directory (EoD) record at all! (like > ZipOutStream.finish() was never called). > > I am able to extract the large file and verify its MD5 which is correct. > > So I am doing this (data is 12G): > > - md5sum data > - jar cvf data.jar data > [wait a while, out is around 2.3G, return code is 0] > - bvi data.jar (look for EoD at end of jar file, magic 0x06054B50 or > even the zip64 (EoD) locator/record signatures) > > Not found! (bummer) > > Extract: > > - jar tvf data.jar -> I see the correct size which means jar is > reading the 64-bit sizes correctly, earlier builds ( would see -1. > - jar xvf data.jar > - md5sum data > - Matches original data > > I noticed that after the deflate compressed blocks, the file is > appended with a lot of zeros (I originally thought it got truncated > but from the above extraction test, that is not the case). > > This is on a x86-64 Fedora 13 system using yesterday's JDK7 build tree > (I downloaded the build infrastructure and set it to download bundles > during the build - I had no build failures). > > Why for very large files does jar (java.util.zip) output a > non-standard zip file, i.e. no EoD record and friends? > > I have just begun to look at the actual code to see whether this is > pilot error on my part or something else a foot (my code calls > zos.finish() explicitly which has no effect - not sure where jar calls > it just yet from ZipOutputStream.finish()). > > Thanks! > > -aps > From xueming.shen at oracle.com Thu Feb 7 18:31:36 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 07 Feb 2013 10:31:36 -0800 Subject: [JSR310 M7 Review request] 8007392: JSR310 DateTime API Updates Message-ID: <5113F308.6040102@oracle.com> 8007392: JSR 310: DateTime API Updates Webrev: http://cr.openjdk.java.net/~sherman/8007392/ http://cr.openjdk.java.net/~sherman/8007392/javadoc Note: The Threeten API has been updated based on reviews and continued development. The main changes included here are - Consolidating Chronology classes for local calendars in a new java.time.chrono package - Merging the localized calendars into java.time.chrono (removing package java.time.calendar) - Moving Year, YearMonth, MonthDay to java.time - Rename DateTimeFormatter print method to format() - Move DateTimeFormatters static methods to DateTimeFormatter - Redesign/remove DateTimeBuilder class - becomes package private - Replace TemporalAdder/Subtractor with TemporalAmount - Remove DateTimePrintException - Move OffsetDateTime and OffsetTime to java.time package - Remove OffsetDate - Rename chrono to chronology in class and method names - Rename ISO* classes and methods to Iso* - Refactor Period to be date based year/month/day - Refactor Duration to be time based h/m/s Thanks! -Sherman From xueming.shen at oracle.com Thu Feb 7 18:31:47 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 07 Feb 2013 10:31:47 -0800 Subject: [JSR310 M7 Review request] 8007520: Update date/time classes in j.util and j.sql packages to interoperate with JSR310 classes Message-ID: <5113F313.50401@oracle.com> 8007520: Update date/time classes in j.util and j.sql packages Webrev: http://cr.openjdk.java.net/~sherman/8007520/ Note: As part of the JSR310 Date/Time API project, methods are proposed to be added into existing jdk date/time classes in java.util and java.sql packages to inter-operate with the new JSR310 date/time types Thanks! -Sherman From xueming.shen at oracle.com Thu Feb 7 18:31:54 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 07 Feb 2013 10:31:54 -0800 Subject: [JSR310 M7 Review request] 8007572: Replace existing jdk timezone data at /lib/zi with JSR310's tzdb. Message-ID: <5113F31A.3080704@oracle.com> 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 pisymbol at gmail.com Thu Feb 7 18:48:50 2013 From: pisymbol at gmail.com (Alexander Sack) Date: Thu, 7 Feb 2013 13:48:50 -0500 Subject: JDK7's java.util.zip breakage with very large files In-Reply-To: References: Message-ID: On Thu, Feb 7, 2013 at 1:32 PM, Martin Buchholz wrote: > It's probably a bug, but ... > - it would help to have a clear reproducible test case dd if= of=data bs=1G count=12 jar cvf data.jar data [get a cup of your favorite hot beverage] bvi data #504B0506 or "$", "#504B' etc. No EoD at the end and what's even worse, I recently ran out of Kleenex to wipe away my tears. > - take a look at my vaguely related webrev from yesterday to this mailing > list. Ok. > - I don't call zos.finish; I call zos.close which Works For Me. Try it with very large files...see above! :-) I mentioned zos.finish() before I ran to lunch because that's where I see the EoD actually written out to the stream in cscope. Unfortunately I don't have a working debugger right now since Java is normally just coffee to me, hence my cry for help (I may change that situation in the next few hours). Thanks for the feedback, it is appreciated. -aps From mike.duigou at oracle.com Thu Feb 7 19:45:57 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 7 Feb 2013 11:45:57 -0800 Subject: Missing @since tags In-Reply-To: References: <5113DB2A.1000001@oracle.com> <5113E91D.8060608@oracle.com> Message-ID: http://javadiff.sourceforge.net/ Which is implemented as a doclet does provide missing @since detection functionality. Mike On Feb 7 2013, at 10:29 , Martin Buchholz wrote: > On Thu, Feb 7, 2013 at 9:49 AM, Alan Bateman wrote: > >> On 07/02/2013 17:40, Martin Buchholz wrote: >> >>> Alternatively, maybe this is a job for an annotation processor. >> >> > IIRC, we considered that 6 years ago. It might be possible, but consider > that you need to diff multiple jdk implementations, and the annotation > processor needs to be able to grok javadoc comments. Also, there are no > "annotations" being processed, so it's weird to use an annotation > processor. Writing a javadoc doclet is another approach that might work. From xueming.shen at oracle.com Thu Feb 7 20:11:38 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 07 Feb 2013 12:11:38 -0800 Subject: JDK7's java.util.zip breakage with very large files In-Reply-To: References: Message-ID: <51140A7A.80600@oracle.com> Alexander, Can you do "jar xvf data.jar data" to extract the file? -Sherman On 02/07/2013 08:54 AM, Alexander Sack wrote: > Folks: > > What I am trying to do is generate Zip64 extensions within a JAR file > and then dissect the zip contents (end of directory records, file > headers, etc.). > > However, when I use jar or a small program that I wrote which uses > java.util.zip to zip up a very large file>12G, I do not get the > expected output. > > Despite the fact that jar succeeds, the zip binary created does not > have an End of Directory (EoD) record at all! (like > ZipOutStream.finish() was never called). > > I am able to extract the large file and verify its MD5 which is correct. > > So I am doing this (data is 12G): > > - md5sum data > - jar cvf data.jar data > [wait a while, out is around 2.3G, return code is 0] > - bvi data.jar (look for EoD at end of jar file, magic 0x06054B50 or > even the zip64 (EoD) locator/record signatures) > > Not found! (bummer) > > Extract: > > - jar tvf data.jar -> I see the correct size which means jar is > reading the 64-bit sizes correctly, earlier builds ( would see -1. > - jar xvf data.jar > - md5sum data > - Matches original data > > I noticed that after the deflate compressed blocks, the file is > appended with a lot of zeros (I originally thought it got truncated > but from the above extraction test, that is not the case). > > This is on a x86-64 Fedora 13 system using yesterday's JDK7 build tree > (I downloaded the build infrastructure and set it to download bundles > during the build - I had no build failures). > > Why for very large files does jar (java.util.zip) output a > non-standard zip file, i.e. no EoD record and friends? > > I have just begun to look at the actual code to see whether this is > pilot error on my part or something else a foot (my code calls > zos.finish() explicitly which has no effect - not sure where jar calls > it just yet from ZipOutputStream.finish()). > > Thanks! > > -aps From pisymbol at gmail.com Thu Feb 7 20:15:03 2013 From: pisymbol at gmail.com (Alexander Sack) Date: Thu, 7 Feb 2013 15:15:03 -0500 Subject: JDK7's java.util.zip breakage with very large files In-Reply-To: <51140A7A.80600@oracle.com> References: <51140A7A.80600@oracle.com> Message-ID: On Thu, Feb 7, 2013 at 3:11 PM, Xueming Shen wrote: > Alexander, > > Can you do "jar xvf data.jar data" to extract the file? > > As per original email, yes I can. Also md5sum checks out. But large files result in a malformed zip file. -aps From xueming.shen at oracle.com Thu Feb 7 20:23:38 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 07 Feb 2013 12:23:38 -0800 Subject: JDK7's java.util.zip breakage with very large files In-Reply-To: References: <51140A7A.80600@oracle.com> Message-ID: <51140D4A.4010605@oracle.com> There is difference between doing "jar xvf data.jar data" and "jar xvf data.jar" If the previous one works, it means the zip file should have the healthy end table there (it goes down to end->cen-> loc->data file). The later goes from the sequential looking up from the beginning, so it only looks into the "loc" table, it may extract the file out even there is no cen and end tables. I thought you just did "java xvf data.jar" in your previous email. -Sherman On 02/07/2013 12:15 PM, Alexander Sack wrote: > On Thu, Feb 7, 2013 at 3:11 PM, Xueming Shen wrote: >> Alexander, >> >> Can you do "jar xvf data.jar data" to extract the file? >> >> > As per original email, yes I can. Also md5sum checks out. > > But large files result in a malformed zip file. > > -aps From pisymbol at gmail.com Thu Feb 7 20:33:47 2013 From: pisymbol at gmail.com (Alexander Sack) Date: Thu, 7 Feb 2013 15:33:47 -0500 Subject: JDK7's java.util.zip breakage with very large files In-Reply-To: <51140D4A.4010605@oracle.com> References: <51140A7A.80600@oracle.com> <51140D4A.4010605@oracle.com> Message-ID: On Thu, Feb 7, 2013 at 3:23 PM, Xueming Shen wrote: > There is difference between doing > > "jar xvf data.jar data" > > and > > "jar xvf data.jar" > > If the previous one works, it means the zip file should have > the healthy end table there (it goes down to end->cen-> > loc->data file). $ jar xvf data.jar data java.util.zip.ZipException: ZIP_Read: specified offset out of range at java.util.zip.ZipFile.read(Native Method) at java.util.zip.ZipFile.access$1200(ZipFile.java:46) at java.util.zip.ZipFile$ZipFileInputStream.read(ZipFile.java:464) at java.util.zip.ZipFile$1.fill(ZipFile.java:247) at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:158) at java.io.FilterInputStream.read(FilterInputStream.java:107) at sun.tools.jar.Main.copy(Main.java:771) at sun.tools.jar.Main.copy(Main.java:803) at sun.tools.jar.Main.extractFile(Main.java:951) at sun.tools.jar.Main.extract(Main.java:905) at sun.tools.jar.Main.run(Main.java:254) at sun.tools.jar.Main.main(Main.java:1167) > The later goes from the sequential looking > up from the beginning, so it only looks into the "loc" table, > it may extract the file out even there is no cen and end tables. > > I thought you just did "java xvf data.jar" in your previous > email. I did. That works. md5sum's match original data file. -aps From kumar.x.srinivasan at oracle.com Thu Feb 7 20:36:56 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 07 Feb 2013 12:36:56 -0800 Subject: JDK7's java.util.zip breakage with very large files In-Reply-To: <51140D4A.4010605@oracle.com> References: <51140A7A.80600@oracle.com> <51140D4A.4010605@oracle.com> Message-ID: <51141068.60303@oracle.com> On 2/7/2013 12:23 PM, Xueming Shen wrote: > There is difference between doing > > "jar xvf data.jar data" > > and > > "jar xvf data.jar" you can also use zipinfo -v to check CEN entries. Kumar > > If the previous one works, it means the zip file should have > the healthy end table there (it goes down to end->cen-> > loc->data file). The later goes from the sequential looking > up from the beginning, so it only looks into the "loc" table, > it may extract the file out even there is no cen and end tables. > > I thought you just did "java xvf data.jar" in your previous > email. > > -Sherman > > > On 02/07/2013 12:15 PM, Alexander Sack wrote: >> On Thu, Feb 7, 2013 at 3:11 PM, Xueming >> Shen wrote: >>> Alexander, >>> >>> Can you do "jar xvf data.jar data" to extract the file? >>> >>> >> As per original email, yes I can. Also md5sum checks out. >> >> But large files result in a malformed zip file. >> >> -aps > From pisymbol at gmail.com Thu Feb 7 20:37:04 2013 From: pisymbol at gmail.com (Alexander Sack) Date: Thu, 7 Feb 2013 15:37:04 -0500 Subject: JDK7's java.util.zip breakage with very large files In-Reply-To: References: <51140A7A.80600@oracle.com> <51140D4A.4010605@oracle.com> Message-ID: On Thu, Feb 7, 2013 at 3:33 PM, Alexander Sack wrote: > On Thu, Feb 7, 2013 at 3:23 PM, Xueming Shen wrote: >> There is difference between doing >> >> "jar xvf data.jar data" >> >> and >> >> "jar xvf data.jar" >> >> If the previous one works, it means the zip file should have >> the healthy end table there (it goes down to end->cen-> >> loc->data file). > > $ jar xvf data.jar data Wait hold on....I apologize...ignore that last email...mea culpa, I have two JDKs on my system. That was with the JDK6 jar. I believe they both work...still waiting for it to deflate! -aps From pisymbol at gmail.com Thu Feb 7 20:47:19 2013 From: pisymbol at gmail.com (Alexander Sack) Date: Thu, 7 Feb 2013 15:47:19 -0500 Subject: JDK7's java.util.zip breakage with very large files In-Reply-To: <51141068.60303@oracle.com> References: <51140A7A.80600@oracle.com> <51140D4A.4010605@oracle.com> <51141068.60303@oracle.com> Message-ID: On Thu, Feb 7, 2013 at 3:36 PM, Kumar Srinivasan wrote: > On 2/7/2013 12:23 PM, Xueming Shen wrote: >> >> There is difference between doing >> >> "jar xvf data.jar data" >> >> and >> >> "jar xvf data.jar" > > > you can also use zipinfo -v to check CEN entries. Wow, that works too. Hmph. I think bvi led me astray...my apologies. Seems like it won't show me past 2.3GB for whatever reason (I guess that is a buffer limitation, it certainly didn't barf at me). I just did `tail -n 100 data.jar > out` and then bvi'ed that and I see it. (od as well). I am truly sorry for the noise (bad day), -aps From xueming.shen at oracle.com Thu Feb 7 20:59:49 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 07 Feb 2013 12:59:49 -0800 Subject: JDK7's java.util.zip breakage with very large files In-Reply-To: <51141068.60303@oracle.com> References: <51140A7A.80600@oracle.com> <51140D4A.4010605@oracle.com> <51141068.60303@oracle.com> Message-ID: <511415C5.1050503@oracle.com> Sure, I do have the "zipinfo" there:-) try java com.sun.nio.zipfs.ZipInfo FOO.jar Cool, right :-) -Sherman On 02/07/2013 12:36 PM, Kumar Srinivasan wrote: > On 2/7/2013 12:23 PM, Xueming Shen wrote: >> There is difference between doing >> >> "jar xvf data.jar data" >> >> and >> >> "jar xvf data.jar" > > you can also use zipinfo -v to check CEN entries. > > Kumar > >> >> If the previous one works, it means the zip file should have >> the healthy end table there (it goes down to end->cen-> >> loc->data file). The later goes from the sequential looking >> up from the beginning, so it only looks into the "loc" table, >> it may extract the file out even there is no cen and end tables. >> >> I thought you just did "java xvf data.jar" in your previous >> email. >> >> -Sherman >> >> >> On 02/07/2013 12:15 PM, Alexander Sack wrote: >>> On Thu, Feb 7, 2013 at 3:11 PM, Xueming Shen wrote: >>>> Alexander, >>>> >>>> Can you do "jar xvf data.jar data" to extract the file? >>>> >>>> >>> As per original email, yes I can. Also md5sum checks out. >>> >>> But large files result in a malformed zip file. >>> >>> -aps >> > From martinrb at google.com Thu Feb 7 23:23:04 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 7 Feb 2013 15:23:04 -0800 Subject: Missing @since tags In-Reply-To: References: <5113DB2A.1000001@oracle.com> <5113E91D.8060608@oracle.com> Message-ID: JDiff hasn't been updated since 2008. I would be surprised if you could get it to work on jdk8 vs. jdk7 without significant work. But the key thing is to use a tool, any tool, since history has shown it is very easy for engineers to forget to add the necessary @since tags. On Thu, Feb 7, 2013 at 11:45 AM, Mike Duigou wrote: > http://javadiff.sourceforge.net/ > > Which is implemented as a doclet does provide missing @since detection > functionality. > > Mike > > On Feb 7 2013, at 10:29 , Martin Buchholz wrote: > > > On Thu, Feb 7, 2013 at 9:49 AM, Alan Bateman >wrote: > > > >> On 07/02/2013 17:40, Martin Buchholz wrote: > >> > >>> Alternatively, maybe this is a job for an annotation processor. > >> > >> > > IIRC, we considered that 6 years ago. It might be possible, but consider > > that you need to diff multiple jdk implementations, and the annotation > > processor needs to be able to grok javadoc comments. Also, there are no > > "annotations" being processed, so it's weird to use an annotation > > processor. Writing a javadoc doclet is another approach that might work. > > From david.holmes at oracle.com Fri Feb 8 00:15:46 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 08 Feb 2013 10:15:46 +1000 Subject: RFR JDK-8007609 In-Reply-To: <5113A402.6050905@oracle.com> References: <51127084.3080206@oracle.com> <51138587.1010801@oracle.com> <511394C0.6040908@oracle.com> <511395FA.8060108@oracle.com> <5113A402.6050905@oracle.com> Message-ID: <511443B2.6030705@oracle.com> On 7/02/2013 10:54 PM, Chris Hegarty wrote: > On 02/07/2013 11:54 AM, David Holmes wrote: >> .... >>> AFAICS setting len=0 means len==0 will be true and so we will >>> free(result). >> >> And if len != 0 then we will have already freed result, so avoiding a >> double-free. > > Here's the code as it stands today. Yes .... I don't see the problem > > 113 result = (WCHAR*)malloc(MAX_PATH * sizeof(WCHAR)); > 114 if (result != NULL) { we've entered this block so we must free result evetually. > 115 DWORD len = (*GetFinalPathNameByHandle_func)(h, result, MAX_PATH, 0); > 116 if (len >= MAX_PATH) { > 117 /* retry with a buffer of the right size */ > 118 result = (WCHAR*)realloc(result, (len+1) * sizeof(WCHAR)); > 119 if (result != NULL) { > 120 len = (*GetFinalPathNameByHandle_func)(h, result, len, 0); > 121 } else { > 122 len = 0; > 123 } > 124 } > 125 if (len > 0) { len was good so we've gone this path > 126 /** > 127 * Strip prefix (should be \\?\ or \\?\UNC) > 128 */ > 129 if (result[0] == L'\\' && result[1] == L'\\' && > 130 result[2] == L'?' && result[3] == L'\\') > 131 { > 132 int isUnc = (result[4] == L'U' && > 133 result[5] == L'N' && > 134 result[6] == L'C'); > 135 int prefixLen = (isUnc) ? 7 : 4; > 136 /* actual result length (includes terminator) */ > 137 int resultLen = len - prefixLen + (isUnc ? 1 : 0) + 1; > 138 > 139 /* copy result without prefix into new buffer */ > 140 WCHAR *tmp = (WCHAR*)malloc(resultLen * sizeof(WCHAR)); > 141 if (tmp == NULL) { > 142 len = 0; <<<<<<<<<<<<<<<<<<< HERE malloc failed so we need to bail out. We will now skip to line 161 > 143 } else { > 144 WCHAR *p = result; > 145 p += prefixLen; > 146 if (isUnc) { > 147 WCHAR *p2 = tmp; > 148 p2[0] = L'\\'; > 149 p2++; > 150 wcscpy(p2, p); > 151 } else { > 152 wcscpy(tmp, p); > 153 } > 154 free(result); > 155 result = tmp; > 156 } > 157 } > 158 } > 159 > 160 /* unable to get final path */ > 161 if (len == 0 && result != NULL) { We reach here because len==0 and result != NULL > 162 free(result); > 163 result = NULL; > 164 } > 165 } Looks fine to me. David > -Chris. From henry.jen at oracle.com Fri Feb 8 00:15:53 2013 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 07 Feb 2013 16:15:53 -0800 Subject: Early review on NIO Stream APIs Message-ID: <511443B9.2060505@oracle.com> Hi, While lambda still finalizing the final API for Stream, there are a couple of streamifaction APIs in nio area, which I would like to start circling around to get early feedbacks. Those APIs return a CloseableStream, other than that, there is not much directly connection to Stream definition. The specdiff and webrev is available at http://cr.openjdk.java.net/~henryjen/ccc/8006884.0/ Please include me in the reply as I don't necessary receiving emails from all aliases. Cheers, Henry From forax at univ-mlv.fr Fri Feb 8 00:23:45 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 08 Feb 2013 01:23:45 +0100 Subject: [JSR310 M7 Review request] 8007392: JSR310 DateTime API Updates In-Reply-To: <5113F308.6040102@oracle.com> References: <5113F308.6040102@oracle.com> Message-ID: <51144591.4050108@univ-mlv.fr> I wonder if it's not better to declare enum constants of DayOfWeek (and Month) in an order that is not the usual week/month order to make clear that ordinal() doesn't work as expected. By example they can be declared in alphabetical order. cheers, R?mi On 02/07/2013 07:31 PM, Xueming Shen wrote: > > 8007392: JSR 310: DateTime API Updates > > Webrev: > http://cr.openjdk.java.net/~sherman/8007392/ > http://cr.openjdk.java.net/~sherman/8007392/javadoc > > Note: > The Threeten API has been updated based on reviews and continued > development. The main changes included here are > > - Consolidating Chronology classes for local calendars in a > new java.time.chrono package > - Merging the localized calendars into java.time.chrono > (removing package java.time.calendar) > - Moving Year, YearMonth, MonthDay to java.time > - Rename DateTimeFormatter print method to format() > - Move DateTimeFormatters static methods to DateTimeFormatter > - Redesign/remove DateTimeBuilder class - becomes package private > - Replace TemporalAdder/Subtractor with TemporalAmount > - Remove DateTimePrintException > - Move OffsetDateTime and OffsetTime to java.time package > - Remove OffsetDate > - Rename chrono to chronology in class and method names > - Rename ISO* classes and methods to Iso* > - Refactor Period to be date based year/month/day > - Refactor Duration to be time based h/m/s > > Thanks! > -Sherman > > > > > From zhong.j.yu at gmail.com Fri Feb 8 02:53:04 2013 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Thu, 7 Feb 2013 20:53:04 -0600 Subject: Early review on NIO Stream APIs In-Reply-To: <511443B9.2060505@oracle.com> References: <511443B9.2060505@oracle.com> Message-ID: The find() method uses a BiPredicate matcher what about using the existing java.nio.file.PathMatcher interface? There are already some implementations of PathMatcher both in JDK and in the wild. PathMatcher doesn't accept the file attributes though, but that's a problem for most Path-based APIs - path alone often isn't enough and app has to look up attributes in a separate step. Zhong Yu On Thu, Feb 7, 2013 at 6:15 PM, Henry Jen wrote: > Hi, > > While lambda still finalizing the final API for Stream, there are a > couple of streamifaction APIs in nio area, which I would like to start > circling around to get early feedbacks. > > Those APIs return a CloseableStream, other than that, there is not much > directly connection to Stream definition. > > The specdiff and webrev is available at > > http://cr.openjdk.java.net/~henryjen/ccc/8006884.0/ > > Please include me in the reply as I don't necessary receiving emails > from all aliases. > > Cheers, > Henry From henry.jen at oracle.com Fri Feb 8 04:45:52 2013 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 7 Feb 2013 20:45:52 -0800 Subject: Early review on NIO Stream APIs In-Reply-To: References: <511443B9.2060505@oracle.com> Message-ID: <6BA0AD92-429C-4AC5-909D-57D53326ABA8@oracle.com> BiPredicate is a intentional choice, as during the walk process, the attribute is read and many times, filtering is based on file attributes. PathMatcher is basically a Predicate, developer can easily use that in a filter with walk, which return a Stream. Hope that helps. Cheers, Henry On Feb 7, 2013, at 6:53 PM, Zhong Yu wrote: > The find() method uses a > > BiPredicate matcher > > what about using the existing java.nio.file.PathMatcher interface? > There are already some implementations of PathMatcher both in JDK and > in the wild. > > PathMatcher doesn't accept the file attributes though, but that's a > problem for most Path-based APIs - path alone often isn't enough and > app has to look up attributes in a separate step. > > Zhong Yu > > On Thu, Feb 7, 2013 at 6:15 PM, Henry Jen wrote: >> Hi, >> >> While lambda still finalizing the final API for Stream, there are a >> couple of streamifaction APIs in nio area, which I would like to start >> circling around to get early feedbacks. >> >> Those APIs return a CloseableStream, other than that, there is not much >> directly connection to Stream definition. >> >> The specdiff and webrev is available at >> >> http://cr.openjdk.java.net/~henryjen/ccc/8006884.0/ >> >> Please include me in the reply as I don't necessary receiving emails >> from all aliases. >> >> Cheers, >> Henry From joe.darcy at oracle.com Fri Feb 8 04:47:42 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 08 Feb 2013 04:47:42 +0000 Subject: hg: jdk8/tl/langtools: 7195131: Update 2 compiler combo tests for repeating annotations to include package and default use cases Message-ID: <20130208044749.690294791E@hg.openjdk.java.net> Changeset: 5125b9854d07 Author: darcy Date: 2013-02-07 20:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5125b9854d07 7195131: Update 2 compiler combo tests for repeating annotations to include package and default use cases Reviewed-by: darcy Contributed-by: sonali.goel at oracle.com ! 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 zhong.j.yu at gmail.com Fri Feb 8 05:10:30 2013 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Thu, 7 Feb 2013 23:10:30 -0600 Subject: Early review on NIO Stream APIs In-Reply-To: <6BA0AD92-429C-4AC5-909D-57D53326ABA8@oracle.com> References: <511443B9.2060505@oracle.com> <6BA0AD92-429C-4AC5-909D-57D53326ABA8@oracle.com> Message-ID: On Thu, Feb 7, 2013 at 10:45 PM, Henry Jen wrote: > BiPredicate is a intentional choice, as during the walk process, the attribute is read and many times, filtering is based on file attributes. > > PathMatcher is basically a Predicate, developer can easily use that in a filter with walk, which return a Stream. I see. It's a pity that we don't have an abstraction for Path+Attributes, since often applications need both. > Hope that helps. > > Cheers, > Henry > > On Feb 7, 2013, at 6:53 PM, Zhong Yu wrote: > >> The find() method uses a >> >> BiPredicate matcher >> >> what about using the existing java.nio.file.PathMatcher interface? >> There are already some implementations of PathMatcher both in JDK and >> in the wild. >> >> PathMatcher doesn't accept the file attributes though, but that's a >> problem for most Path-based APIs - path alone often isn't enough and >> app has to look up attributes in a separate step. >> >> Zhong Yu >> >> On Thu, Feb 7, 2013 at 6:15 PM, Henry Jen wrote: >>> Hi, >>> >>> While lambda still finalizing the final API for Stream, there are a >>> couple of streamifaction APIs in nio area, which I would like to start >>> circling around to get early feedbacks. >>> >>> Those APIs return a CloseableStream, other than that, there is not much >>> directly connection to Stream definition. >>> >>> The specdiff and webrev is available at >>> >>> http://cr.openjdk.java.net/~henryjen/ccc/8006884.0/ >>> >>> Please include me in the reply as I don't necessary receiving emails >>> from all aliases. >>> >>> Cheers, >>> Henry > From joe.darcy at oracle.com Fri Feb 8 05:58:07 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 07 Feb 2013 21:58:07 -0800 Subject: Missing @since tags In-Reply-To: References: <5113DB2A.1000001@oracle.com> <5113E91D.8060608@oracle.com> Message-ID: <511493EF.7050200@oracle.com> Hi Martin, On 02/07/2013 10:29 AM, Martin Buchholz wrote: > On Thu, Feb 7, 2013 at 9:49 AM, Alan Bateman wrote: > >> On 07/02/2013 17:40, Martin Buchholz wrote: >> >>> Alternatively, maybe this is a job for an annotation processor. >> > IIRC, we considered that 6 years ago. It might be possible, but consider > that you need to diff multiple jdk implementations, and the annotation > processor needs to be able to grok javadoc comments. Also, there are no > "annotations" being processed, so it's weird to use an annotation > processor. Writing a javadoc doclet is another approach that might work. IIRC, your @since checker was based on parsing javadoc output. If so, it (like BlenderRev) might have been rendered unusable out of the box due to the changes in javadoc output made since those tools were written. Annotation processors don't need to process annotations, they are general-purpose meta-programming tools that happen to look at annotations :-) For such a tool to work, it needs to be able to know what was *really* part of JDK (N-1), regardless of @since mark-up, to find out what is now being added in JDK N. I strongly agree that this property should be checked by some kind of tool since engineers have a long history of forgetting to add the tags at the right time. -Joe From vicente.romero at oracle.com Fri Feb 8 09:14:07 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 08 Feb 2013 09:14:07 +0000 Subject: hg: jdk8/tl/langtools: 7166455: javac doesn't set ACC_STRICT bit on for strictfp class Message-ID: <20130208091412.4506D47935@hg.openjdk.java.net> Changeset: 762d0af062f5 Author: vromero Date: 2013-02-08 09:12 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/762d0af062f5 7166455: javac doesn't set ACC_STRICT bit on for strictfp class Reviewed-by: mcimadamore ! 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/jvm/Gen.java + test/tools/javac/7166455/CheckACC_STRICTFlagOnclinitTest.java From vicente.romero at oracle.com Fri Feb 8 09:16:56 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 08 Feb 2013 09:16:56 +0000 Subject: hg: jdk8/tl/langtools: 8005931: javac doesn't set ACC_STRICT for classes with package access Message-ID: <20130208091658.A12BE47936@hg.openjdk.java.net> Changeset: b1deb90d2e37 Author: vromero Date: 2013-02-08 09:15 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b1deb90d2e37 8005931: javac doesn't set ACC_STRICT for classes with package access Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/8005931/CheckACC_STRICTFlagOnPkgAccessClassTest.java From vicente.romero at oracle.com Fri Feb 8 09:22:22 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 08 Feb 2013 09:22:22 +0000 Subject: hg: jdk8/tl/langtools: 7167125: Two variables after the same operation in a inner class return different results Message-ID: <20130208092224.F166D47937@hg.openjdk.java.net> Changeset: 017e8bdd440f Author: vromero Date: 2013-02-08 09:21 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/017e8bdd440f 7167125: Two variables after the same operation in a inner class return different results Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/7167125/DiffResultAfterSameOperationInnerClasses.java From erik.joelsson at oracle.com Fri Feb 8 09:51:58 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 08 Feb 2013 10:51:58 +0100 Subject: [JSR310 M7 Review request] 8007572: Replace existing jdk timezone data at /lib/zi with JSR310's tzdb. In-Reply-To: <5113F31A.3080704@oracle.com> References: <5113F31A.3080704@oracle.com> Message-ID: <5114CABE.3070809@oracle.com> The build part of this review looks good to me. /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 chris.hegarty at oracle.com Fri Feb 8 10:45:17 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 08 Feb 2013 10:45:17 +0000 Subject: RFR JDK-8007609 In-Reply-To: <511443B2.6030705@oracle.com> References: <51127084.3080206@oracle.com> <51138587.1010801@oracle.com> <511394C0.6040908@oracle.com> <511395FA.8060108@oracle.com> <5113A402.6050905@oracle.com> <511443B2.6030705@oracle.com> Message-ID: <5114D73D.8080903@oracle.com> Apologies, you are correct. I'll book an appointment with the optician! -Chris. On 08/02/2013 00:15, David Holmes wrote: > On 7/02/2013 10:54 PM, Chris Hegarty wrote: >> On 02/07/2013 11:54 AM, David Holmes wrote: >>> .... >>>> AFAICS setting len=0 means len==0 will be true and so we will >>>> free(result). >>> >>> And if len != 0 then we will have already freed result, so avoiding a >>> double-free. >> >> Here's the code as it stands today. > > Yes .... I don't see the problem > >> >> 113 result = (WCHAR*)malloc(MAX_PATH * sizeof(WCHAR)); >> 114 if (result != NULL) { > > we've entered this block so we must free result evetually. > >> 115 DWORD len = (*GetFinalPathNameByHandle_func)(h, result, MAX_PATH, 0); >> 116 if (len >= MAX_PATH) { >> 117 /* retry with a buffer of the right size */ >> 118 result = (WCHAR*)realloc(result, (len+1) * sizeof(WCHAR)); >> 119 if (result != NULL) { >> 120 len = (*GetFinalPathNameByHandle_func)(h, result, len, 0); >> 121 } else { >> 122 len = 0; >> 123 } >> 124 } >> 125 if (len > 0) { > > len was good so we've gone this path > >> 126 /** >> 127 * Strip prefix (should be \\?\ or \\?\UNC) >> 128 */ >> 129 if (result[0] == L'\\' && result[1] == L'\\' && >> 130 result[2] == L'?' && result[3] == L'\\') >> 131 { >> 132 int isUnc = (result[4] == L'U' && >> 133 result[5] == L'N' && >> 134 result[6] == L'C'); >> 135 int prefixLen = (isUnc) ? 7 : 4; >> 136 /* actual result length (includes terminator) */ >> 137 int resultLen = len - prefixLen + (isUnc ? 1 : 0) + 1; >> 138 >> 139 /* copy result without prefix into new buffer */ >> 140 WCHAR *tmp = (WCHAR*)malloc(resultLen * sizeof(WCHAR)); >> 141 if (tmp == NULL) { >> 142 len = 0; <<<<<<<<<<<<<<<<<<< HERE > > malloc failed so we need to bail out. We will now skip to line 161 > >> 143 } else { >> 144 WCHAR *p = result; >> 145 p += prefixLen; >> 146 if (isUnc) { >> 147 WCHAR *p2 = tmp; >> 148 p2[0] = L'\\'; >> 149 p2++; >> 150 wcscpy(p2, p); >> 151 } else { >> 152 wcscpy(tmp, p); >> 153 } >> 154 free(result); >> 155 result = tmp; >> 156 } >> 157 } >> 158 } >> 159 >> 160 /* unable to get final path */ >> 161 if (len == 0 && result != NULL) { > > We reach here because len==0 and result != NULL > >> 162 free(result); >> 163 result = NULL; >> 164 } >> 165 } > > Looks fine to me. > David > >> -Chris. From fweimer at redhat.com Fri Feb 8 11:00:41 2013 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 08 Feb 2013 12:00:41 +0100 Subject: [JSR310 M7 Review request] 8007392: JSR310 DateTime API Updates In-Reply-To: <5113F308.6040102@oracle.com> References: <5113F308.6040102@oracle.com> Message-ID: <5114DAD9.20805@redhat.com> On 02/07/2013 07:31 PM, Xueming Shen wrote: > > 8007392: JSR 310: DateTime API Updates > > Webrev: > http://cr.openjdk.java.net/~sherman/8007392/ > http://cr.openjdk.java.net/~sherman/8007392/javadoc I don't think you mention that the reference to ISO 8601 actually refers to ISO 8601:1988 with Technical Corrigendum 1 applied. That would be ISO 8601:1988/Cor.1:1991 (E). The original standard numbered hours from 1 to 24 and minutes and seconds from 1 to 60, although it is somewhat self-contradictory in this area. -- Florian Weimer / Red Hat Product Security Team From scolebourne at joda.org Fri Feb 8 11:11:20 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 8 Feb 2013 11:11:20 +0000 Subject: [JSR310 M7 Review request] 8007392: JSR310 DateTime API Updates In-Reply-To: <5114DAD9.20805@redhat.com> References: <5113F308.6040102@oracle.com> <5114DAD9.20805@redhat.com> Message-ID: On 8 February 2013 11:00, Florian Weimer wrote: >> 8007392: JSR 310: DateTime API Updates >> >> Webrev: >> http://cr.openjdk.java.net/~sherman/8007392/ >> http://cr.openjdk.java.net/~sherman/8007392/javadoc > > > I don't think you mention that the reference to ISO 8601 actually refers to > ISO 8601:1988 with Technical Corrigendum 1 applied. That would be ISO > 8601:1988/Cor.1:1991 (E). > > The original standard numbered hours from 1 to 24 and minutes and seconds > from 1 to 60, although it is somewhat self-contradictory in this area. Just to note that the latest ISO-8601 is the 2004 version. Question is whether specifying a particular version is overly limiting on the specification (and we have never slavishly followed every last detail of the spec anyway). Stephen From scolebourne at joda.org Fri Feb 8 11:12:38 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 8 Feb 2013 11:12:38 +0000 Subject: [JSR310 M7 Review request] 8007392: JSR310 DateTime API Updates In-Reply-To: <51144591.4050108@univ-mlv.fr> References: <5113F308.6040102@oracle.com> <51144591.4050108@univ-mlv.fr> Message-ID: On 8 February 2013 00:23, Remi Forax wrote: > I wonder if it's not better to declare enum constants of DayOfWeek (and > Month) in an order that is not the usual week/month order to make clear that > ordinal() doesn't work as expected. > By example they can be declared in alphabetical order. The constants need to be in order as Enums are Comparable. (It was actually a mistake that all enums are Comparable, but not one that can be fixed now) Stephen From Ulf.Zibis at CoSoCo.de Fri Feb 8 12:09:24 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Fri, 08 Feb 2013 13:09:24 +0100 Subject: Early review on NIO Stream APIs In-Reply-To: <511443B9.2060505@oracle.com> References: <511443B9.2060505@oracle.com> Message-ID: <5114EAF4.8090308@CoSoCo.de> Am 08.02.2013 01:15, schrieb Henry Jen: > The specdiff and webrev is available at > > http://cr.openjdk.java.net/~henryjen/ccc/8006884.0/ > > Please include me in the reply as I don't necessary receiving emails > from all aliases. In Files.lines(...): After returned from this method, if an I/O error occurs reading ... should be: After returned from this method, if an I/O error occurs while reading ... In Files.walk(...): ... a given staring file... should be: ... a given starting file... Do those streams close automatically from finalize() method, if released to GC, e.g. by nulling the referencing variable? ...and if not, why? -Ulf From forax at univ-mlv.fr Fri Feb 8 13:56:44 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 08 Feb 2013 14:56:44 +0100 Subject: [JSR310 M7 Review request] 8007392: JSR310 DateTime API Updates In-Reply-To: References: <5113F308.6040102@oracle.com> <51144591.4050108@univ-mlv.fr> Message-ID: <5115041C.5080807@univ-mlv.fr> On 02/08/2013 12:12 PM, Stephen Colebourne wrote: > On 8 February 2013 00:23, Remi Forax wrote: >> I wonder if it's not better to declare enum constants of DayOfWeek (and >> Month) in an order that is not the usual week/month order to make clear that >> ordinal() doesn't work as expected. >> By example they can be declared in alphabetical order. > The constants need to be in order as Enums are Comparable. > > (It was actually a mistake that all enums are Comparable, but not one > that can be fixed now) don't get it, English calendar starts with Sunday, French one with Monday, so the result of Sunday.compareTo(Monday) is dubious, that why I think that the only valid order is the lexical one. > > Stephen R?mi From Roger.Riggs at oracle.com Fri Feb 8 14:15:44 2013 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 08 Feb 2013 09:15:44 -0500 Subject: [JSR310 M7 Review request] 8007392: JSR310 DateTime API Updates In-Reply-To: References: <5113F308.6040102@oracle.com> <5114DAD9.20805@redhat.com> Message-ID: <51150890.7050208@oracle.com> Hi, We may need to tighten this up; by calling out ISO, folks may incorrectly assume various features that are by design not reflected in the API. Either we need to say what aspects of 8601 and version the API conforms to and /or list the variances. Roger On 2/8/2013 6:11 AM, Stephen Colebourne wrote: > On 8 February 2013 11:00, Florian Weimer wrote: >>> 8007392: JSR 310: DateTime API Updates >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sherman/8007392/ >>> http://cr.openjdk.java.net/~sherman/8007392/javadoc >> >> I don't think you mention that the reference to ISO 8601 actually refers to >> ISO 8601:1988 with Technical Corrigendum 1 applied. That would be ISO >> 8601:1988/Cor.1:1991 (E). >> >> The original standard numbered hours from 1 to 24 and minutes and seconds >> from 1 to 60, although it is somewhat self-contradictory in this area. > Just to note that the latest ISO-8601 is the 2004 version. > > Question is whether specifying a particular version is overly limiting > on the specification (and we have never slavishly followed every last > detail of the spec anyway). > > Stephen -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From fweimer at redhat.com Fri Feb 8 14:26:51 2013 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 08 Feb 2013 15:26:51 +0100 Subject: [JSR310 M7 Review request] 8007392: JSR310 DateTime API Updates In-Reply-To: <51150890.7050208@oracle.com> References: <5113F308.6040102@oracle.com> <5114DAD9.20805@redhat.com> <51150890.7050208@oracle.com> Message-ID: <51150B2B.20005@redhat.com> On 02/08/2013 03:15 PM, Roger Riggs wrote: > We may need to tighten this up; by calling out ISO, folks may > incorrectly assume various features that are by design not reflected in > the API. > > Either we need to say what aspects of 8601 and version the API conforms to > and /or list the variances. You could also reference RFC 3339 and build on top of that, considering that most ISO standards (including 8601, it seems) are not widely available. -- Florian Weimer / Red Hat Product Security Team From martinrb at google.com Fri Feb 8 16:35:04 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 8 Feb 2013 08:35:04 -0800 Subject: Missing @since tags In-Reply-To: <511493EF.7050200@oracle.com> References: <5113DB2A.1000001@oracle.com> <5113E91D.8060608@oracle.com> <511493EF.7050200@oracle.com> Message-ID: On Thu, Feb 7, 2013 at 9:58 PM, Joe Darcy wrote: > Hi Martin, > > IIRC, your @since checker was based on parsing javadoc output. If so, it > (like BlenderRev) might have been rendered unusable out of the box due to > the changes in javadoc output made since those tools were written. > It's absolutely true that findMissingSince is a crappy script that is very brittle due to parsing generated javadoc, and has to be tweaked every time javadoc output changes. OTOH, it is one of those crude yet effective tools that may be the shortest path to finding jdk8's missing @since. I challenge you to demonstrate a tool that can do better! In any case, please share whatever tool you end up using in openjdk. From john.zavgren at oracle.com Fri Feb 8 17:03:14 2013 From: john.zavgren at oracle.com (John Zavgren) Date: Fri, 08 Feb 2013 12:03:14 -0500 Subject: RFR JDK-8007609 In-Reply-To: <5114D73D.8080903@oracle.com> References: <51127084.3080206@oracle.com> <51138587.1010801@oracle.com> <511394C0.6040908@oracle.com> <511395FA.8060108@oracle.com> <5113A402.6050905@oracle.com> <511443B2.6030705@oracle.com> <5114D73D.8080903@oracle.com> Message-ID: <51152FD2.8040706@oracle.com> Greetings: I posted a new webrev image: http://cr.openjdk.java.net/~jzavgren/8007609/webrev.03/ The sole "functional" revision is contained in the following small code snippet: - /* retry with a buffer of the right size */ - result = (WCHAR*)realloc(result, (len+1) * sizeof(WCHAR)); - if (result != NULL) { - len = (*GetFinalPathNameByHandle_func)(h, result, len, 0); - } else { + /* retry the procedure with a buffer of the right size. */ + WCHAR * newResult = (WCHAR*)realloc(result, (len+1) * sizeof(WCHAR)); + if (newResult != NULL) { + result = newResult; + len = (*GetFinalPathNameByHandle_func)(h, newResult, len, 0); + } else and, the innovation is the use of a local variable to hold the attempted memory reallocation. This makes the code simpler and easier to understand. I introduced a huge number of additional changes in the file that are my attempt to make the file consistent with our style guidelines. Changes include: 1.) elimination of tab characters. 2.) spelling, punctuation, and grammar corrections in the comments. 3.) truncation of lines that exceed 80 characters 4.) correction of indentation, line wrapping, etc. I hope I haven't missed anything. http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html On 02/08/2013 05:45 AM, Chris Hegarty wrote: > Apologies, you are correct. I'll book an appointment with the optician! > > -Chris. > > On 08/02/2013 00:15, David Holmes wrote: >> On 7/02/2013 10:54 PM, Chris Hegarty wrote: >>> On 02/07/2013 11:54 AM, David Holmes wrote: >>>> .... >>>>> AFAICS setting len=0 means len==0 will be true and so we will >>>>> free(result). >>>> >>>> And if len != 0 then we will have already freed result, so avoiding a >>>> double-free. >>> >>> Here's the code as it stands today. >> >> Yes .... I don't see the problem >> >>> >>> 113 result = (WCHAR*)malloc(MAX_PATH * sizeof(WCHAR)); >>> 114 if (result != NULL) { >> >> we've entered this block so we must free result evetually. >> >>> 115 DWORD len = (*GetFinalPathNameByHandle_func)(h, result, >>> MAX_PATH, 0); >>> 116 if (len >= MAX_PATH) { >>> 117 /* retry with a buffer of the right size */ >>> 118 result = (WCHAR*)realloc(result, (len+1) * sizeof(WCHAR)); >>> 119 if (result != NULL) { >>> 120 len = (*GetFinalPathNameByHandle_func)(h, result, len, 0); >>> 121 } else { >>> 122 len = 0; >>> 123 } >>> 124 } >>> 125 if (len > 0) { >> >> len was good so we've gone this path >> >>> 126 /** >>> 127 * Strip prefix (should be \\?\ or \\?\UNC) >>> 128 */ >>> 129 if (result[0] == L'\\' && result[1] == L'\\' && >>> 130 result[2] == L'?' && result[3] == L'\\') >>> 131 { >>> 132 int isUnc = (result[4] == L'U' && >>> 133 result[5] == L'N' && >>> 134 result[6] == L'C'); >>> 135 int prefixLen = (isUnc) ? 7 : 4; >>> 136 /* actual result length (includes terminator) */ >>> 137 int resultLen = len - prefixLen + (isUnc ? 1 : 0) + 1; >>> 138 >>> 139 /* copy result without prefix into new buffer */ >>> 140 WCHAR *tmp = (WCHAR*)malloc(resultLen * sizeof(WCHAR)); >>> 141 if (tmp == NULL) { >>> 142 len = 0; <<<<<<<<<<<<<<<<<<< HERE >> >> malloc failed so we need to bail out. We will now skip to line 161 >> >>> 143 } else { >>> 144 WCHAR *p = result; >>> 145 p += prefixLen; >>> 146 if (isUnc) { >>> 147 WCHAR *p2 = tmp; >>> 148 p2[0] = L'\\'; >>> 149 p2++; >>> 150 wcscpy(p2, p); >>> 151 } else { >>> 152 wcscpy(tmp, p); >>> 153 } >>> 154 free(result); >>> 155 result = tmp; >>> 156 } >>> 157 } >>> 158 } >>> 159 >>> 160 /* unable to get final path */ >>> 161 if (len == 0 && result != NULL) { >> >> We reach here because len==0 and result != NULL >> >>> 162 free(result); >>> 163 result = NULL; >>> 164 } >>> 165 } >> >> Looks fine to me. >> David >> >>> -Chris. -- John Zavgren john.zavgren at oracle.com 603-821-0904 US-Burlington-MA From nils.loodin at oracle.com Fri Feb 8 17:10:02 2013 From: nils.loodin at oracle.com (Nils Loodin) Date: Fri, 08 Feb 2013 18:10:02 +0100 Subject: RFR: 8007806: Need a Throwables performance counter Message-ID: <5115316A.8050109@oracle.com> It would be interesting to know the number of thrown throwables in the JVM, to be able to do some high level application diagnostics / statistics. A good way to put this number would be a performance counter, since it is accessible both from Java and from the VM. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007806 http://cr.openjdk.java.net/~nloodin/8007806/webrev.00/ Regards, Nils Loodin From henry.jen at oracle.com Fri Feb 8 17:25:32 2013 From: henry.jen at oracle.com (Henry Jen) Date: Fri, 08 Feb 2013 09:25:32 -0800 Subject: Early review on NIO Stream APIs In-Reply-To: <5114EAF4.8090308@CoSoCo.de> References: <511443B9.2060505@oracle.com> <5114EAF4.8090308@CoSoCo.de> Message-ID: <5115350C.4050004@oracle.com> On 02/08/2013 04:09 AM, Ulf Zibis wrote: > Am 08.02.2013 01:15, schrieb Henry Jen: > In Files.lines(...): > After returned from this method, if an I/O error occurs reading ... > should be: > After returned from this method, if an I/O error occurs while reading ... > > In Files.walk(...): > ... a given staring file... > should be: > ... a given starting file... > Fixed, thanks. > Do those streams close automatically from finalize() method, if released > to GC, e.g. by nulling the referencing variable? ...and if not, why? > The stream doesn't do that, it's transparent to whatever the underlying Closeable resource's behavior. Cheers, Henry From naoto.sato at oracle.com Fri Feb 8 17:36:43 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 08 Feb 2013 17:36:43 +0000 Subject: hg: jdk8/tl/jdk: 8007038: ArrayIndexOutOfBoundsException on calling localizedDateTime().print() with JapaneseChrono Message-ID: <20130208173718.23C2E4794A@hg.openjdk.java.net> Changeset: 79d7595abe95 Author: naoto Date: 2013-02-08 09:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/79d7595abe95 8007038: ArrayIndexOutOfBoundsException on calling localizedDateTime().print() with JapaneseChrono Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java + test/java/util/Calendar/Bug8007038.java From Ulf.Zibis at CoSoCo.de Fri Feb 8 17:50:46 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Fri, 08 Feb 2013 18:50:46 +0100 Subject: Early review on NIO Stream APIs In-Reply-To: <5115350C.4050004@oracle.com> References: <511443B9.2060505@oracle.com> <5114EAF4.8090308@CoSoCo.de> <5115350C.4050004@oracle.com> Message-ID: <51153AF6.9090305@CoSoCo.de> Am 08.02.2013 18:25, schrieb Henry Jen: > On 02/08/2013 04:09 AM, Ulf Zibis wrote: >> Do those streams close automatically from finalize() method, if released >> to GC, e.g. by nulling the referencing variable? ...and if not, why? > The stream doesn't do that, it's transparent to whatever the underlying > Closeable resource's behavior. :-( -Ulf From kumar.x.srinivasan at oracle.com Fri Feb 8 18:19:42 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 08 Feb 2013 10:19:42 -0800 Subject: RFR: 8007519: [unpack200] produces bad class files when producing BootstrapMethods attribute Message-ID: <511541BE.2060907@oracle.com> Hi, Please review http://cr.openjdk.java.net/~ksrini/8007519/webrev.0/ Bug: https://jbs.oracle.com/bugs/browse/JDK-8007519 Thanks Kumar From krystal.mo at oracle.com Fri Feb 8 18:38:00 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Fri, 08 Feb 2013 10:38:00 -0800 Subject: Request for review (M): JDK-7087570: java.lang.invoke.MemberName information wrong for method handles created with findConstructor Message-ID: <51154608.2030401@oracle.com> Hi all, Could I have a couple of review for this change: 7087570: java.lang.invoke.MemberName information wrong for method handles created with findConstructor Summary: REF_invokeSpecial DMHs (which are unusual) get marked explicitly; tweak the MHI to use this bit Reviewed-by: ? Webrev: http://cr.openjdk.java.net/~kmo/7087570/webrev.00/ Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7087570 ( And a duplicate of this: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005119 ) Background: When linking methods, HotSpot VM may strength-reduce the invocation mode of some virtual methods from invokevirtual to invokespecial. e.g. virtual methods in a final class, or non-private member methods marked as final. When that happens, a method's invocation mode may be nominally "invokevirtual", but the VM actually treats it as "invokespecial". Before this fix, the Java-level MethodHandle implementation didn't tell apart the "real" invokespecials with the strength-reduced ones. When creating a MethodHandle via lookup/ldc/unreflect, wrong metadata may be returned if this strength-reduction happened. This broke a few things, including the two scenarios in JDK-7087570 and JDK-8005119. With the fix, special handling is added so that a "real" invokespecial is truly a "Special" version of DirectMethodHandle, so users of the MethodHandle will not be affected by the mismatch between the nominal and the actual invocation mode. For the record, credit goes to John Rose who did the actual fix. I only added the unit test to verify the fix. Tested with JPRT, jtreg test/java/lang/invoke, including the new unit test. I intend to push this to jdk8/tl/jdk as it's a Java-only change; I believe langtool people could get the bits earlier this way. Could somebody from the jdk side help with the push? Thanks, Kris From james.holmlund at oracle.com Fri Feb 8 18:43:23 2013 From: james.holmlund at oracle.com (Jim Holmlund) Date: Fri, 08 Feb 2013 10:43:23 -0800 Subject: RFR: 8007519: [unpack200] produces bad class files when producing BootstrapMethods attribute In-Reply-To: <511541BE.2060907@oracle.com> References: <511541BE.2060907@oracle.com> Message-ID: <5115474B.9020209@oracle.com> Looks good to me. - jjh On 2/8/2013 10:19 AM, Kumar Srinivasan wrote: > Hi, > > Please review > http://cr.openjdk.java.net/~ksrini/8007519/webrev.0/ > > Bug: > https://jbs.oracle.com/bugs/browse/JDK-8007519 > > Thanks > Kumar > From Alan.Bateman at oracle.com Fri Feb 8 19:40:23 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 08 Feb 2013 19:40:23 +0000 Subject: Early review on NIO Stream APIs In-Reply-To: <5114EAF4.8090308@CoSoCo.de> References: <511443B9.2060505@oracle.com> <5114EAF4.8090308@CoSoCo.de> Message-ID: <511554A7.901@oracle.com> On 08/02/2013 12:09, Ulf Zibis wrote: > : > > Do those streams close automatically from finalize() method, if > released to GC, e.g. by nulling the referencing variable? ...and if > not, why? > > -Ulf > We don't use finalizers in this area. Aside from the overhead, the other issue here is that file descriptors are a relatively scarce resource so if the application is not closing files or channels then you'll often run out of file descriptors long before you run out of memory. In any case, I think try-with-resources should be very useful here. -Alan. From Alan.Bateman at oracle.com Fri Feb 8 20:17:18 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 08 Feb 2013 20:17:18 +0000 Subject: RFR JDK-8007609 In-Reply-To: <51152FD2.8040706@oracle.com> References: <51127084.3080206@oracle.com> <51138587.1010801@oracle.com> <511394C0.6040908@oracle.com> <511395FA.8060108@oracle.com> <5113A402.6050905@oracle.com> <511443B2.6030705@oracle.com> <5114D73D.8080903@oracle.com> <51152FD2.8040706@oracle.com> Message-ID: <51155D4E.8010407@oracle.com> On 08/02/2013 17:03, John Zavgren wrote: > Greetings: > I posted a new webrev image: > http://cr.openjdk.java.net/~jzavgren/8007609/webrev.03/ > > > The sole "functional" revision is contained in the following small > code snippet: > > - /* retry with a buffer of the right size */ > - result = (WCHAR*)realloc(result, (len+1) * > sizeof(WCHAR)); > - if (result != NULL) { > - len = (*GetFinalPathNameByHandle_func)(h, result, > len, 0); > - } else { > + /* retry the procedure with a buffer of the right > size. */ > + WCHAR * newResult = (WCHAR*)realloc(result, (len+1) * > sizeof(WCHAR)); > + if (newResult != NULL) { > + result = newResult; > + len = (*GetFinalPathNameByHandle_func)(h, > newResult, len, 0); > + } else > > and, the innovation is the use of a local variable to hold the > attempted memory reallocation. This makes the code simpler and easier > to understand. > > I introduced a huge number of additional changes in the file that are > my attempt to make the file consistent with our style guidelines. > > Changes include: > 1.) elimination of tab characters. > 2.) spelling, punctuation, and grammar corrections in the comments. > 3.) truncation of lines that exceed 80 characters > 4.) correction of indentation, line wrapping, etc. I think the "functional" changes in L121-126 are fine and fixes the issue that this bug is about. I'm not sure what to say about all the re-formatting. Some of it is okay (there is some old code here) but some of the proposed changes make the code a lot less readable (in my view). An example of proposed change that gets on my goat is the removal of the careful alignment of the parameters to CreateFileW. The fixes to typos in comments in other areas are of course welcome. So I'm okay with the fix to the issue and would be happy to sponsor the bug fix portion of the proposed change. -Alan. From joe.darcy at oracle.com Fri Feb 8 20:32:03 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 08 Feb 2013 12:32:03 -0800 Subject: RFR - 6480539: BigDecimal.stripTrailingZeros() should specify no-op on zero BigDecimals In-Reply-To: <511358A2.9090408@paradise.net.nz> References: <51100C97.4040504@oracle.com> <51104CE4.10506@oracle.com> <1BA5F227-8369-4AC4-A108-165A094BD763@oracle.com> <511358A2.9090408@paradise.net.nz> Message-ID: <511560C3.9070009@oracle.com> Hello, On 2/6/2013 11:32 PM, Bruce Chapman wrote: > Stephen, In your case(s) would the workaround fail to work if the bug > was fixed? > > Working around a bug is quite different to taking advantage of the > buggy behaviour. If fixing the bug would break code that works around > it that can be seen as a problem, while breaking code that relies on > the bug is IMHO much less of an issue since anyone that does that is > taking a known risk, or a risk that should reasonably be expected to > be known. > > I am finding it hard to imagine a genuine attempt at a workaround that > would not still work (though redundantly) if the bug was fixed. > > Also bear in mind that there are other implementations, and the > signature and the javadoc are the spec. If you find behaviour that > differs and take advantage of that behaviour then you are opening the > possibility of it changing if either: you run with another > implementation, or the bug gets fixed. > > While it is easy to contrive an example that would break if this bug > were fixed, and it is possible (on the grounds that I cannot prove it > is impossible) that some real code might break, it is hard to imagine > a scenario where the author/owner of that broken code has any morally > legitimate grounds for complaint in that case. > > I guess if you take the "This is one of those unfortunate cases where > a bug can become a feature." approach to its logical conclusion then > no bugs get fixed because there are no bugs, just a nice online list > of newly discovered unexpected features. As noted earlier in this thread, we use a nuanced compatibility policy in evolving the JDK: http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html In particular, besides looking after source and binary compatibility, we also look to manage behavioral compatibility, that is, to be mindful of changing what a method does at runtime when called, even when the specification gives us leeway to do so. Let me relate an example of behavioral compatibility from JDK 7. The method Class.getMethods returns an array of Method objects for the Class and in part its javadoc has long stated: "The elements in the array returned are not sorted and are not in any particular order." Therefore, any caller of Class.getMethods relying on or assuming a particular order has a bug according to the specification. As a side-effect of permgen removal in JDK 7, the long-standing (and mostly stable) order of Method objects returned by HotSpot changed. As expected, some user applications and tests "broke" after this change went in. We received requests to "fix" the ordering of Class.getMethods, which we declined to do given the benefits of permgen removal and the clear specification that no ordering should be relied upon. Even though that change in getMethods is allowed by specification, it is out-of-bounds of what we would do an an update release but in-bounds for a platform release like JDK 7. The reason for this conservatism is because we value keeping the broad usage of the JDK working :-) Getting back to BigDecimal.stripTrailingZeros, we cannot inspect all usages of this method today, nor can we inspect all the future usages of BigDecimal.stripTrailingZeros that will be around before JDK 8 is adopted for the code in question. We know not everyone migrates to a new JDK release promptly; within the past two years I fielded a query/complaint about the behavior change in BigDecimal.toString made between 1.4.2 and JDK 5 and later. For these sorts of reasons, the default resolution when the specification and implementation conflict is to make the specification match the implementation. There are exceptions to this default. Given sufficient evidence that changing the behavior of BigDecimal.stripTrailingZeros would not have adverse consequences on fielded code, we could change its behavior despite being implemented that way for about 9 years. -Joe > > Bruce > > On 7/02/2013 12:16 p.m., Stephen Colebourne wrote: >> On 5 February 2013 09:09, Paul Sandoz wrote: >>> This is one of those unfortunate cases where a bug can become a >>> feature. >> I *really* don't see how. >> >> The method name is absolutely clear about its purpose. "Strip trailing >> zeros". Anyone relying on it not stripping zeroes for zero needs their >> head examining. >> >> This particular one just happens to be one that I've run across twice >> and in both cases it required a workaround. I'd argue that there are >> more people with undiscovered bugs in their code because the method is >> buggy than people who would break were the method fixed. >> >> What bothers me even more is the desire expressed in this thread to >> simply wish away bugs by redefining the documentation. If the method >> name is clear enough, like in this case, then its a bug, and a >> documentation change simply isn't the right solution. >> Stephen >> > From xueming.shen at oracle.com Fri Feb 8 21:23:48 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 08 Feb 2013 13:23:48 -0800 Subject: [JSR310 M7 Review request] 8007392: JSR310 DateTime API Updates In-Reply-To: <5113F308.6040102@oracle.com> References: <5113F308.6040102@oracle.com> Message-ID: <51156CE4.9020503@oracle.com> Hi The webrev and the javadoc have been updated with some last minute changes mainly to support non-iso calendar formatting/parsing. http://cr.openjdk.java.net/~sherman/8007392/ http://cr.openjdk.java.net/~sherman/8007392/javadoc Thanks! -Sherman On 02/07/2013 10:31 AM, Xueming Shen wrote: > > 8007392: JSR 310: DateTime API Updates > > Webrev: > http://cr.openjdk.java.net/~sherman/8007392/ > http://cr.openjdk.java.net/~sherman/8007392/javadoc > > Note: > The Threeten API has been updated based on reviews and continued > development. The main changes included here are > > - Consolidating Chronology classes for local calendars in a > new java.time.chrono package > - Merging the localized calendars into java.time.chrono > (removing package java.time.calendar) > - Moving Year, YearMonth, MonthDay to java.time > - Rename DateTimeFormatter print method to format() > - Move DateTimeFormatters static methods to DateTimeFormatter > - Redesign/remove DateTimeBuilder class - becomes package private > - Replace TemporalAdder/Subtractor with TemporalAmount > - Remove DateTimePrintException > - Move OffsetDateTime and OffsetTime to java.time package > - Remove OffsetDate > - Rename chrono to chronology in class and method names > - Rename ISO* classes and methods to Iso* > - Refactor Period to be date based year/month/day > - Refactor Duration to be time based h/m/s > > Thanks! > -Sherman > > > > > From scolebourne at joda.org Fri Feb 8 22:37:48 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 8 Feb 2013 22:37:48 +0000 Subject: RFR - 6480539: BigDecimal.stripTrailingZeros() should specify no-op on zero BigDecimals In-Reply-To: References: <51100C97.4040504@oracle.com> <51104CE4.10506@oracle.com> <1BA5F227-8369-4AC4-A108-165A094BD763@oracle.com> <511358A2.9090408@paradise.net.nz> <511560C3.9070009@oracle.com> Message-ID: We've established that it causes problems (me and Paul) and that likely workarounds of the bug would not be broken by a fix. The getMethods case is very different as the spec clearly allowed the behavior. Here the spec and method name are also clear on the expected behavior. The proposal would make the behavior out of line with the method name and of no earthly use to users. ie, as a user of that method, I would never be calling it for any reason other than to remove all the trailing zeroes. Mostly the JDK team gets it right. But not this time. Stephen > On 8 Feb 2013 20:32, "Joe Darcy" wrote: >> >> Hello, >> >> On 2/6/2013 11:32 PM, Bruce Chapman wrote: >>> >>> Stephen, In your case(s) would the workaround fail to work if the bug was fixed? >>> >>> Working around a bug is quite different to taking advantage of the buggy behaviour. If fixing the bug would break code that works around it that can be seen as a problem, while breaking code that relies on the bug is IMHO much less of an issue since anyone that does that is taking a known risk, or a risk that should reasonably be expected to be known. >>> >>> I am finding it hard to imagine a genuine attempt at a workaround that would not still work (though redundantly) if the bug was fixed. >>> >>> Also bear in mind that there are other implementations, and the signature and the javadoc are the spec. If you find behaviour that differs and take advantage of that behaviour then you are opening the possibility of it changing if either: you run with another implementation, or the bug gets fixed. >>> >>> While it is easy to contrive an example that would break if this bug were fixed, and it is possible (on the grounds that I cannot prove it is impossible) that some real code might break, it is hard to imagine a scenario where the author/owner of that broken code has any morally legitimate grounds for complaint in that case. >>> >>> I guess if you take the "This is one of those unfortunate cases where a bug can become a feature." approach to its logical conclusion then no bugs get fixed because there are no bugs, just a nice online list of newly discovered unexpected features. >> >> >> As noted earlier in this thread, we use a nuanced compatibility policy in evolving the JDK: >> >> http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html >> >> In particular, besides looking after source and binary compatibility, we also look to manage behavioral compatibility, that is, to be mindful of changing what a method does at runtime when called, even when the specification gives us leeway to do so. >> >> Let me relate an example of behavioral compatibility from JDK 7. The method Class.getMethods returns an array of Method objects for the Class and in part its javadoc has long stated: >> >> "The elements in the array returned are not sorted and are not in any particular order." >> >> Therefore, any caller of Class.getMethods relying on or assuming a particular order has a bug according to the specification. As a side-effect of permgen removal in JDK 7, the long-standing (and mostly stable) order of Method objects returned by HotSpot changed. As expected, some user applications and tests "broke" after this change went in. We received requests to "fix" the ordering of Class.getMethods, which we declined to do given the benefits of permgen removal and the clear specification that no ordering should be relied upon. Even though that change in getMethods is allowed by specification, it is out-of-bounds of what we would do an an update release but in-bounds for a platform release like JDK 7. >> >> The reason for this conservatism is because we value keeping the broad usage of the JDK working :-) >> >> Getting back to BigDecimal.stripTrailingZeros, we cannot inspect all usages of this method today, nor can we inspect all the future usages of BigDecimal.stripTrailingZeros that will be around before JDK 8 is adopted for the code in question. We know not everyone migrates to a new JDK release promptly; within the past two years I fielded a query/complaint about the behavior change in BigDecimal.toString made between 1.4.2 and JDK 5 and later. >> >> For these sorts of reasons, the default resolution when the specification and implementation conflict is to make the specification match the implementation. There are exceptions to this default. Given sufficient evidence that changing the behavior of BigDecimal.stripTrailingZeros would not have adverse consequences on fielded code, we could change its behavior despite being implemented that way for about 9 years. >> >> -Joe >> >>> >>> Bruce >>> >>> On 7/02/2013 12:16 p.m., Stephen Colebourne wrote: >>>> >>>> On 5 February 2013 09:09, Paul Sandoz wrote: >>>>> >>>>> This is one of those unfortunate cases where a bug can become a feature. >>>> >>>> I *really* don't see how. >>>> >>>> The method name is absolutely clear about its purpose. "Strip trailing >>>> zeros". Anyone relying on it not stripping zeroes for zero needs their >>>> head examining. >>>> >>>> This particular one just happens to be one that I've run across twice >>>> and in both cases it required a workaround. I'd argue that there are >>>> more people with undiscovered bugs in their code because the method is >>>> buggy than people who would break were the method fixed. >>>> >>>> What bothers me even more is the desire expressed in this thread to >>>> simply wish away bugs by redefining the documentation. If the method >>>> name is clear enough, like in this case, then its a bug, and a >>>> documentation change simply isn't the right solution. >>>> Stephen >>>> >>> >> From joe.darcy at oracle.com Sat Feb 9 00:00:41 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Sat, 09 Feb 2013 00:00:41 +0000 Subject: hg: jdk8/tl/jdk: 8005623: Retrofit FunctionalInterface annotations to core platform interfaces Message-ID: <20130209000112.8DE1047963@hg.openjdk.java.net> Changeset: 522fb3867a3a Author: darcy Date: 2013-02-08 16:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/522fb3867a3a 8005623: Retrofit FunctionalInterface annotations to core platform interfaces Reviewed-by: mduigou, chegar, alanb ! src/share/classes/java/io/Closeable.java ! src/share/classes/java/io/FileFilter.java ! src/share/classes/java/io/FilenameFilter.java ! src/share/classes/java/io/Flushable.java ! src/share/classes/java/lang/AutoCloseable.java ! src/share/classes/java/lang/Comparable.java ! src/share/classes/java/lang/Iterable.java ! src/share/classes/java/lang/Readable.java ! src/share/classes/java/lang/Runnable.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/nio/file/DirectoryStream.java ! src/share/classes/java/nio/file/PathMatcher.java ! src/share/classes/java/util/Comparator.java ! src/share/classes/java/util/function/BinaryOperator.java ! src/share/classes/java/util/function/Block.java ! src/share/classes/java/util/function/DoubleBinaryOperator.java ! src/share/classes/java/util/function/DoubleBlock.java ! src/share/classes/java/util/function/DoubleFunction.java ! src/share/classes/java/util/function/DoubleSupplier.java ! src/share/classes/java/util/function/DoubleUnaryOperator.java ! src/share/classes/java/util/function/Function.java ! src/share/classes/java/util/function/IntBinaryOperator.java ! src/share/classes/java/util/function/IntBlock.java ! src/share/classes/java/util/function/IntFunction.java ! src/share/classes/java/util/function/IntSupplier.java ! src/share/classes/java/util/function/IntUnaryOperator.java ! src/share/classes/java/util/function/LongBinaryOperator.java ! src/share/classes/java/util/function/LongBlock.java ! src/share/classes/java/util/function/LongFunction.java ! src/share/classes/java/util/function/LongSupplier.java ! src/share/classes/java/util/function/LongUnaryOperator.java ! src/share/classes/java/util/function/Predicate.java ! src/share/classes/java/util/function/Supplier.java ! src/share/classes/java/util/function/UnaryOperator.java ! src/share/classes/java/util/logging/Filter.java ! src/share/classes/java/util/prefs/PreferenceChangeListener.java From jonathan.gibbons at oracle.com Sat Feb 9 01:35:27 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sat, 09 Feb 2013 01:35:27 +0000 Subject: hg: jdk8/tl/langtools: 8007610: javadoc doclint does not work with -private Message-ID: <20130209013533.BE20047968@hg.openjdk.java.net> Changeset: 60caf53b98e2 Author: jjg Date: 2013-02-08 17:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/60caf53b98e2 8007610: javadoc doclint does not work with -private Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! test/com/sun/javadoc/T6735320/T6735320.java ! test/tools/javadoc/doclint/DocLintTest.java From chris.hegarty at oracle.com Sat Feb 9 08:37:27 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sat, 09 Feb 2013 08:37:27 +0000 Subject: hg: jdk8/tl/jdk: 8005697: Add StampedLock Message-ID: <20130209083747.A8AA847974@hg.openjdk.java.net> Changeset: 36d25dc2b8f0 Author: dl Date: 2013-02-09 08:35 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/36d25dc2b8f0 8005697: Add StampedLock Reviewed-by: chegar, alanb, dice, martin ! make/java/java/FILES_java.gmk ! src/share/classes/java/util/concurrent/locks/LockSupport.java + src/share/classes/java/util/concurrent/locks/StampedLock.java + test/java/util/concurrent/locks/StampedLock/Basic.java From weijun.wang at oracle.com Sat Feb 9 08:46:40 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Sat, 09 Feb 2013 08:46:40 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130209084703.D7F1447975@hg.openjdk.java.net> Changeset: d14cd2272b2d Author: weijun Date: 2013-02-09 16:43 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d14cd2272b2d 8001104: Unbound SASL service: the GSSAPI/krb5 mech Reviewed-by: valeriep ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/javax/security/auth/kerberos/JavaxSecurityAuthKerberosAccessImpl.java ! src/share/classes/javax/security/auth/kerberos/KeyTab.java ! src/share/classes/sun/security/jgss/LoginConfigImpl.java ! src/share/classes/sun/security/jgss/krb5/Krb5Util.java ! src/share/classes/sun/security/jgss/krb5/ServiceCreds.java ! src/share/classes/sun/security/jgss/krb5/SubjectComber.java ! src/share/classes/sun/security/krb5/JavaxSecurityAuthKerberosAccess.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/share/classes/sun/security/provider/ConfigSpiFile.java ! test/sun/security/krb5/ServiceCredsCombination.java ! test/sun/security/krb5/auto/AcceptPermissions.java + test/sun/security/krb5/auto/GSSUnbound.java ! test/sun/security/krb5/auto/OneKDC.java + test/sun/security/krb5/auto/SaslUnbound.java + test/sun/security/krb5/auto/UnboundService.java Changeset: 57cb988c811e Author: weijun Date: 2013-02-09 16:43 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/57cb988c811e 8007761: NTLM coding errors Reviewed-by: chegar ! src/share/classes/com/sun/security/ntlm/Client.java ! src/share/classes/com/sun/security/ntlm/NTLM.java From peter.levart at gmail.com Sat Feb 9 09:50:14 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 09 Feb 2013 10:50:14 +0100 Subject: zip64 compatibility problems In-Reply-To: References: <50F6010D.5000806@oracle.com> <5100C3D2.6040604@oracle.com> <5113D311.7060006@oracle.com> Message-ID: <51161BD6.3040608@gmail.com> On 02/07/2013 06:51 PM, Martin Buchholz wrote: > On Thu, Feb 7, 2013 at 8:15 AM, Alan Bateman wrote: > >> On 07/02/2013 01:55, Martin Buchholz wrote: >> >>> Following up, please review the backward compatiblitiy support in: >>> >>> http://cr.openjdk.java.net/~**martin/webrevs/openjdk8/** >>> useZip64For64kEntries/ >>> >>> (ideally users would have even more control via the API, but I ain't gonna >>> try to touch that) >>> >> No objection to adding a knob for this but do we need changes for reading >> too? I'm just concerned that someone could use ZipOutputStream to create a >> zip or JAR file that is not readable (in the same VM). >> >> > Such zip files have always been readable by the JDK's (and other folks') > zip implementations, so no changes should be needed (in theory). I've > already fixed a case where the zip implementation in langtools regressed to > not be able to read such files. > > That said, we could use more testing. > > >> On the property name then we've started using jdk.* for JDK-specific >> properties. Also as the default is to support ZIP64 when writing then maybe >> this should have a disable* name so someone can specify >> -Djdk.util.zip.disableZip64 on the command line without specifying a value. > Can you point me at exemplar code for reading such a system property? > > 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 ? Regards, Peter From Alan.Bateman at oracle.com Sat Feb 9 16:50:05 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 09 Feb 2013 16:50:05 +0000 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <5115316A.8050109@oracle.com> References: <5115316A.8050109@oracle.com> Message-ID: <51167E3D.3060803@oracle.com> On 08/02/2013 17:10, Nils Loodin wrote: > It would be interesting to know the number of thrown throwables in the > JVM, to be able to do some high level application diagnostics / > statistics. A good way to put this number would be a performance > counter, since it is accessible both from Java and from the VM. > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007806 > http://cr.openjdk.java.net/~nloodin/8007806/webrev.00/ > > Regards, > Nils Loodin Nils - this seems incomplete, where is the counter updated? -Alan From kumar.x.srinivasan at oracle.com Sat Feb 9 18:09:09 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Sat, 09 Feb 2013 10:09:09 -0800 Subject: RFR: JDK-8007883: Re-enable pack200 tests for jprt testing on fast systems Message-ID: <511690C5.9000009@oracle.com> Hi, Please review the following patch to reinstate pack200 tests for the fastest systems. In my testing I also found that launcher's I18NJarTest was failing with a known issue on Macs, so I have taken the opportunity to add this as well. Thanks Kumar +++ b/test/ProblemList.txt @@ -317,13 +317,16 @@ # 7132203 sun/jvmstat/monitor/MonitoredVm/CR6672135.java generic-all -# Tests take too long, see 7143279 -tools/pack200/CommandLineTests.java generic-all -tools/pack200/Pack200Test.java generic-all +# Tests take too long, on sparcs see 7143279 +tools/pack200/CommandLineTests.java solaris-all, macosx-all +tools/pack200/Pack200Test.java solaris-all, macosx-all # 7150569 tools/launcher/UnicodeTest.java macosx-all +# 8006039 +tools/launcher/I18NJarTest.java macosx-all + # 8007410 tools/launcher/FXLauncherTest.java linux-all From martinrb at google.com Sat Feb 9 23:09:47 2013 From: martinrb at google.com (Martin Buchholz) Date: Sat, 9 Feb 2013 15:09:47 -0800 Subject: [7u-dev] Request for approval for JDK-7175464 - entrySetView field is never updated in NavigableSubMap In-Reply-To: References: <718E9936-939D-4D0F-941F-6B8696772F4F@oracle.com> <51155565.9070800@cs.oswego.edu> Message-ID: It looks to me like Collections.reverseOrder no longer deserializes to the same object. It also looks like the definition for that in Collections.java hasn't changed recently. So I suspect that there has been some serious incompatible change to deserialization itself. (It's another matter whether that could break TreeSet). (I have long lobbied for more cross-jdk testing focused on seriallization) The program below demonstrates the different behavior between jdk7 and jdk8: import java.util.*; import java.io.*; public class ReverseOrder { public static void main(String[] args) throws Throwable { Comparator c = Collections.reverseOrder(); if (c != serialClone(c)) throw new Error(String.format("c=%s clone=%s", c, serialClone(c))); } static byte[] serialBytes(Object o) { try { ByteArrayOutputStream bos = new ByteArrayOutputStream(); ObjectOutputStream oos = new ObjectOutputStream(bos); oos.writeObject(o); oos.flush(); oos.close(); return bos.toByteArray(); } catch (Throwable t) { throw new Error(t); } } @SuppressWarnings("unchecked") static T serialClone(T o) { try { ObjectInputStream ois = new ObjectInputStream (new ByteArrayInputStream(serialBytes(o))); T clone = (T) ois.readObject(); return clone; } catch (Throwable t) { throw new Error(t); } } } On Fri, Feb 8, 2013 at 3:16 PM, Mike Duigou wrote: > Thank you for catching this Doug. I missed your original post on this > topic during my Christmas vacation. ( > http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-December/013127.htmlfor those following along at home) > > I will definitely hold off and follow up on the potentially bad patch to > Java 8. I have created an issue to resolve the test breakage, JDK-8007889 > > Mike > > On Feb 8 2013, at 11:43 , Doug Lea wrote: > > > On 02/08/13 14:33, Mike Duigou wrote: > >> Hello all; > >> > >> I would like to backport this change from Java 8. It has been baking in > JDK8 for about two months with no problems. > >> > > > > I think it may have problems. > > As I mentioned in a post a few months ago, it seems > > to be responsible for breakage in a TCK/JCK test; > > One derived from a jsr166 tck test at > > > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/TreeSubSetTest.java?view=log > > > > You need the file for context, but it looks like: > > > > public void testDescendingSerialization() throws Exception { > > NavigableSet x = dset5(); > > NavigableSet y = serialClone(x); > > > > assertTrue(x != y); > > assertEquals(x.size(), y.size()); > > assertEquals(x.toString(), y.toString()); > > assertEquals(x, y); > > assertEquals(y, x); > > while (!x.isEmpty()) { > > assertFalse(y.isEmpty()); > > assertEquals(x.pollFirst(), y.pollFirst()); > > } > > assertTrue(y.isEmpty()); > > } > > > > > >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7175464 > >> > >> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/bf6ceb6b8f80 > >> > >> The change was previously reviewed by Alan Bateman, Paul Sandoz and > David Holmes before going in to Java 8. > >> > >> Mike > >> > > > > From martinrb at google.com Sat Feb 9 23:31:02 2013 From: martinrb at google.com (Martin Buchholz) Date: Sat, 9 Feb 2013 15:31:02 -0800 Subject: [7u-dev] Request for approval for JDK-7175464 - entrySetView field is never updated in NavigableSubMap In-Reply-To: References: <718E9936-939D-4D0F-941F-6B8696772F4F@oracle.com> <51155565.9070800@cs.oswego.edu> Message-ID: On Sat, Feb 9, 2013 at 3:09 PM, Martin Buchholz wrote: > It looks to me like Collections.reverseOrder no longer deserializes to the > same object. It also looks like the definition for that in > Collections.java hasn't changed recently. So I suspect that there has been > some serious incompatible change to deserialization itself. > (It's another matter whether that could break TreeSet). > (I have long lobbied for more cross-jdk testing focused on seriallization) > > The program below demonstrates the different behavior between jdk7 and > jdk8: > > Oops - correction - this is not a difference between jdk7 and jdk8, but between jdk8 and lambda8, More specifically, lambda-8-b74 fails, while jdk8-b74 succeeds. Have lambdadukes messed with serialization? > import java.util.*; > import java.io.*; > > public class ReverseOrder { > public static void main(String[] args) throws Throwable { > Comparator c = Collections.reverseOrder(); > if (c != serialClone(c)) > throw new Error(String.format("c=%s clone=%s", > c, serialClone(c))); > } > > static byte[] serialBytes(Object o) { > try { > ByteArrayOutputStream bos = new ByteArrayOutputStream(); > ObjectOutputStream oos = new ObjectOutputStream(bos); > oos.writeObject(o); > oos.flush(); > oos.close(); > return bos.toByteArray(); > } catch (Throwable t) { > throw new Error(t); > } > } > > @SuppressWarnings("unchecked") > static T serialClone(T o) { > try { > ObjectInputStream ois = new ObjectInputStream > (new ByteArrayInputStream(serialBytes(o))); > T clone = (T) ois.readObject(); > return clone; > } catch (Throwable t) { > throw new Error(t); > } > } > } > > > On Fri, Feb 8, 2013 at 3:16 PM, Mike Duigou wrote: > >> Thank you for catching this Doug. I missed your original post on this >> topic during my Christmas vacation. ( >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-December/013127.htmlfor those following along at home) >> >> I will definitely hold off and follow up on the potentially bad patch to >> Java 8. I have created an issue to resolve the test breakage, JDK-8007889 >> >> Mike >> >> On Feb 8 2013, at 11:43 , Doug Lea wrote: >> >> > On 02/08/13 14:33, Mike Duigou wrote: >> >> Hello all; >> >> >> >> I would like to backport this change from Java 8. It has been baking >> in JDK8 for about two months with no problems. >> >> >> > >> > I think it may have problems. >> > As I mentioned in a post a few months ago, it seems >> > to be responsible for breakage in a TCK/JCK test; >> > One derived from a jsr166 tck test at >> > >> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/TreeSubSetTest.java?view=log >> > >> > You need the file for context, but it looks like: >> > >> > public void testDescendingSerialization() throws Exception { >> > NavigableSet x = dset5(); >> > NavigableSet y = serialClone(x); >> > >> > assertTrue(x != y); >> > assertEquals(x.size(), y.size()); >> > assertEquals(x.toString(), y.toString()); >> > assertEquals(x, y); >> > assertEquals(y, x); >> > while (!x.isEmpty()) { >> > assertFalse(y.isEmpty()); >> > assertEquals(x.pollFirst(), y.pollFirst()); >> > } >> > assertTrue(y.isEmpty()); >> > } >> > >> > >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7175464 >> >> >> >> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/bf6ceb6b8f80 >> >> >> >> The change was previously reviewed by Alan Bateman, Paul Sandoz and >> David Holmes before going in to Java 8. >> >> >> >> Mike >> >> >> > >> >> > From martinrb at google.com Sun Feb 10 07:49:39 2013 From: martinrb at google.com (Martin Buchholz) Date: Sat, 9 Feb 2013 23:49:39 -0800 Subject: [7u-dev] Request for approval for JDK-7175464 - entrySetView field is never updated in NavigableSubMap In-Reply-To: References: <718E9936-939D-4D0F-941F-6B8696772F4F@oracle.com> <51155565.9070800@cs.oswego.edu> Message-ID: [adding lambda-dev] Here's another refinement to the test case, which shows that a serial clone of Collections.reverseOrder in lambda8 creates a new instance of a new class with the opposite order (which I can't explain): When run against latest lambda-b76, it gives this output: x=java.util.Collections$ReverseComparator at 3710b205 y=java.util.Collections$ReverseComparator2 at e9b8b810 x: 1 -1 y: -1 1 import java.util.*; import java.io.*; public class ReverseOrder { public static void main(String[] args) throws Throwable { Comparator x = Collections.reverseOrder(); Comparator y = serialClone(x); System.out.printf("x=%s%n", x); System.out.printf("y=%s%n", y); System.out.printf("x: %d %d%n", x.compare(0,1), x.compare(1,0)); System.out.printf("y: %d %d%n", y.compare(0,1), y.compare(1,0)); } static byte[] serialBytes(Object o) { try { ByteArrayOutputStream bos = new ByteArrayOutputStream(); ObjectOutputStream oos = new ObjectOutputStream(bos); oos.writeObject(o); oos.flush(); oos.close(); return bos.toByteArray(); } catch (Throwable t) { throw new Error(t); } } @SuppressWarnings("unchecked") static T serialClone(T o) { try { ObjectInputStream ois = new ObjectInputStream (new ByteArrayInputStream(serialBytes(o))); T clone = (T) ois.readObject(); return clone; } catch (Throwable t) { throw new Error(t); } } } On Sat, Feb 9, 2013 at 3:31 PM, Martin Buchholz wrote: > > > On Sat, Feb 9, 2013 at 3:09 PM, Martin Buchholz wrote: > >> It looks to me like Collections.reverseOrder no longer deserializes to >> the same object. It also looks like the definition for that in >> Collections.java hasn't changed recently. So I suspect that there has been >> some serious incompatible change to deserialization itself. >> (It's another matter whether that could break TreeSet). >> (I have long lobbied for more cross-jdk testing focused on seriallization) >> >> The program below demonstrates the different behavior between jdk7 and >> jdk8: >> >> > Oops - correction - this is not a difference between jdk7 and jdk8, but > between jdk8 and lambda8, More specifically, lambda-8-b74 fails, > while jdk8-b74 succeeds. Have lambdadukes messed with serialization? > > > >> import java.util.*; >> import java.io.*; >> >> public class ReverseOrder { >> public static void main(String[] args) throws Throwable { >> Comparator c = Collections.reverseOrder(); >> if (c != serialClone(c)) >> throw new Error(String.format("c=%s clone=%s", >> c, serialClone(c))); >> } >> >> static byte[] serialBytes(Object o) { >> try { >> ByteArrayOutputStream bos = new ByteArrayOutputStream(); >> ObjectOutputStream oos = new ObjectOutputStream(bos); >> oos.writeObject(o); >> oos.flush(); >> oos.close(); >> return bos.toByteArray(); >> } catch (Throwable t) { >> throw new Error(t); >> } >> } >> >> @SuppressWarnings("unchecked") >> static T serialClone(T o) { >> try { >> ObjectInputStream ois = new ObjectInputStream >> (new ByteArrayInputStream(serialBytes(o))); >> T clone = (T) ois.readObject(); >> return clone; >> } catch (Throwable t) { >> throw new Error(t); >> } >> } >> } >> >> >> On Fri, Feb 8, 2013 at 3:16 PM, Mike Duigou wrote: >> >>> Thank you for catching this Doug. I missed your original post on this >>> topic during my Christmas vacation. ( >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-December/013127.htmlfor those following along at home) >>> >>> I will definitely hold off and follow up on the potentially bad patch to >>> Java 8. I have created an issue to resolve the test breakage, JDK-8007889 >>> >>> Mike >>> >>> On Feb 8 2013, at 11:43 , Doug Lea wrote: >>> >>> > On 02/08/13 14:33, Mike Duigou wrote: >>> >> Hello all; >>> >> >>> >> I would like to backport this change from Java 8. It has been baking >>> in JDK8 for about two months with no problems. >>> >> >>> > >>> > I think it may have problems. >>> > As I mentioned in a post a few months ago, it seems >>> > to be responsible for breakage in a TCK/JCK test; >>> > One derived from a jsr166 tck test at >>> > >>> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/TreeSubSetTest.java?view=log >>> > >>> > You need the file for context, but it looks like: >>> > >>> > public void testDescendingSerialization() throws Exception { >>> > NavigableSet x = dset5(); >>> > NavigableSet y = serialClone(x); >>> > >>> > assertTrue(x != y); >>> > assertEquals(x.size(), y.size()); >>> > assertEquals(x.toString(), y.toString()); >>> > assertEquals(x, y); >>> > assertEquals(y, x); >>> > while (!x.isEmpty()) { >>> > assertFalse(y.isEmpty()); >>> > assertEquals(x.pollFirst(), y.pollFirst()); >>> > } >>> > assertTrue(y.isEmpty()); >>> > } >>> > >>> > >>> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7175464 >>> >> >>> >> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/bf6ceb6b8f80 >>> >> >>> >> The change was previously reviewed by Alan Bateman, Paul Sandoz and >>> David Holmes before going in to Java 8. >>> >> >>> >> Mike >>> >> >>> > >>> >>> >> > From peter.levart at gmail.com Sun Feb 10 10:37:40 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 10 Feb 2013 11:37:40 +0100 Subject: [7u-dev] Request for approval for JDK-7175464 - entrySetView field is never updated in NavigableSubMap In-Reply-To: References: <718E9936-939D-4D0F-941F-6B8696772F4F@oracle.com> <51155565.9070800@cs.oswego.edu> Message-ID: <51177874.4030609@gmail.com> Hi Martin, It seems that adding a default method Comparator.reverseOrder() had an impact on the code in Collections. In he following code in Collections: private static class ReverseComparator implements Comparator>, Serializable { private static final long serialVersionUID = 7207038068494060240L; static final ReverseComparator REVERSE_ORDER = new ReverseComparator(); public int compare(Comparable c1, Comparable c2) { return c2.compareTo(c1); } private Object readResolve() { return reverseOrder(); } } ...the method readResolve() now calls default Comparator.reverseOrder(), but previously it called the static Collections.reverseOrder().... Regards, Peter On 02/10/2013 08:49 AM, Martin Buchholz wrote: > [adding lambda-dev] > > Here's another refinement to the test case, which shows that a serial clone > of Collections.reverseOrder in lambda8 creates a new instance of a new > class with the opposite order (which I can't explain): > > When run against latest lambda-b76, it gives this output: > > x=java.util.Collections$ReverseComparator at 3710b205 > y=java.util.Collections$ReverseComparator2 at e9b8b810 > x: 1 -1 > y: -1 1 > > import java.util.*; > import java.io.*; > > public class ReverseOrder { > public static void main(String[] args) throws Throwable { > Comparator x = Collections.reverseOrder(); > Comparator y = serialClone(x); > System.out.printf("x=%s%n", x); > System.out.printf("y=%s%n", y); > System.out.printf("x: %d %d%n", x.compare(0,1), x.compare(1,0)); > System.out.printf("y: %d %d%n", y.compare(0,1), y.compare(1,0)); > } > > static byte[] serialBytes(Object o) { > try { > ByteArrayOutputStream bos = new ByteArrayOutputStream(); > ObjectOutputStream oos = new ObjectOutputStream(bos); > oos.writeObject(o); > oos.flush(); > oos.close(); > return bos.toByteArray(); > } catch (Throwable t) { > throw new Error(t); > } > } > > @SuppressWarnings("unchecked") > static T serialClone(T o) { > try { > ObjectInputStream ois = new ObjectInputStream > (new ByteArrayInputStream(serialBytes(o))); > T clone = (T) ois.readObject(); > return clone; > } catch (Throwable t) { > throw new Error(t); > } > } > } > > > On Sat, Feb 9, 2013 at 3:31 PM, Martin Buchholz wrote: > >> On Sat, Feb 9, 2013 at 3:09 PM, Martin Buchholz wrote: >> >>> It looks to me like Collections.reverseOrder no longer deserializes to >>> the same object. It also looks like the definition for that in >>> Collections.java hasn't changed recently. So I suspect that there has been >>> some serious incompatible change to deserialization itself. >>> (It's another matter whether that could break TreeSet). >>> (I have long lobbied for more cross-jdk testing focused on seriallization) >>> >>> The program below demonstrates the different behavior between jdk7 and >>> jdk8: >>> >>> >> Oops - correction - this is not a difference between jdk7 and jdk8, but >> between jdk8 and lambda8, More specifically, lambda-8-b74 fails, >> while jdk8-b74 succeeds. Have lambdadukes messed with serialization? >> >> >> >>> import java.util.*; >>> import java.io.*; >>> >>> public class ReverseOrder { >>> public static void main(String[] args) throws Throwable { >>> Comparator c = Collections.reverseOrder(); >>> if (c != serialClone(c)) >>> throw new Error(String.format("c=%s clone=%s", >>> c, serialClone(c))); >>> } >>> >>> static byte[] serialBytes(Object o) { >>> try { >>> ByteArrayOutputStream bos = new ByteArrayOutputStream(); >>> ObjectOutputStream oos = new ObjectOutputStream(bos); >>> oos.writeObject(o); >>> oos.flush(); >>> oos.close(); >>> return bos.toByteArray(); >>> } catch (Throwable t) { >>> throw new Error(t); >>> } >>> } >>> >>> @SuppressWarnings("unchecked") >>> static T serialClone(T o) { >>> try { >>> ObjectInputStream ois = new ObjectInputStream >>> (new ByteArrayInputStream(serialBytes(o))); >>> T clone = (T) ois.readObject(); >>> return clone; >>> } catch (Throwable t) { >>> throw new Error(t); >>> } >>> } >>> } >>> >>> >>> On Fri, Feb 8, 2013 at 3:16 PM, Mike Duigou wrote: >>> >>>> Thank you for catching this Doug. I missed your original post on this >>>> topic during my Christmas vacation. ( >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-December/013127.htmlfor those following along at home) >>>> >>>> I will definitely hold off and follow up on the potentially bad patch to >>>> Java 8. I have created an issue to resolve the test breakage, JDK-8007889 >>>> >>>> Mike >>>> >>>> On Feb 8 2013, at 11:43 , Doug Lea wrote: >>>> >>>>> On 02/08/13 14:33, Mike Duigou wrote: >>>>>> Hello all; >>>>>> >>>>>> I would like to backport this change from Java 8. It has been baking >>>> in JDK8 for about two months with no problems. >>>>> I think it may have problems. >>>>> As I mentioned in a post a few months ago, it seems >>>>> to be responsible for breakage in a TCK/JCK test; >>>>> One derived from a jsr166 tck test at >>>>> >>>> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/TreeSubSetTest.java?view=log >>>>> You need the file for context, but it looks like: >>>>> >>>>> public void testDescendingSerialization() throws Exception { >>>>> NavigableSet x = dset5(); >>>>> NavigableSet y = serialClone(x); >>>>> >>>>> assertTrue(x != y); >>>>> assertEquals(x.size(), y.size()); >>>>> assertEquals(x.toString(), y.toString()); >>>>> assertEquals(x, y); >>>>> assertEquals(y, x); >>>>> while (!x.isEmpty()) { >>>>> assertFalse(y.isEmpty()); >>>>> assertEquals(x.pollFirst(), y.pollFirst()); >>>>> } >>>>> assertTrue(y.isEmpty()); >>>>> } >>>>> >>>>> >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7175464 >>>>>> >>>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/bf6ceb6b8f80 >>>>>> >>>>>> The change was previously reviewed by Alan Bateman, Paul Sandoz and >>>> David Holmes before going in to Java 8. >>>>>> Mike >>>>>> From Alan.Bateman at oracle.com Sun Feb 10 10:54:38 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 10 Feb 2013 10:54:38 +0000 Subject: [7u-dev] Request for approval for JDK-7175464 - entrySetView field is never updated in NavigableSubMap In-Reply-To: References: <718E9936-939D-4D0F-941F-6B8696772F4F@oracle.com> <51155565.9070800@cs.oswego.edu> Message-ID: <51177C6E.1060203@oracle.com> On 09/02/2013 23:31, Martin Buchholz wrote: > On Sat, Feb 9, 2013 at 3:09 PM, Martin Buchholz wrote: > >> It looks to me like Collections.reverseOrder no longer deserializes to the >> same object. It also looks like the definition for that in >> Collections.java hasn't changed recently. So I suspect that there has been >> some serious incompatible change to deserialization itself. >> (It's another matter whether that could break TreeSet). >> (I have long lobbied for more cross-jdk testing focused on seriallization) >> >> The program below demonstrates the different behavior between jdk7 and >> jdk8: >> >> > Oops - correction - this is not a difference between jdk7 and jdk8, but > between jdk8 and lambda8, More specifically, lambda-8-b74 fails, > while jdk8-b74 succeeds. Have lambdadukes messed with serialization? > Collections.ReverseComparator's readResolve is: private Object readResolve() { return reverseOrder(); } so I assume it's the new Comparator.reverseOrder() that is used now rather than Collections.reverseOrder() as before. Ha, this means it's returning a compator to reverse itself. This one aside, this is another issue with serialization that has come about because of default methods and because declared methods are used in the computation of the default serial version UID. Mike and Stuart are looking into that one (I think it came up on the lambda-dev list recently). -Alan From Alan.Bateman at oracle.com Sun Feb 10 10:55:06 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 10 Feb 2013 10:55:06 +0000 Subject: RFR: JDK-8007883: Re-enable pack200 tests for jprt testing on fast systems In-Reply-To: <511690C5.9000009@oracle.com> References: <511690C5.9000009@oracle.com> Message-ID: <51177C8A.7080409@oracle.com> On 09/02/2013 18:09, Kumar Srinivasan wrote: > Hi, > > Please review the following patch to reinstate pack200 tests for the > fastest > systems. > > In my testing I also found that launcher's I18NJarTest was failing > with a known > issue on Macs, so I have taken the opportunity to add this as well. The change looks okay to me, although for the pack200 tests then I assume the issue is really just old sparc machines that refuse to die and so continue to be used for testing. In that case, then maybe the exclude should be just for solaris-sparc and solaris-sparcv9. I guess you've probably thought about that already and that once the tests are running on at least one of two platforms it means you get the test coverage that it needed here. -Alan. From kumar.x.srinivasan at oracle.com Sun Feb 10 16:03:18 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Sun, 10 Feb 2013 08:03:18 -0800 Subject: RFR: JDK-8007883: Re-enable pack200 tests for jprt testing on fast systems In-Reply-To: <51177C8A.7080409@oracle.com> References: <511690C5.9000009@oracle.com> <51177C8A.7080409@oracle.com> Message-ID: <5117C4C6.3000602@oracle.com> On 2/10/2013 2:55 AM, Alan Bateman wrote: > On 09/02/2013 18:09, Kumar Srinivasan wrote: >> Hi, >> >> Please review the following patch to reinstate pack200 tests for the >> fastest >> systems. >> >> In my testing I also found that launcher's I18NJarTest was failing >> with a known >> issue on Macs, so I have taken the opportunity to add this as well. > The change looks okay to me, although for the pack200 tests then I > assume the issue is really just old sparc machines that refuse to die > and so continue to be used for testing. In that case, then maybe the > exclude should be just for solaris-sparc and solaris-sparcv9. I guess > you've probably thought about that already and that once the tests are > running on at least one of two platforms it means you get the test > coverage that it needed here. Thanks Alan for looking at this. Right, for a sanity check , one platform should suffice. I went for the bonus point and added windows (32/64) as well, to err on the side of safety. Kumar > > -Alan. From kumar.x.srinivasan at oracle.com Sun Feb 10 16:12:34 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Sun, 10 Feb 2013 16:12:34 +0000 Subject: hg: jdk8/tl/jdk: 8007519: [unpack200] produces bad class files when producing BootstrapMethods attribute Message-ID: <20130210161315.5094947989@hg.openjdk.java.net> Changeset: 58c95d0b6b1a Author: ksrini Date: 2013-02-10 08:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/58c95d0b6b1a 8007519: [unpack200] produces bad class files when producing BootstrapMethods attribute Reviewed-by: alanb ! test/ProblemList.txt From kumar.x.srinivasan at oracle.com Sun Feb 10 16:19:52 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Sun, 10 Feb 2013 08:19:52 -0800 Subject: RFR: JDK-8007883: Re-enable pack200 tests for jprt testing on fast systems In-Reply-To: <5117C4C6.3000602@oracle.com> References: <511690C5.9000009@oracle.com> <51177C8A.7080409@oracle.com> <5117C4C6.3000602@oracle.com> Message-ID: <5117C8A8.20406@oracle.com> Drat, I made a mistake, sorry!, I used the wrong JBS id for this push, to keep it simple and avoid confusion I will swap the jbs ids, and add some comments in jbs as well. Kumar > On 2/10/2013 2:55 AM, Alan Bateman wrote: >> On 09/02/2013 18:09, Kumar Srinivasan wrote: >>> Hi, >>> >>> Please review the following patch to reinstate pack200 tests for the >>> fastest >>> systems. >>> >>> In my testing I also found that launcher's I18NJarTest was failing >>> with a known >>> issue on Macs, so I have taken the opportunity to add this as well. >> The change looks okay to me, although for the pack200 tests then I >> assume the issue is really just old sparc machines that refuse to die >> and so continue to be used for testing. In that case, then maybe the >> exclude should be just for solaris-sparc and solaris-sparcv9. I guess >> you've probably thought about that already and that once the tests >> are running on at least one of two platforms it means you get the >> test coverage that it needed here. > > Thanks Alan for looking at this. > > Right, for a sanity check , one platform should suffice. I went for > the bonus point and > added windows (32/64) as well, to err on the side of safety. > > Kumar > >> >> -Alan. > From kumar.x.srinivasan at oracle.com Sun Feb 10 17:02:01 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Sun, 10 Feb 2013 17:02:01 +0000 Subject: hg: jdk8/tl/jdk: 8007902: [unpack200] incorrect BootstrapMethods attribute Message-ID: <20130210170212.F0A6B4798A@hg.openjdk.java.net> Changeset: 520a3433883d Author: ksrini Date: 2013-02-10 08:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/520a3433883d 8007902: [unpack200] incorrect BootstrapMethods attribute Reviewed-by: jjh ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! test/tools/pack200/Pack200Test.java ! test/tools/pack200/pack200-verifier/data/golden.jar From martinrb at google.com Mon Feb 11 03:52:13 2013 From: martinrb at google.com (Martin Buchholz) Date: Sun, 10 Feb 2013 19:52:13 -0800 Subject: [7u-dev] Request for approval for JDK-7175464 - entrySetView field is never updated in NavigableSubMap In-Reply-To: <51177C6E.1060203@oracle.com> References: <718E9936-939D-4D0F-941F-6B8696772F4F@oracle.com> <51155565.9070800@cs.oswego.edu> <51177C6E.1060203@oracle.com> Message-ID: Alright, now that the problem (if not the solution) is well understood, I leave it to you. Martin On Sun, Feb 10, 2013 at 2:54 AM, Alan Bateman wrote: > On 09/02/2013 23:31, Martin Buchholz wrote: > >> On Sat, Feb 9, 2013 at 3:09 PM, Martin Buchholz >> wrote: >> >> It looks to me like Collections.reverseOrder no longer deserializes to >>> the >>> same object. It also looks like the definition for that in >>> Collections.java hasn't changed recently. So I suspect that there has >>> been >>> some serious incompatible change to deserialization itself. >>> (It's another matter whether that could break TreeSet). >>> (I have long lobbied for more cross-jdk testing focused on >>> seriallization) >>> >>> The program below demonstrates the different behavior between jdk7 and >>> jdk8: >>> >>> >>> Oops - correction - this is not a difference between jdk7 and jdk8, but >> between jdk8 and lambda8, More specifically, lambda-8-b74 fails, >> while jdk8-b74 succeeds. Have lambdadukes messed with serialization? >> >> Collections.ReverseComparator'**s readResolve is: > > > private Object readResolve() { return reverseOrder(); } > > so I assume it's the new Comparator.reverseOrder() that is used now rather > than Collections.reverseOrder() as before. Ha, this means it's returning a > compator to reverse itself. > > This one aside, this is another issue with serialization that has come > about because of default methods and because declared methods are used in > the computation of the default serial version UID. Mike and Stuart are > looking into that one (I think it came up on the lambda-dev list recently). > > -Alan > > > > From martinrb at google.com Mon Feb 11 03:59:52 2013 From: martinrb at google.com (Martin Buchholz) Date: Sun, 10 Feb 2013 19:59:52 -0800 Subject: zip64 compatibility problems In-Reply-To: <51161BD6.3040608@gmail.com> References: <50F6010D.5000806@oracle.com> <5100C3D2.6040604@oracle.com> <5113D311.7060006@oracle.com> <51161BD6.3040608@gmail.com> Message-ID: 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 mike.duigou at oracle.com Mon Feb 11 05:03:31 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Sun, 10 Feb 2013 21:03:31 -0800 Subject: [7u-dev] Request for approval for JDK-7175464 - entrySetView field is never updated in NavigableSubMap In-Reply-To: References: <718E9936-939D-4D0F-941F-6B8696772F4F@oracle.com> <51155565.9070800@cs.oswego.edu> <51177C6E.1060203@oracle.com> Message-ID: Thank you Doug, Martin, Peter and Alan for efforts your in tracking this down. Even though it's not implicated, I am going to hold off on the OpenJDK7u-dev push of 7175464 for a few days to allow for some additional testing. Mike On Feb 10 2013, at 19:52 , Martin Buchholz wrote: > Alright, now that the problem (if not the solution) is well understood, I leave it to you. > > Martin > > On Sun, Feb 10, 2013 at 2:54 AM, Alan Bateman wrote: > On 09/02/2013 23:31, Martin Buchholz wrote: > On Sat, Feb 9, 2013 at 3:09 PM, Martin Buchholz wrote: > > It looks to me like Collections.reverseOrder no longer deserializes to the > same object. It also looks like the definition for that in > Collections.java hasn't changed recently. So I suspect that there has been > some serious incompatible change to deserialization itself. > (It's another matter whether that could break TreeSet). > (I have long lobbied for more cross-jdk testing focused on seriallization) > > The program below demonstrates the different behavior between jdk7 and > jdk8: > > > Oops - correction - this is not a difference between jdk7 and jdk8, but > between jdk8 and lambda8, More specifically, lambda-8-b74 fails, > while jdk8-b74 succeeds. Have lambdadukes messed with serialization? > > Collections.ReverseComparator's readResolve is: > > > private Object readResolve() { return reverseOrder(); } > > so I assume it's the new Comparator.reverseOrder() that is used now rather than Collections.reverseOrder() as before. Ha, this means it's returning a compator to reverse itself. > > This one aside, this is another issue with serialization that has come about because of default methods and because declared methods are used in the computation of the default serial version UID. Mike and Stuart are looking into that one (I think it came up on the lambda-dev list recently). > > -Alan > > > > From xueming.shen at oracle.com Mon Feb 11 06:30:00 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Sun, 10 Feb 2013 22:30:00 -0800 Subject: zip64 compatibility problems In-Reply-To: References: <50F6010D.5000806@oracle.com> <5100C3D2.6040604@oracle.com> <5113D311.7060006@oracle.com> <51161BD6.3040608@gmail.com> Message-ID: <51188FE8.40604@oracle.com> 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 me at hildeberto.com Mon Feb 11 11:54:35 2013 From: me at hildeberto.com (=?ISO-8859-1?Q?Hildeberto_Mendon=E7a?=) Date: Mon, 11 Feb 2013 12:54:35 +0100 Subject: Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer Message-ID: Hello, we have a scenario where a project with approximately 500K lines of code is going through a large refactoring. One of the changes was to replace string concatenations in loops by StringBuilder. Within the logic we found the following condition: for(...) { if(str.isEmpty()) { // do something } } After using StringBuilder,we had to change it to: for(...) { if(str.length() == 0) { // do something } } ... which is a less readable code than the previous code. Having shown that, we would like to know if there was a previous discution on the inclusion or not of a method isEmpty in the StringBuilder. if yes, why it is not there, if no, can we actually have it on Java8 or in a near future? We can actually find other similar String-like methods within StringBuilder, such as charAt, replace and others. We would like to know if it is worthwhile to be discussed and taken forward. Best regards, -- Hildeberto Mendon?a, Ph.D Blog: http://www.hildeberto.com Twitter: https://twitter.com/htmfilho From peter.levart at gmail.com Mon Feb 11 12:20:05 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 11 Feb 2013 13:20:05 +0100 Subject: Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer In-Reply-To: References: Message-ID: <5118E1F5.6040600@gmail.com> This could be a default method in CharSequence.... Regards, Peter On 02/11/2013 12:54 PM, Hildeberto Mendon?a wrote: > Hello, > > we have a scenario where a project with approximately 500K lines of code is > going through a large refactoring. One of the changes was to replace string > concatenations in loops by StringBuilder. Within the logic we found the > following condition: > > for(...) { > if(str.isEmpty()) { > // do something > } > } > > After using StringBuilder,we had to change it to: > > for(...) { > if(str.length() == 0) { > // do something > } > } > > ... which is a less readable code than the previous code. Having shown > that, we would like to know if there was a previous discution on the > inclusion or not of a method isEmpty in the StringBuilder. if yes, why it > is not there, if no, can we actually have it on Java8 or in a near future? > > We can actually find other similar String-like methods within > StringBuilder, such as charAt, replace and others. > > We would like to know if it is worthwhile to be discussed and taken forward. > > Best regards, > From me at hildeberto.com Mon Feb 11 13:02:59 2013 From: me at hildeberto.com (=?ISO-8859-1?Q?Hildeberto_Mendon=E7a?=) Date: Mon, 11 Feb 2013 14:02:59 +0100 Subject: Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer In-Reply-To: <5118E1F5.6040600@gmail.com> References: <5118E1F5.6040600@gmail.com> Message-ID: Yes. That's definitively a good approach. I think there are many other opportunities to improve StringBuilder and other subclasses of CharSequence, but this isEmpty() method is a very important one. A lot of developers might be constantly doing this kind of refactoring and it may reduce the effort to do so. It also keeps the elegance up all the time, instead of downgrading it a little bit by a length() invocation (replacing an unary check by a binary operator check). It might be a case where a small change in the core libs design doesn't cause any impact (backwards compatible) and may call attention of lots of developers to move complex concatenation scenarios to StringBuilder/StringBuffer without any loss. On Mon, Feb 11, 2013 at 1:20 PM, Peter Levart wrote: > This could be a default method in CharSequence.... > > Regards, Peter > > > On 02/11/2013 12:54 PM, Hildeberto Mendon?a wrote: > >> Hello, >> >> we have a scenario where a project with approximately 500K lines of code >> is >> going through a large refactoring. One of the changes was to replace >> string >> concatenations in loops by StringBuilder. Within the logic we found the >> following condition: >> >> for(...) { >> if(str.isEmpty()) { >> // do something >> } >> } >> >> After using StringBuilder,we had to change it to: >> >> for(...) { >> if(str.length() == 0) { >> // do something >> } >> } >> >> ... which is a less readable code than the previous code. Having shown >> that, we would like to know if there was a previous discution on the >> inclusion or not of a method isEmpty in the StringBuilder. if yes, why it >> is not there, if no, can we actually have it on Java8 or in a near future? >> >> We can actually find other similar String-like methods within >> StringBuilder, such as charAt, replace and others. >> >> We would like to know if it is worthwhile to be discussed and taken >> forward. >> >> Best regards, >> >> > -- Hildeberto Mendon?a, Ph.D Blog: http://www.hildeberto.com Twitter: https://twitter.com/htmfilho From Ulf.Zibis at CoSoCo.de Mon Feb 11 14:29:45 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Mon, 11 Feb 2013 15:29:45 +0100 Subject: Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer In-Reply-To: References: Message-ID: <51190059.4000505@CoSoCo.de> Am 11.02.2013 12:54, schrieb Hildeberto Mendon?a: > Hello, > > we have a scenario where a project with approximately 500K lines of code is > going through a large refactoring. One of the changes was to replace string > concatenations in loops by StringBuilder. Are you aware, that behind the scenes, String concatenations are automatically internally replaced from javac by StringBuilder invocations, so in the end you might have less readable code, which is still not faster than before. > Having shown that, we would like to know if there was a previous discution > on the inclusion or not of a method isEmpty in the StringBuilder. +1 anyway -Ulf From vitalyd at gmail.com Mon Feb 11 14:34:09 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 11 Feb 2013 09:34:09 -0500 Subject: Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer In-Reply-To: <51190059.4000505@CoSoCo.de> References: <51190059.4000505@CoSoCo.de> Message-ID: It won't replace them in loops or at least not entirely (may get intermediate builders for each iteration). I also agree on the isEmpty() point. Sent from my phone On Feb 11, 2013 9:30 AM, "Ulf Zibis" wrote: > Am 11.02.2013 12:54, schrieb Hildeberto Mendon?a: > >> Hello, >> >> we have a scenario where a project with approximately 500K lines of code >> is >> going through a large refactoring. One of the changes was to replace >> string >> concatenations in loops by StringBuilder. >> > > Are you aware, that behind the scenes, String concatenations are > automatically internally replaced from javac by StringBuilder invocations, > so in the end you might have less readable code, which is still not faster > than before. > > Having shown that, we would like to know if there was a previous discution >> on the inclusion or not of a method isEmpty in the StringBuilder. >> > > +1 anyway > > -Ulf > > From dmitry.samersoff at oracle.com Mon Feb 11 14:49:43 2013 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Mon, 11 Feb 2013 14:49:43 +0000 Subject: hg: jdk8/tl/jdk: 8007536: Incorrect copyright header in JDP files Message-ID: <20130211145005.0B2B4479A4@hg.openjdk.java.net> Changeset: 1df991184045 Author: dsamersoff Date: 2013-02-11 18:44 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1df991184045 8007536: Incorrect copyright header in JDP files Summary: Copyright header in JDP files missed the "classpath exception" rule. Reviewed-by: mikael ! src/share/classes/sun/management/jdp/JdpBroadcaster.java ! src/share/classes/sun/management/jdp/JdpController.java ! src/share/classes/sun/management/jdp/JdpException.java ! src/share/classes/sun/management/jdp/JdpGenericPacket.java ! src/share/classes/sun/management/jdp/JdpJmxPacket.java ! src/share/classes/sun/management/jdp/JdpPacket.java ! src/share/classes/sun/management/jdp/JdpPacketReader.java ! src/share/classes/sun/management/jdp/JdpPacketWriter.java ! src/share/classes/sun/management/jdp/package-info.java From Alan.Bateman at oracle.com Mon Feb 11 14:53:54 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 Feb 2013 14:53:54 +0000 Subject: zip64 compatibility problems In-Reply-To: References: <50F6010D.5000806@oracle.com> <5100C3D2.6040604@oracle.com> <5113D311.7060006@oracle.com> <51161BD6.3040608@gmail.com> Message-ID: <51190602.2090406@oracle.com> On 11/02/2013 03:59, 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. The test looks fine, looks like it won't be too slow. One improvement would be to use try-with-resources. -Alan. From me at hildeberto.com Mon Feb 11 15:39:00 2013 From: me at hildeberto.com (=?ISO-8859-1?Q?Hildeberto_Mendon=E7a?=) Date: Mon, 11 Feb 2013 16:39:00 +0100 Subject: Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer In-Reply-To: <51190059.4000505@CoSoCo.de> References: <51190059.4000505@CoSoCo.de> Message-ID: On Mon, Feb 11, 2013 at 3:29 PM, Ulf Zibis wrote: > Am 11.02.2013 12:54, schrieb Hildeberto Mendon?a: > > we have a scenario where a project with approximately 500K lines of code is >> going through a large refactoring. One of the changes was to replace >> string >> concatenations in loops by StringBuilder. >> > > Are you aware, that behind the scenes, String concatenations are > automatically internally replaced from javac by StringBuilder invocations, > so in the end you might have less readable code, which is still not faster > than before. Yes, I am. On my understanding the compiler can handle that with concatenations like this: str += "text" + "another" + str2; but I'm not sure it happens when concatenations are more complex, such as the hypothetical example below: if(str.isEmpty()) { str = "best cars: "; boolean firstCar = true; for(Car car: cars) { if(firstCar) { firstCar = false; } else { str += ", "; } str += car.getName(); if(car.getBrand() != null) { str += " - " + car.getBrand(); } } str += "."; } I believe, in each iteration, the String is converted to a StringBuilder, appended to, and converted back to a String. Thanks for the feedback. -- Hildeberto Mendon?a, Ph.D Blog: http://www.hildeberto.com Twitter: https://twitter.com/htmfilho From pbenedict at apache.org Mon Feb 11 17:03:04 2013 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 11 Feb 2013 11:03:04 -0600 Subject: Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer Message-ID: Do you want isEmpty() for bean access, or empty() like Collections? Since there isn't a getLength() but just length() (and size() for collections), I think the latter would be preferred. Paul From vitalyd at gmail.com Mon Feb 11 17:08:01 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 11 Feb 2013 12:08:01 -0500 Subject: Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer In-Reply-To: References: Message-ID: It should be isEmpty() -- empty() is usually for returning empty versions of the class. isEmpty is also consistent with String. Sent from my phone On Feb 11, 2013 12:03 PM, "Paul Benedict" wrote: > Do you want isEmpty() for bean access, or empty() like Collections? Since > there isn't a getLength() but just length() (and size() for collections), I > think the latter would be preferred. > > Paul > From martinrb at google.com Mon Feb 11 18:03:51 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 11 Feb 2013 10:03:51 -0800 Subject: zip64 compatibility problems In-Reply-To: <51190602.2090406@oracle.com> References: <50F6010D.5000806@oracle.com> <5100C3D2.6040604@oracle.com> <5113D311.7060006@oracle.com> <51161BD6.3040608@gmail.com> <51190602.2090406@oracle.com> Message-ID: On Mon, Feb 11, 2013 at 6:53 AM, Alan Bateman wrote: > One improvement would be to use try-with-resources. > I did that, despite the loss of portability. Portable java programs might be able to start using these new-fangled features starting around 2020. From zhengyu.gu at oracle.com Mon Feb 11 18:05:16 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Mon, 11 Feb 2013 13:05:16 -0500 Subject: Code review request: 8006691: Remove jvm_version_info.is_kernel_jvm field Message-ID: <511932DC.2060401@oracle.com> Kernel VM has been deprecated since JDK7 and related JVM code has also been removed recently. This change is to remove is_kernel_jvm flag from jvm_version_info structure in jvm.h on JDK side. Bug: http://bugs.sun.com/view_bug.do?bug_id=8006691 CCC: http://ccc.us.oracle.com/8006691 JDK7: http://cr.openjdk.java.net/~zgu/8006691/jdk7/webrev.00/ JDK8: http://cr.openjdk.java.net/~zgu/8006691/jdk8/webrev.00/ Thanks, -Zhengyu From daniel.daugherty at oracle.com Mon Feb 11 18:09:01 2013 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Mon, 11 Feb 2013 18:09:01 +0000 Subject: hg: jdk8/tl/jdk: 8007420: add test for 6805864 to com/sun/jdi, add test for 7182152 to java/lang/instrument Message-ID: <20130211180922.66431479AA@hg.openjdk.java.net> Changeset: abd530253f01 Author: dcubed Date: 2013-02-11 10:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/abd530253f01 8007420: add test for 6805864 to com/sun/jdi, add test for 7182152 to java/lang/instrument Reviewed-by: coleenp, sspitsyn + test/com/sun/jdi/RedefineAbstractClass.sh + test/java/lang/instrument/RedefineSubclassWithTwoInterfaces.sh + test/java/lang/instrument/RedefineSubclassWithTwoInterfacesAgent.java + test/java/lang/instrument/RedefineSubclassWithTwoInterfacesApp.java + test/java/lang/instrument/RedefineSubclassWithTwoInterfacesImpl.java + test/java/lang/instrument/RedefineSubclassWithTwoInterfacesImpl_1.java + test/java/lang/instrument/RedefineSubclassWithTwoInterfacesIntf1.java + test/java/lang/instrument/RedefineSubclassWithTwoInterfacesIntf2.java + test/java/lang/instrument/RedefineSubclassWithTwoInterfacesRemote.java + test/java/lang/instrument/RedefineSubclassWithTwoInterfacesTarget.java + test/java/lang/instrument/RedefineSubclassWithTwoInterfacesTarget_1.java From jeremymanson at google.com Mon Feb 11 18:26:07 2013 From: jeremymanson at google.com (Jeremy Manson) Date: Mon, 11 Feb 2013 10:26:07 -0800 Subject: Define JNIEXPORT as visibility default with GCC? Message-ID: Hi folks, Pardon if this has come up before; a quick search didn't indicate anything, but the mailing list archives are kind of hard to search. I wonder if it makes sense to define JNIEXPORT as meaning __attribute__ ((visibility ("default"))) when compiling with gcc. Currently, anyone building JNI code with -fvisibility=hidden and a stock Oracle JDK is at a loss: their JNI exports will be hidden along with everything else. I notice that both IcedTea and OS X have made this change independently, and it has been added to Hotspot's JNIEXPORT definition (so HS can be built with -fvisibility=hidden), but the change isn't present in the latest JDK8 bits: http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/933742f4bb4c/src/solaris/javavm/export/jni_md.h The workaround is pretty ugly: people who want to use -fvisibility=hidden have to redefine JNIEXPORT. Upstream, it would be a pretty simple change to jni_md.h, along the lines of: #if defined(__GNUC__) && __GNUC__ >= 4 #define JNIEXPORT __attribute__ ((visibility ("default"))) #else #define JNIEXPORT #endif Any thoughts? Jeremy From me at hildeberto.com Mon Feb 11 18:32:58 2013 From: me at hildeberto.com (=?ISO-8859-1?Q?Hildeberto_Mendon=E7a?=) Date: Mon, 11 Feb 2013 19:32:58 +0100 Subject: Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer In-Reply-To: References: Message-ID: On Mon, Feb 11, 2013 at 6:08 PM, Vitaly Davidovich wrote: > It should be isEmpty() -- empty() is usually for returning empty versions > of the class. isEmpty is also consistent with String. > Yes. Also, being consistent with String helps to reduce effort during refactoring. -- Hildeberto Mendon?a, Ph.D Blog: http://www.hildeberto.com Twitter: https://twitter.com/htmfilho From mandy.chung at oracle.com Mon Feb 11 18:30:48 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 11 Feb 2013 10:30:48 -0800 Subject: Code review request: 8006691: Remove jvm_version_info.is_kernel_jvm field In-Reply-To: <511932DC.2060401@oracle.com> References: <511932DC.2060401@oracle.com> Message-ID: <511938D8.6050502@oracle.com> Hi ZhengYu, Looks good to me. I will sponsor this change and push it to JDK8. To backport to jdk7u, you will need to get an approval and please follow the processes [1]. You have filed a CCC request for this change - FWIW this is private implementation-specific and no CCC is needed for this. Mandy [1] http://openjdk.java.net/projects/jdk7u/ On 2/11/13 10:05 AM, Zhengyu Gu wrote: > Kernel VM has been deprecated since JDK7 and related JVM code has also > been removed recently. This change is to remove is_kernel_jvm flag > from jvm_version_info structure in jvm.h on JDK side. > > > Bug: > http://bugs.sun.com/view_bug.do?bug_id=8006691 > > CCC: > http://ccc.us.oracle.com/8006691 > > JDK7: > http://cr.openjdk.java.net/~zgu/8006691/jdk7/webrev.00/ > > JDK8: > http://cr.openjdk.java.net/~zgu/8006691/jdk8/webrev.00/ > > Thanks, > > -Zhengyu From me at hildeberto.com Mon Feb 11 19:12:56 2013 From: me at hildeberto.com (=?ISO-8859-1?Q?Hildeberto_Mendon=E7a?=) Date: Mon, 11 Feb 2013 20:12:56 +0100 Subject: Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer In-Reply-To: References: Message-ID: Is there something we can do to push it forward? Maybe a patch, tests, text, or something else? On Mon, Feb 11, 2013 at 7:32 PM, Hildeberto Mendon?a wrote: > On Mon, Feb 11, 2013 at 6:08 PM, Vitaly Davidovich wrote: > >> It should be isEmpty() -- empty() is usually for returning empty versions >> of the class. isEmpty is also consistent with String. >> > > Yes. Also, being consistent with String helps to reduce effort during > refactoring. > > -- > Hildeberto Mendon?a, Ph.D > Blog: http://www.hildeberto.com > Twitter: https://twitter.com/htmfilho -- Hildeberto Mendon?a, Ph.D Blog: http://www.hildeberto.com Twitter: https://twitter.com/htmfilho From Ulf.Zibis at CoSoCo.de Mon Feb 11 20:08:04 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Mon, 11 Feb 2013 21:08:04 +0100 Subject: Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer In-Reply-To: References: <51190059.4000505@CoSoCo.de> Message-ID: <51194FA4.3010804@CoSoCo.de> Am 11.02.2013 16:39, schrieb Hildeberto Mendon?a: > On Mon, Feb 11, 2013 at 3:29 PM, Ulf Zibis > wrote: > > Am 11.02.2013 12:54, schrieb Hildeberto Mendon?a: > > we have a scenario where a project with approximately 500K lines of code is > going through a large refactoring. One of the changes was to replace string > concatenations in loops by StringBuilder. > > > Are you aware, that behind the scenes, String concatenations are automatically internally > replaced from javac by StringBuilder invocations, so in the end you might have less readable > code, which is still not faster than before. > > > Yes, I am. On my understanding the compiler can handle that with concatenations like this: > > str += "text" + "another" + str2; > > but I'm not sure it happens when concatenations are more complex, such as the hypothetical example > below: > > if(str.isEmpty()) { > str = "best cars: "; > boolean firstCar = true; > for(Car car: cars) { > if(firstCar) { > firstCar = false; > } > else { > str += ", "; > } > str += car.getName(); > > if(car.getBrand() != null) { > str += " - " + car.getBrand(); > } > } > str += "."; > } > > I believe, in each iteration, the String is converted to a StringBuilder, appended to, and > converted back to a String. Hi Hildeberto, maybe your believe is correct. You could have a look in the byte code by javap. And additionally you could run a benchmark for both alternatives and compare, if HotSpot compiler would be able to optimize both with same result. I would like to know the result :-) -Ulf From mandy.chung at oracle.com Mon Feb 11 20:04:22 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 11 Feb 2013 12:04:22 -0800 Subject: Code review request: 8006691: Remove jvm_version_info.is_kernel_jvm field In-Reply-To: <511938D8.6050502@oracle.com> References: <511932DC.2060401@oracle.com> <511938D8.6050502@oracle.com> Message-ID: <51194EC6.8000007@oracle.com> ZhengYu - Just realize that you are a committer [1]. You can push the fix to TL yourself. Mandy [1] http://openjdk.java.net/census#zgu On 2/11/13 10:30 AM, Mandy Chung wrote: > Hi ZhengYu, > > Looks good to me. I will sponsor this change and push it to JDK8. > > To backport to jdk7u, you will need to get an approval and please > follow the processes [1]. You have filed a CCC request for this > change - FWIW this is private implementation-specific and no CCC is > needed for this. > > Mandy > [1] http://openjdk.java.net/projects/jdk7u/ > > On 2/11/13 10:05 AM, Zhengyu Gu wrote: >> Kernel VM has been deprecated since JDK7 and related JVM code has >> also been removed recently. This change is to remove is_kernel_jvm >> flag from jvm_version_info structure in jvm.h on JDK side. >> >> >> Bug: >> http://bugs.sun.com/view_bug.do?bug_id=8006691 >> >> CCC: >> http://ccc.us.oracle.com/8006691 >> >> JDK7: >> http://cr.openjdk.java.net/~zgu/8006691/jdk7/webrev.00/ >> >> JDK8: >> http://cr.openjdk.java.net/~zgu/8006691/jdk8/webrev.00/ >> >> Thanks, >> >> -Zhengyu > From alan.bateman at oracle.com Mon Feb 11 20:20:15 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 11 Feb 2013 20:20:15 +0000 Subject: hg: jdk8/tl/jdk: 8007405: Update java.lang.reflect API to replace SYNTHESIZED with MANDATED Message-ID: <20130211202037.63AC7479B1@hg.openjdk.java.net> Changeset: f21a4b761424 Author: alanb Date: 2013-02-11 20:16 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f21a4b761424 8007405: Update java.lang.reflect API to replace SYNTHESIZED with MANDATED Reviewed-by: darcy ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Modifier.java ! src/share/classes/java/lang/reflect/Parameter.java From Alan.Bateman at oracle.com Mon Feb 11 20:27:19 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 Feb 2013 20:27:19 +0000 Subject: hg: jdk8/tl/jdk: 8007405: Update java.lang.reflect API to replace SYNTHESIZED with MANDATED In-Reply-To: <20130211202037.63AC7479B1@hg.openjdk.java.net> References: <20130211202037.63AC7479B1@hg.openjdk.java.net> Message-ID: <51195427.4040609@oracle.com> Drat! The change-set author should be "emc" (Eric McCorkle), not me. I was only pushing Eric's patch as he's not a jdk8 committer at this time. On 11/02/2013 20:20, alan.bateman at oracle.com wrote: > Changeset: f21a4b761424 > Author: alanb > Date: 2013-02-11 20:16 +0000 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f21a4b761424 > > 8007405: Update java.lang.reflect API to replace SYNTHESIZED with MANDATED > Reviewed-by: darcy > > ! src/share/classes/java/lang/reflect/Executable.java > ! src/share/classes/java/lang/reflect/Modifier.java > ! src/share/classes/java/lang/reflect/Parameter.java > From Dmitry.Degrave at oracle.com Mon Feb 11 20:58:14 2013 From: Dmitry.Degrave at oracle.com (Dmeetry Degrave) Date: Tue, 12 Feb 2013 00:58:14 +0400 Subject: RFR: 7199858: Marshal exception is wrong Message-ID: <51195B66.90601@oracle.com> Hi, Resending a code review request for a corba fix for 7 and 8, which is identical to fix went to earlier releases. A wrong unexpectedUnionDefault exception is thrown in TypeCode handling code when an OptUnion value with false discriminator is inserted into any of NV struct on server side for the following idl: union OptUnion switch (boolean) { case TRUE: unsigned short opt; }; struct NV { string name; any value; }; typedef sequence NVSeq; interface OptUnionInterface { OptUnion retrieve (); NVSeq retrieveNVSeq(); }; The fix is elimination of the exception, as it's wrong. There is a test case attached to the bug, though it requires a CORBA env setup. webrev : http://cr.openjdk.java.net/~dmeetry/7199858/webrev.0/ jdk7 bug w/ desc: http://bugs.sun.com/view_bug.do?bug_id=7199858 jdk8 bug w/ comm: http://bugs.sun.com/view_bug.do?bug_id=8005310 Fix was reviewed by Mark Sheppard and verified in the field. thanks, dmeetry From joe.darcy at oracle.com Mon Feb 11 21:37:55 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 11 Feb 2013 21:37:55 +0000 Subject: hg: jdk8/tl/langtools: 8007574: Provide isFunctionalInterface in javax.lang.model Message-ID: <20130211213800.20C09479B7@hg.openjdk.java.net> Changeset: 01af1b5c631d Author: darcy Date: 2013-02-11 13:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/01af1b5c631d 8007574: Provide isFunctionalInterface in javax.lang.model Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/javax/lang/model/element/TypeElement.java ! src/share/classes/javax/lang/model/util/Elements.java + test/tools/javac/processing/model/util/elements/TestIsFunctionalInterface.java From Lance.Andersen at oracle.com Mon Feb 11 22:52:00 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Mon, 11 Feb 2013 17:52:00 -0500 Subject: RFR: 7199858: Marshal exception is wrong In-Reply-To: <51195B66.90601@oracle.com> References: <51195B66.90601@oracle.com> Message-ID: <32BEF112-F4CE-4CCD-9EA5-CF156E92BC85@oracle.com> Looks Ok Dmeetry. Best Lance On Feb 11, 2013, at 3:58 PM, Dmeetry Degrave wrote: > Hi, > > Resending a code review request for a corba fix for 7 and 8, which is identical to fix went to earlier releases. > > A wrong unexpectedUnionDefault exception is thrown in TypeCode handling code when an OptUnion value with false discriminator is inserted into any of NV struct on server side for the following idl: > > union OptUnion switch (boolean) { > case TRUE: > unsigned short opt; > }; > > struct NV { > string name; > any value; > }; > > typedef sequence NVSeq; > > interface OptUnionInterface > { > OptUnion retrieve (); > NVSeq retrieveNVSeq(); > }; > > The fix is elimination of the exception, as it's wrong. There is a test case attached to the bug, though it requires a CORBA env setup. > > webrev : http://cr.openjdk.java.net/~dmeetry/7199858/webrev.0/ > jdk7 bug w/ desc: http://bugs.sun.com/view_bug.do?bug_id=7199858 > jdk8 bug w/ comm: http://bugs.sun.com/view_bug.do?bug_id=8005310 > > Fix was reviewed by Mark Sheppard and verified in the field. > > thanks, > dmeetry -------------- 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 Ulf.Zibis at CoSoCo.de Tue Feb 12 00:21:12 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Tue, 12 Feb 2013 01:21:12 +0100 Subject: Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer In-Reply-To: References: <51190059.4000505@CoSoCo.de> <51194E7E.6080101@CoSoCo.de> Message-ID: <51198AF8.3010805@CoSoCo.de> Am 11.02.2013 22:26, schrieb Hildeberto Mendon?a: > Hello Ulf, > > On Mon, Feb 11, 2013 at 9:03 PM, Ulf Zibis > wrote: > > > Hi Hildeberto, > > maybe your believe is correct. > You could have a look in the byte code by javap. > > And additionally you could run a benchmark for both alternatives and compare, if HotSpot > compiler would be able to optimize both with same result. > > I would like to know the result :-) > > -Ulf > > > The issue is fairly documented in the book "Effective Java - Second Edition" by Joshua Bloch, pg. > 227: "Item 51: Beware the performance of string concatenation". It gives an example with a "for" > saying that "The difference in performance is dramatic." The method with StringBuilder "... is > eighty-five times faster than... " the one with String concatenation considering only 100 iterations. Hi again, I suspect, "Effective Java" was written some time before javac substituted string concatenation by StringBuilder calls, and before HotSpot optimizations were as performant as they are today. I'm still inquisitive about some micro-benchmark results. -Ulf From vitalyd at gmail.com Tue Feb 12 00:45:57 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 11 Feb 2013 19:45:57 -0500 Subject: Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer In-Reply-To: <51198AF8.3010805@CoSoCo.de> References: <51190059.4000505@CoSoCo.de> <51194E7E.6080101@CoSoCo.de> <51198AF8.3010805@CoSoCo.de> Message-ID: javac will not replace concat ops across loop iterations, it will replace whichever ones are inside one loop iteration. This will still create temporary StringBuilder instances. As for JIT optimizing further, it would have to fully unroll the loop to have a chance at eliminating this; I'd be really surprised if loops with nontrivial (and non compile time constant) trip counts get eliminated. I'd also not rely on JIT here and do the "right" thing manually :). You also may not have C2 compiler available or may not even be running on hotspot. Sent from my phone On Feb 11, 2013 7:21 PM, "Ulf Zibis" wrote: > Am 11.02.2013 22:26, schrieb Hildeberto Mendon?a: > >> Hello Ulf, >> >> On Mon, Feb 11, 2013 at 9:03 PM, Ulf Zibis > Ulf.Zibis at cosoco.de>> wrote: >> >> >> Hi Hildeberto, >> >> maybe your believe is correct. >> You could have a look in the byte code by javap. >> >> And additionally you could run a benchmark for both alternatives and >> compare, if HotSpot >> compiler would be able to optimize both with same result. >> >> I would like to know the result :-) >> >> -Ulf >> >> >> The issue is fairly documented in the book "Effective Java - Second >> Edition" by Joshua Bloch, pg. 227: "Item 51: Beware the performance of >> string concatenation". It gives an example with a "for" saying that "The >> difference in performance is dramatic." The method with StringBuilder "... >> is eighty-five times faster than... " the one with String concatenation >> considering only 100 iterations. >> > > Hi again, > > I suspect, "Effective Java" was written some time before javac substituted > string concatenation by StringBuilder calls, and before HotSpot > optimizations were as performant as they are today. I'm still inquisitive > about some micro-benchmark results. > > -Ulf > > From david.holmes at oracle.com Tue Feb 12 01:33:16 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Feb 2013 11:33:16 +1000 Subject: RFR JDK-8007609 In-Reply-To: <51152FD2.8040706@oracle.com> References: <51127084.3080206@oracle.com> <51138587.1010801@oracle.com> <511394C0.6040908@oracle.com> <511395FA.8060108@oracle.com> <5113A402.6050905@oracle.com> <511443B2.6030705@oracle.com> <5114D73D.8080903@oracle.com> <51152FD2.8040706@oracle.com> Message-ID: <51199BDC.2020009@oracle.com> John, I think the functional fix is okay but you have obscured it in so much "cleanup" that it is hard to say with 100% certainty. Please leave extensive cleanups to separate bugs - in this case I'm not seeing improvements in readability in a number of places (indentation is odd) and in at least one case you have made a change that violates the coding guidelines you cite eg: 126 } else 127 len = 0; The else should have been left as a block. 121 } else { 122 len = 0; 123 } David ----- On 9/02/2013 3:03 AM, John Zavgren wrote: > Greetings: > I posted a new webrev image: > http://cr.openjdk.java.net/~jzavgren/8007609/webrev.03/ > > > The sole "functional" revision is contained in the following small code > snippet: > > - /* retry with a buffer of the right size */ > - result = (WCHAR*)realloc(result, (len+1) * sizeof(WCHAR)); > - if (result != NULL) { > - len = (*GetFinalPathNameByHandle_func)(h, result, > len, 0); > - } else { > + /* retry the procedure with a buffer of the right size. */ > + WCHAR * newResult = (WCHAR*)realloc(result, (len+1) * > sizeof(WCHAR)); > + if (newResult != NULL) { > + result = newResult; > + len = (*GetFinalPathNameByHandle_func)(h, > newResult, len, 0); > + } else > > and, the innovation is the use of a local variable to hold the attempted > memory reallocation. This makes the code simpler and easier to understand. > > I introduced a huge number of additional changes in the file that are my > attempt to make the file consistent with our style guidelines. > > Changes include: > 1.) elimination of tab characters. > 2.) spelling, punctuation, and grammar corrections in the comments. > 3.) truncation of lines that exceed 80 characters > 4.) correction of indentation, line wrapping, etc. > > I hope I haven't missed anything. > http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html > > > On 02/08/2013 05:45 AM, Chris Hegarty wrote: >> Apologies, you are correct. I'll book an appointment with the optician! >> >> -Chris. >> >> On 08/02/2013 00:15, David Holmes wrote: >>> On 7/02/2013 10:54 PM, Chris Hegarty wrote: >>>> On 02/07/2013 11:54 AM, David Holmes wrote: >>>>> .... >>>>>> AFAICS setting len=0 means len==0 will be true and so we will >>>>>> free(result). >>>>> >>>>> And if len != 0 then we will have already freed result, so avoiding a >>>>> double-free. >>>> >>>> Here's the code as it stands today. >>> >>> Yes .... I don't see the problem >>> >>>> >>>> 113 result = (WCHAR*)malloc(MAX_PATH * sizeof(WCHAR)); >>>> 114 if (result != NULL) { >>> >>> we've entered this block so we must free result evetually. >>> >>>> 115 DWORD len = (*GetFinalPathNameByHandle_func)(h, result, >>>> MAX_PATH, 0); >>>> 116 if (len >= MAX_PATH) { >>>> 117 /* retry with a buffer of the right size */ >>>> 118 result = (WCHAR*)realloc(result, (len+1) * sizeof(WCHAR)); >>>> 119 if (result != NULL) { >>>> 120 len = (*GetFinalPathNameByHandle_func)(h, result, len, 0); >>>> 121 } else { >>>> 122 len = 0; >>>> 123 } >>>> 124 } >>>> 125 if (len > 0) { >>> >>> len was good so we've gone this path >>> >>>> 126 /** >>>> 127 * Strip prefix (should be \\?\ or \\?\UNC) >>>> 128 */ >>>> 129 if (result[0] == L'\\' && result[1] == L'\\' && >>>> 130 result[2] == L'?' && result[3] == L'\\') >>>> 131 { >>>> 132 int isUnc = (result[4] == L'U' && >>>> 133 result[5] == L'N' && >>>> 134 result[6] == L'C'); >>>> 135 int prefixLen = (isUnc) ? 7 : 4; >>>> 136 /* actual result length (includes terminator) */ >>>> 137 int resultLen = len - prefixLen + (isUnc ? 1 : 0) + 1; >>>> 138 >>>> 139 /* copy result without prefix into new buffer */ >>>> 140 WCHAR *tmp = (WCHAR*)malloc(resultLen * sizeof(WCHAR)); >>>> 141 if (tmp == NULL) { >>>> 142 len = 0; <<<<<<<<<<<<<<<<<<< HERE >>> >>> malloc failed so we need to bail out. We will now skip to line 161 >>> >>>> 143 } else { >>>> 144 WCHAR *p = result; >>>> 145 p += prefixLen; >>>> 146 if (isUnc) { >>>> 147 WCHAR *p2 = tmp; >>>> 148 p2[0] = L'\\'; >>>> 149 p2++; >>>> 150 wcscpy(p2, p); >>>> 151 } else { >>>> 152 wcscpy(tmp, p); >>>> 153 } >>>> 154 free(result); >>>> 155 result = tmp; >>>> 156 } >>>> 157 } >>>> 158 } >>>> 159 >>>> 160 /* unable to get final path */ >>>> 161 if (len == 0 && result != NULL) { >>> >>> We reach here because len==0 and result != NULL >>> >>>> 162 free(result); >>>> 163 result = NULL; >>>> 164 } >>>> 165 } >>> >>> Looks fine to me. >>> David >>> >>>> -Chris. > > From christian.thalinger at oracle.com Tue Feb 12 02:06:54 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 11 Feb 2013 18:06:54 -0800 Subject: Request for review (M): JDK-7087570: java.lang.invoke.MemberName information wrong for method handles created with findConstructor In-Reply-To: <51154608.2030401@oracle.com> References: <51154608.2030401@oracle.com> Message-ID: <2D75B8BC-BF71-4309-82C6-72A3D76DEFF5@oracle.com> On Feb 8, 2013, at 10:38 AM, Krystal Mo wrote: > Hi all, > > Could I have a couple of review for this change: > > 7087570: java.lang.invoke.MemberName information wrong for method handles created with findConstructor > Summary: REF_invokeSpecial DMHs (which are unusual) get marked explicitly; tweak the MHI to use this bit > Reviewed-by: ? > > Webrev: http://cr.openjdk.java.net/~kmo/7087570/webrev.00/ src/share/classes/java/lang/invoke/DirectMethodHandle.java: + static DirectMethodHandle make(Class receiver, MemberName member) { + byte refKind = member.getReferenceKind(); + if (refKind == REF_invokeSpecial) + refKind = REF_invokeVirtual; + return make(refKind, receiver, member); + } We are replacing all invokespecials with invokevirtuals? -- Chris > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7087570 > ( And a duplicate of this: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005119 ) > > Background: > > When linking methods, HotSpot VM may strength-reduce the invocation mode of some virtual methods from invokevirtual to invokespecial. > e.g. virtual methods in a final class, or non-private member methods marked as final. > When that happens, a method's invocation mode may be nominally "invokevirtual", but the VM actually treats it as "invokespecial". > > Before this fix, the Java-level MethodHandle implementation didn't tell apart the "real" invokespecials with the strength-reduced ones. When creating a MethodHandle via lookup/ldc/unreflect, wrong metadata may be returned if this strength-reduction happened. This broke a few things, including the two scenarios in JDK-7087570 and JDK-8005119. > > With the fix, special handling is added so that a "real" invokespecial is truly a "Special" version of DirectMethodHandle, so users of the MethodHandle will not be affected by the mismatch between the nominal and the actual invocation mode. > > For the record, credit goes to John Rose who did the actual fix. I only added the unit test to verify the fix. > > Tested with JPRT, jtreg test/java/lang/invoke, including the new unit test. > > I intend to push this to jdk8/tl/jdk as it's a Java-only change; I believe langtool people could get the bits earlier this way. > Could somebody from the jdk side help with the push? > > Thanks, > Kris From krystal.mo at oracle.com Tue Feb 12 02:34:12 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Mon, 11 Feb 2013 18:34:12 -0800 Subject: Request for review (M): JDK-7087570: java.lang.invoke.MemberName information wrong for method handles created with findConstructor In-Reply-To: <2D75B8BC-BF71-4309-82C6-72A3D76DEFF5@oracle.com> References: <51154608.2030401@oracle.com> <2D75B8BC-BF71-4309-82C6-72A3D76DEFF5@oracle.com> Message-ID: <5119AA24.3010106@oracle.com> Thank you for the review, Chris. Comments inline: On 02/11/2013 06:06 PM, Christian Thalinger wrote: > > src/share/classes/java/lang/invoke/DirectMethodHandle.java: > > + static DirectMethodHandle make(Class receiver, MemberName member) { > + byte refKind = member.getReferenceKind(); > + if (refKind == REF_invokeSpecial) > + refKind = REF_invokeVirtual; > + return make(refKind, receiver, member); > + } > > We are replacing all invokespecials with invokevirtuals? > > -- Chris This might look a bit hacky... The idea is, DirectMethodHandle.make(Class receiver, MemberName member) should keep its behavior as it used to be. The newly added DirectMethodHandle.make(byte refKind, Class receiver, MemberName member) treats (refKind == invokespecial) "specially", which is necessary when called from MethodHandles.getDirectMethodCommon(...), where invokevirtual got strength-reduced to invokespecial matters; but when called from DirectMethodHandle.make(Class receiver, MemberName member), refKind would need to be something other than invokespecial to keep the original behavior, thus the normalization in DirectMethodHandle.make(Class receiver, MemberName member). This is safe. Let's get John's comment and see if my understanding of that part is correct. Thanks, Kris >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7087570 >> ( And a duplicate of this: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005119 ) >> >> Background: >> >> When linking methods, HotSpot VM may strength-reduce the invocation mode of some virtual methods from invokevirtual to invokespecial. >> e.g. virtual methods in a final class, or non-private member methods marked as final. >> When that happens, a method's invocation mode may be nominally "invokevirtual", but the VM actually treats it as "invokespecial". >> >> Before this fix, the Java-level MethodHandle implementation didn't tell apart the "real" invokespecials with the strength-reduced ones. When creating a MethodHandle via lookup/ldc/unreflect, wrong metadata may be returned if this strength-reduction happened. This broke a few things, including the two scenarios in JDK-7087570 and JDK-8005119. >> >> With the fix, special handling is added so that a "real" invokespecial is truly a "Special" version of DirectMethodHandle, so users of the MethodHandle will not be affected by the mismatch between the nominal and the actual invocation mode. >> >> For the record, credit goes to John Rose who did the actual fix. I only added the unit test to verify the fix. >> >> Tested with JPRT, jtreg test/java/lang/invoke, including the new unit test. >> >> I intend to push this to jdk8/tl/jdk as it's a Java-only change; I believe langtool people could get the bits earlier this way. >> Could somebody from the jdk side help with the push? >> >> Thanks, >> Kris From mike.duigou at oracle.com Tue Feb 12 04:27:14 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 12 Feb 2013 04:27:14 +0000 Subject: hg: jdk8/tl/jdk: 8006594: Add jdk_core target to jdk/test/Makefile Message-ID: <20130212042734.9CCB7479C5@hg.openjdk.java.net> Changeset: 465cce29a9ed Author: mduigou Date: 2013-02-06 11:28 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/465cce29a9ed 8006594: Add jdk_core target to jdk/test/Makefile Reviewed-by: alanb ! make/jprt.properties ! test/Makefile ! test/ProblemList.txt From mike.duigou at oracle.com Tue Feb 12 04:29:29 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 12 Feb 2013 04:29:29 +0000 Subject: hg: jdk8/tl: 8006595: Use jdk/test/Makefile targets in preference to local definitions Message-ID: <20130212042929.27A3C479C6@hg.openjdk.java.net> Changeset: 7817368287cd Author: mduigou Date: 2013-02-06 11:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/7817368287cd 8006595: Use jdk/test/Makefile targets in preference to local definitions Reviewed-by: alanb ! common/makefiles/Main.gmk ! test/Makefile From mike.duigou at oracle.com Tue Feb 12 05:04:35 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 11 Feb 2013 21:04:35 -0800 Subject: RFR (S) CR 8006627: Improving performance and reducing object allocations of java.util.UUID to/from string In-Reply-To: References: <84A32ABE-B1E7-4E03-9843-DDFE20897B77@oracle.com> <0EC036A3-3D11-4F56-B3FD-403CCC610347@gmail.com> Message-ID: <9251F945-7B88-484A-B38F-487A29D66F4D@oracle.com> I have been following up on this issue. I am going to have to adapt the code a bit because there have been some changes in JDK8. I won't forget this issue though. It is possible I may not have time to backport it to Java 7. Mile On Feb 3 2013, at 21:26 , Steven Schlansker wrote: > > On Feb 1, 2013, at 11:42 AM, Mike Duigou wrote: >> >> I have created another issue 8007398 for the changes to Long. We can even test and push the two issues at the same time. Separating them into two changesets makes the intent easier to follow for future maintainers. >> >> We can use the same webrev. There's no need to create another. >> >>>> - I would like to see if performed of toString() can be improved further by using String(char[] value, boolean share) constructor via a sun.miscSharedSecret.JavaLangAccesss method to construct the string directly from the character array. You could test to see if this has positive benefit by temporarily using a static char array. >>> >>> I will incorporate this into my next revision >>> >>>> >>>> - public static String toString(long msb, long lsb) should be private. There's no compelling reason to add this to the API. >>> >>>> - Have you run this code against any of the existing regression tests? >>> >>> Yes, I ran the jtreg UUID and Long tests, all pass. I ran the Apache Harmony UUID test cases against the pre-integrated version of the code. (There should only have been minor modifications since then, variable renamings, whatnot?) >> >> OK, once we have a final webrev then I will run final tests and push this! > > Hi, > > Here are the updates to the webrev. I hope the changes are in line with what you'd had in mind: > http://dl.dropbox.com/u/1422321/uuid_webrev/index.html > http://dl.dropbox.com/u/1422321/uuid_webrev.zip > > Please let me know if there are any further modifications I should make. > > Thanks! > Steven > From stevenschlansker at gmail.com Tue Feb 12 05:18:54 2013 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Mon, 11 Feb 2013 21:18:54 -0800 Subject: RFR (S) CR 8006627: Improving performance and reducing object allocations of java.util.UUID to/from string In-Reply-To: <9251F945-7B88-484A-B38F-487A29D66F4D@oracle.com> References: <84A32ABE-B1E7-4E03-9843-DDFE20897B77@oracle.com> <0EC036A3-3D11-4F56-B3FD-403CCC610347@gmail.com> <9251F945-7B88-484A-B38F-487A29D66F4D@oracle.com> Message-ID: <7DDE01A1-0845-4FE7-9454-958CC5F585FF@gmail.com> On Feb 11, 2013, at 9:04 PM, Mike Duigou wrote: > I have been following up on this issue. I am going to have to adapt the code a bit because there have been some changes in JDK8. > > I won't forget this issue though. It is possible I may not have time to backport it to Java 7. > Please let me know if I can be of any help in a way that doesn't actually cost more work than I end up contributing :-) > Mile > > On Feb 3 2013, at 21:26 , Steven Schlansker wrote: > >> >> On Feb 1, 2013, at 11:42 AM, Mike Duigou wrote: >>> >>> I have created another issue 8007398 for the changes to Long. We can even test and push the two issues at the same time. Separating them into two changesets makes the intent easier to follow for future maintainers. >>> >>> We can use the same webrev. There's no need to create another. >>> >>>>> - I would like to see if performed of toString() can be improved further by using String(char[] value, boolean share) constructor via a sun.miscSharedSecret.JavaLangAccesss method to construct the string directly from the character array. You could test to see if this has positive benefit by temporarily using a static char array. >>>> >>>> I will incorporate this into my next revision >>>> >>>>> >>>>> - public static String toString(long msb, long lsb) should be private. There's no compelling reason to add this to the API. >>>> >>>>> - Have you run this code against any of the existing regression tests? >>>> >>>> Yes, I ran the jtreg UUID and Long tests, all pass. I ran the Apache Harmony UUID test cases against the pre-integrated version of the code. (There should only have been minor modifications since then, variable renamings, whatnot?) >>> >>> OK, once we have a final webrev then I will run final tests and push this! >> >> Hi, >> >> Here are the updates to the webrev. I hope the changes are in line with what you'd had in mind: >> http://dl.dropbox.com/u/1422321/uuid_webrev/index.html >> http://dl.dropbox.com/u/1422321/uuid_webrev.zip >> >> Please let me know if there are any further modifications I should make. >> >> Thanks! >> Steven >> > From john.r.rose at oracle.com Tue Feb 12 05:47:01 2013 From: john.r.rose at oracle.com (John Rose) Date: Mon, 11 Feb 2013 21:47:01 -0800 Subject: Request for review (M): JDK-7087570: java.lang.invoke.MemberName information wrong for method handles created with findConstructor In-Reply-To: <51154608.2030401@oracle.com> References: <51154608.2030401@oracle.com> Message-ID: <5C07106D-4BD8-4688-8052-C28F71FB20F2@oracle.com> On Feb 8, 2013, at 10:38 AM, Krystal Mo wrote: > For the record, credit goes to John Rose who did the actual fix. I only added the unit test to verify the fix. Also FTR, your unit test found a bug which led you to amend the fix. So the final version of the fix, as well as the unit test, is yours. In any case, you can list me as a reviewer. And thanks for taking on this fix. ? John From john.r.rose at oracle.com Tue Feb 12 05:56:54 2013 From: john.r.rose at oracle.com (John Rose) Date: Mon, 11 Feb 2013 21:56:54 -0800 Subject: Request for review (M): JDK-7087570: java.lang.invoke.MemberName information wrong for method handles created with findConstructor In-Reply-To: <5119AA24.3010106@oracle.com> References: <51154608.2030401@oracle.com> <2D75B8BC-BF71-4309-82C6-72A3D76DEFF5@oracle.com> <5119AA24.3010106@oracle.com> Message-ID: On Feb 11, 2013, at 6:34 PM, Krystal Mo wrote: > Let's get John's comment and see if my understanding of that part is correct. The new code treats findSpecial and unreflectSpecial as corner cases. In these corner cases, refKind is invokespecial, *and* this is visible to the user. These cases are covered by a special subclass of DMH (called DMH.Special). This guy always reports invokespecial as his refKind. Meanwhile, all other "normal" DMHs report invokevirtual (or invokeinterface for interfaces). This is true even if they internally use an optimized refKind of invokespecial. So there are three different cases: Lookup call, external refKind, internal refKind, DMH class findVirtual(Object::hashCode), invokevirtual, invokevirtual, DMH findVirtual(String::hashCode), invokevirtual, invokespecial, DMH findSpecial(Object::hashCode), invokespecial, invokespecial, DMH.Special For plain non-special DMH, an internal reference kind of invokespecial is always rewritten to a user-visible invokevirtual. (I suppose if "final default" methods were allowed, they might need rewriting from internal invokespecial to user-visible invokeinterface.) ? John From john.r.rose at oracle.com Tue Feb 12 06:06:19 2013 From: john.r.rose at oracle.com (John Rose) Date: Mon, 11 Feb 2013 22:06:19 -0800 Subject: Request for review (M): JDK-7087570: java.lang.invoke.MemberName information wrong for method handles created with findConstructor In-Reply-To: <5119AA24.3010106@oracle.com> References: <51154608.2030401@oracle.com> <2D75B8BC-BF71-4309-82C6-72A3D76DEFF5@oracle.com> <5119AA24.3010106@oracle.com> Message-ID: On Feb 11, 2013, at 6:34 PM, Krystal Mo wrote: > This might look a bit hacky... > > The idea is, DirectMethodHandle.make(Class receiver, MemberName member) should keep its behavior as it used to P.S. I wonder if we could get rid of that old overloading of DirectMethodHandle.make. I can see how it make Chris raise his eyebrows. From john.r.rose at oracle.com Tue Feb 12 06:54:05 2013 From: john.r.rose at oracle.com (John Rose) Date: Mon, 11 Feb 2013 22:54:05 -0800 Subject: RFR: 8007519: [unpack200] produces bad class files when producing BootstrapMethods attribute In-Reply-To: <511541BE.2060907@oracle.com> References: <511541BE.2060907@oracle.com> Message-ID: <0B90D741-4AD4-4416-9AC6-9B6C9750ECD3@oracle.com> Good fix; thumbs up. ? John On Feb 8, 2013, at 10:19 AM, Kumar Srinivasan wrote: > Hi, > > Please review > http://cr.openjdk.java.net/~ksrini/8007519/webrev.0/ > > Bug: > https://jbs.oracle.com/bugs/browse/JDK-8007519 > > Thanks > Kumar > From brucechapman at paradise.net.nz Tue Feb 12 08:19:38 2013 From: brucechapman at paradise.net.nz (Bruce Chapman) Date: Tue, 12 Feb 2013 21:19:38 +1300 Subject: RFR - 6480539: BigDecimal.stripTrailingZeros() should specify no-op on zero BigDecimals In-Reply-To: <511560C3.9070009@oracle.com> References: <51100C97.4040504@oracle.com> <51104CE4.10506@oracle.com> <1BA5F227-8369-4AC4-A108-165A094BD763@oracle.com> <511358A2.9090408@paradise.net.nz> <511560C3.9070009@oracle.com> Message-ID: <5119FB1A.800@paradise.net.nz> I didn't know that Randall was following this mailing list and this thread. http://xkcd.com/1172/ Bruce On 9/02/2013 9:32 a.m., Joe Darcy wrote: > Hello, > > On 2/6/2013 11:32 PM, Bruce Chapman wrote: >> Stephen, In your case(s) would the workaround fail to work if the bug >> was fixed? >> >> Working around a bug is quite different to taking advantage of the >> buggy behaviour. If fixing the bug would break code that works >> around it that can be seen as a problem, while breaking code that >> relies on the bug is IMHO much less of an issue since anyone that >> does that is taking a known risk, or a risk that should reasonably be >> expected to be known. >> >> I am finding it hard to imagine a genuine attempt at a workaround >> that would not still work (though redundantly) if the bug was fixed. >> >> Also bear in mind that there are other implementations, and the >> signature and the javadoc are the spec. If you find behaviour that >> differs and take advantage of that behaviour then you are opening the >> possibility of it changing if either: you run with another >> implementation, or the bug gets fixed. >> >> While it is easy to contrive an example that would break if this bug >> were fixed, and it is possible (on the grounds that I cannot prove it >> is impossible) that some real code might break, it is hard to imagine >> a scenario where the author/owner of that broken code has any morally >> legitimate grounds for complaint in that case. >> >> I guess if you take the "This is one of those unfortunate cases where >> a bug can become a feature." approach to its logical conclusion then >> no bugs get fixed because there are no bugs, just a nice online list >> of newly discovered unexpected features. > > As noted earlier in this thread, we use a nuanced compatibility policy > in evolving the JDK: > > http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html > > > In particular, besides looking after source and binary compatibility, > we also look to manage behavioral compatibility, that is, to be > mindful of changing what a method does at runtime when called, even > when the specification gives us leeway to do so. > > Let me relate an example of behavioral compatibility from JDK 7. The > method Class.getMethods returns an array of Method objects for the > Class and in part its javadoc has long stated: > > "The elements in the array returned are not sorted and are not in > any particular order." > > Therefore, any caller of Class.getMethods relying on or assuming a > particular order has a bug according to the specification. As a > side-effect of permgen removal in JDK 7, the long-standing (and mostly > stable) order of Method objects returned by HotSpot changed. As > expected, some user applications and tests "broke" after this change > went in. We received requests to "fix" the ordering of > Class.getMethods, which we declined to do given the benefits of > permgen removal and the clear specification that no ordering should be > relied upon. Even though that change in getMethods is allowed by > specification, it is out-of-bounds of what we would do an an update > release but in-bounds for a platform release like JDK 7. > > The reason for this conservatism is because we value keeping the broad > usage of the JDK working :-) > > Getting back to BigDecimal.stripTrailingZeros, we cannot inspect all > usages of this method today, nor can we inspect all the future usages > of BigDecimal.stripTrailingZeros that will be around before JDK 8 is > adopted for the code in question. We know not everyone migrates to a > new JDK release promptly; within the past two years I fielded a > query/complaint about the behavior change in BigDecimal.toString made > between 1.4.2 and JDK 5 and later. > > For these sorts of reasons, the default resolution when the > specification and implementation conflict is to make the specification > match the implementation. There are exceptions to this default. Given > sufficient evidence that changing the behavior of > BigDecimal.stripTrailingZeros would not have adverse consequences on > fielded code, we could change its behavior despite being implemented > that way for about 9 years. > > -Joe > >> >> Bruce >> >> On 7/02/2013 12:16 p.m., Stephen Colebourne wrote: >>> On 5 February 2013 09:09, Paul Sandoz wrote: >>>> This is one of those unfortunate cases where a bug can become a >>>> feature. >>> I *really* don't see how. >>> >>> The method name is absolutely clear about its purpose. "Strip trailing >>> zeros". Anyone relying on it not stripping zeroes for zero needs their >>> head examining. >>> >>> This particular one just happens to be one that I've run across twice >>> and in both cases it required a workaround. I'd argue that there are >>> more people with undiscovered bugs in their code because the method is >>> buggy than people who would break were the method fixed. >>> >>> What bothers me even more is the desire expressed in this thread to >>> simply wish away bugs by redefining the documentation. If the method >>> name is clear enough, like in this case, then its a bug, and a >>> documentation change simply isn't the right solution. >>> Stephen >>> >> > > From joel.franck at oracle.com Tue Feb 12 10:32:07 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Tue, 12 Feb 2013 10:32:07 +0000 Subject: hg: jdk8/tl/langtools: 8004822: RFE to write language model API tests for repeating annotations based on the spec updates Message-ID: <20130212103213.A6A78479CE@hg.openjdk.java.net> Changeset: 973646bf043a Author: jfranck Date: 2013-02-12 11:28 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/973646bf043a 8004822: RFE to write language model API tests for repeating annotations based on the spec updates Reviewed-by: jjg, abuckley Contributed-by: Matherey Nunez + test/tools/javac/processing/model/element/repeatingAnnotations/ElementRepAnnoTester.java + test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerBasicTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedA1Test.java + test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedA2Test.java + test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedB1Test.java + test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedB2Test.java + test/tools/javac/processing/model/element/repeatingAnnotations/MixSingularAndUnofficialContainerBasicTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/MixSingularAndUnofficialContainerInheritedA1Test.java + test/tools/javac/processing/model/element/repeatingAnnotations/MixSingularAndUnofficialContainerInheritedA2Test.java + test/tools/javac/processing/model/element/repeatingAnnotations/MixSingularAndUnofficialContainerInheritedB1Test.java + test/tools/javac/processing/model/element/repeatingAnnotations/MixSingularAndUnofficialContainerInheritedB2Test.java + test/tools/javac/processing/model/element/repeatingAnnotations/OfficialContainerBasicTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/OfficialContainerInheritedTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableBasicTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableInheritedTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableOfficialContainerBasicTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableOfficialContainerInheritedTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableOverrideATest.java + test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableOverrideBTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/SingularBasicTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/SingularInheritedATest.java + test/tools/javac/processing/model/element/repeatingAnnotations/SingularInheritedBTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/UnofficialContainerBasicTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/UnofficialContainerInheritedTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/Bar.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/BarContainer.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/BarContainerContainer.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/BarInherited.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/BarInheritedContainer.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/BarInheritedContainerContainer.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/ExpectedBase.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/ExpectedContainer.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/Foo.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/FooInherited.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/UnofficialContainer.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/UnofficialInheritedContainer.java From dmitry.samersoff at oracle.com Tue Feb 12 12:04:08 2013 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Tue, 12 Feb 2013 12:04:08 +0000 Subject: hg: jdk8/tl/jdk: 8007786: JDK-8002048 testcase doesn't work on Solaris Message-ID: <20130212120441.B8CCD479D2@hg.openjdk.java.net> Changeset: f7fb173ac833 Author: dsamersoff Date: 2013-02-12 16:02 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f7fb173ac833 8007786: JDK-8002048 testcase doesn't work on Solaris Summary: test built in into Solaris shell doesn't have -e operator Reviewed-by: sla, sspitsyn ! test/sun/management/jdp/JdpTest.sh From Ulf.Zibis at CoSoCo.de Tue Feb 12 13:32:05 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Tue, 12 Feb 2013 14:32:05 +0100 Subject: Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer In-Reply-To: References: <51190059.4000505@CoSoCo.de> <51194E7E.6080101@CoSoCo.de> <51198AF8.3010805@CoSoCo.de> Message-ID: <511A4455.9030106@CoSoCo.de> Am 12.02.2013 01:45, schrieb Vitaly Davidovich: > > javac will not replace concat ops across loop iterations, it will replace whichever ones are > inside one loop iteration. This will still create temporary StringBuilder instances. > > As for JIT optimizing further, it would have to fully unroll the loop to have a chance at > eliminating this; I'd be really surprised if loops with nontrivial (and non compile time constant) > trip counts get eliminated. I'd also not rely on JIT here and do the "right" thing manually :). > You also may not have C2 compiler available or may not even be running on hotspot. > Thanks for your clarification, Vitaly. I was just advocating not to throw away readable syntax for suspicious performance advantage. So this brings me to a new idea: Extend the "+"-syntax over all classes of CharSequence !!! -Ulf From vicente.romero at oracle.com Tue Feb 12 13:38:28 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 12 Feb 2013 13:38:28 +0000 Subject: hg: jdk8/tl/langtools: 8006334: javap, JavapTask constructor breaks with null pointer exception if parameter options is null Message-ID: <20130212133831.64F4F479D8@hg.openjdk.java.net> Changeset: 073696f59241 Author: vromero Date: 2013-02-12 13:36 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/073696f59241 8006334: javap, JavapTask constructor breaks with null pointer exception if parameter options is null Reviewed-by: jjg ! src/share/classes/com/sun/tools/javap/JavapTask.java + test/tools/javap/8006334/JavapTaskCtorFailWithNPE.java From brian.burkhalter at oracle.com Tue Feb 12 15:44:31 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 12 Feb 2013 07:44:31 -0800 Subject: RFR - 6480539: BigDecimal.stripTrailingZeros() should specify no-op on zero BigDecimals In-Reply-To: <5119FB1A.800@paradise.net.nz> References: <51100C97.4040504@oracle.com> <51104CE4.10506@oracle.com> <1BA5F227-8369-4AC4-A108-165A094BD763@oracle.com> <511358A2.9090408@paradise.net.nz> <511560C3.9070009@oracle.com> <5119FB1A.800@paradise.net.nz> Message-ID: <66FCC43B-1A81-486F-B5C0-434F3DC9345F@oracle.com> :-) On Feb 12, 2013, at 12:19 AM, Bruce Chapman wrote: > I didn't know that Randall was following this mailing list and this thread. > > http://xkcd.com/1172/ From xueming.shen at oracle.com Tue Feb 12 17:27:13 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 12 Feb 2013 17:27:13 +0000 Subject: hg: jdk8/tl/jdk: 8007392: JSR 310: DateTime API Updates; ... Message-ID: <20130212172753.897C6479E1@hg.openjdk.java.net> Changeset: 7dcb74c3ffba Author: sherman Date: 2013-02-12 09:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7dcb74c3ffba 8007392: JSR 310: DateTime API Updates 8007520: Update date/time classes in j.util and j.sql packages 8007572: Replace existing jdk timezone data at /lib/zi with JSR310's tzdb Summary: Integration of JSR310 Date/Time API for M7 Reviewed-by: darcy, alanb, naoto Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com, masayoshi.okutsu at oracle.com, patrick.zhang at oracle.com ! make/docs/CORE_PKGS.gmk ! make/java/java/FILES_java.gmk ! make/sun/Makefile ! make/sun/javazic/Makefile + make/sun/javazic/tzdata/gmt + make/sun/javazic/tzdata/jdk11_backward ! make/sun/tzdb/Makefile ! make/tools/Makefile ! make/tools/src/build/tools/javazic/Zoneinfo.java ! make/tools/src/build/tools/tzdb/TzdbZoneRulesCompiler.java ! makefiles/GendataTZDB.gmk ! makefiles/GendataTimeZone.gmk ! makefiles/GenerateData.gmk ! makefiles/Tools.gmk ! src/share/classes/java/sql/Date.java ! src/share/classes/java/sql/Time.java ! src/share/classes/java/sql/Timestamp.java ! src/share/classes/java/time/Clock.java ! src/share/classes/java/time/DayOfWeek.java ! src/share/classes/java/time/Duration.java ! src/share/classes/java/time/Instant.java ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/LocalTime.java ! src/share/classes/java/time/Month.java + src/share/classes/java/time/MonthDay.java + src/share/classes/java/time/OffsetDateTime.java + src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/Period.java - src/share/classes/java/time/PeriodParser.java ! src/share/classes/java/time/Ser.java + src/share/classes/java/time/Year.java + src/share/classes/java/time/YearMonth.java ! src/share/classes/java/time/ZoneId.java ! src/share/classes/java/time/ZoneOffset.java ! src/share/classes/java/time/ZoneRegion.java ! src/share/classes/java/time/ZonedDateTime.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/chrono/ChronoDateImpl.java + src/share/classes/java/time/chrono/ChronoLocalDate.java + src/share/classes/java/time/chrono/ChronoLocalDateTime.java + src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java + src/share/classes/java/time/chrono/ChronoZonedDateTime.java + src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java + src/share/classes/java/time/chrono/Chronology.java + src/share/classes/java/time/chrono/Era.java + src/share/classes/java/time/chrono/HijrahChronology.java + src/share/classes/java/time/chrono/HijrahDate.java + src/share/classes/java/time/chrono/HijrahDeviationReader.java + src/share/classes/java/time/chrono/HijrahEra.java + src/share/classes/java/time/chrono/IsoChronology.java + src/share/classes/java/time/chrono/IsoEra.java + src/share/classes/java/time/chrono/JapaneseChronology.java + src/share/classes/java/time/chrono/JapaneseDate.java + src/share/classes/java/time/chrono/JapaneseEra.java + src/share/classes/java/time/chrono/MinguoChronology.java + src/share/classes/java/time/chrono/MinguoDate.java + src/share/classes/java/time/chrono/MinguoEra.java + src/share/classes/java/time/chrono/Ser.java + src/share/classes/java/time/chrono/ThaiBuddhistChronology.java + src/share/classes/java/time/chrono/ThaiBuddhistDate.java + src/share/classes/java/time/chrono/ThaiBuddhistEra.java + src/share/classes/java/time/chrono/package-info.java ! src/share/classes/java/time/format/DateTimeBuilder.java ! src/share/classes/java/time/format/DateTimeFormatStyleProvider.java ! src/share/classes/java/time/format/DateTimeFormatter.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java - src/share/classes/java/time/format/DateTimeFormatters.java ! src/share/classes/java/time/format/DateTimeParseContext.java ! src/share/classes/java/time/format/DateTimePrintContext.java - src/share/classes/java/time/format/DateTimePrintException.java ! src/share/classes/java/time/format/DateTimeTextProvider.java ! src/share/classes/java/time/format/FormatStyle.java + src/share/classes/java/time/format/ZoneName.java ! src/share/classes/java/time/format/package-info.java ! src/share/classes/java/time/overview.html ! src/share/classes/java/time/package-info.java - src/share/classes/java/time/temporal/Chrono.java ! src/share/classes/java/time/temporal/ChronoField.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/ChronoUnit.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/IsoFields.java ! src/share/classes/java/time/temporal/JulianFields.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/Queries.java - src/share/classes/java/time/temporal/Ser.java - src/share/classes/java/time/temporal/SimplePeriod.java ! src/share/classes/java/time/temporal/Temporal.java ! src/share/classes/java/time/temporal/TemporalAccessor.java - src/share/classes/java/time/temporal/TemporalAdder.java ! src/share/classes/java/time/temporal/TemporalAdjuster.java + src/share/classes/java/time/temporal/TemporalAmount.java ! src/share/classes/java/time/temporal/TemporalField.java ! src/share/classes/java/time/temporal/TemporalQuery.java - src/share/classes/java/time/temporal/TemporalSubtractor.java ! src/share/classes/java/time/temporal/TemporalUnit.java ! src/share/classes/java/time/temporal/WeekFields.java - src/share/classes/java/time/temporal/Year.java - src/share/classes/java/time/temporal/YearMonth.java ! src/share/classes/java/time/temporal/package-info.java ! src/share/classes/java/time/zone/TzdbZoneRulesProvider.java ! src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java ! src/share/classes/java/time/zone/ZoneRules.java ! src/share/classes/java/time/zone/ZoneRulesProvider.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/Date.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/GregorianCalendar.java ! src/share/classes/java/util/TimeZone.java ! src/share/classes/sun/text/resources/FormatData.java ! src/share/classes/sun/text/resources/ar/FormatData_ar.java ! src/share/classes/sun/text/resources/el/FormatData_el.java ! src/share/classes/sun/text/resources/hr/FormatData_hr.java ! src/share/classes/sun/text/resources/ja/FormatData_ja.java ! src/share/classes/sun/text/resources/ko/FormatData_ko.java ! src/share/classes/sun/text/resources/sr/FormatData_sr.java ! src/share/classes/sun/text/resources/sv/FormatData_sv.java ! src/share/classes/sun/text/resources/zh/FormatData_zh.java ! src/share/classes/sun/text/resources/zh/FormatData_zh_TW.java ! src/share/classes/sun/util/calendar/CalendarSystem.java ! src/share/classes/sun/util/calendar/LocalGregorianCalendar.java - src/share/classes/sun/util/calendar/TzIDOldMapping.java ! src/share/classes/sun/util/calendar/ZoneInfo.java ! src/share/classes/sun/util/calendar/ZoneInfoFile.java ! src/share/classes/sun/util/locale/provider/CalendarDataUtility.java ! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleResources.java + test/java/sql/JavatimeTest.java + test/java/time/META-INF/services/java.time.chrono.Chronology - test/java/time/META-INF/services/java.time.temporal.Chrono ! test/java/time/tck/java/time/AbstractTCKTest.java + test/java/time/tck/java/time/MockSimplePeriod.java ! test/java/time/tck/java/time/TCKClock.java ! test/java/time/tck/java/time/TCKClock_Fixed.java ! test/java/time/tck/java/time/TCKClock_Offset.java ! test/java/time/tck/java/time/TCKClock_System.java ! test/java/time/tck/java/time/TCKClock_Tick.java ! test/java/time/tck/java/time/TCKDayOfWeek.java ! test/java/time/tck/java/time/TCKDuration.java ! test/java/time/tck/java/time/TCKInstant.java ! test/java/time/tck/java/time/TCKLocalDate.java ! test/java/time/tck/java/time/TCKLocalDateTime.java ! test/java/time/tck/java/time/TCKLocalTime.java ! test/java/time/tck/java/time/TCKMonth.java + test/java/time/tck/java/time/TCKMonthDay.java + test/java/time/tck/java/time/TCKOffsetDateTime.java + test/java/time/tck/java/time/TCKOffsetTime.java + test/java/time/tck/java/time/TCKPeriod.java + test/java/time/tck/java/time/TCKYear.java + test/java/time/tck/java/time/TCKYearMonth.java ! test/java/time/tck/java/time/TCKZoneId.java ! test/java/time/tck/java/time/TCKZoneOffset.java ! test/java/time/tck/java/time/TCKZonedDateTime.java + test/java/time/tck/java/time/TestChronology.java + test/java/time/tck/java/time/TestIsoChronology.java - 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/chrono/CopticChronology.java + test/java/time/tck/java/time/chrono/CopticDate.java + test/java/time/tck/java/time/chrono/CopticEra.java + test/java/time/tck/java/time/chrono/TCKChronology.java + test/java/time/tck/java/time/chrono/TCKTestServiceLoader.java + test/java/time/tck/java/time/chrono/TestChronoLocalDate.java + test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java + test/java/time/tck/java/time/chrono/TestHijrahChronology.java + test/java/time/tck/java/time/chrono/TestJapaneseChronology.java + test/java/time/tck/java/time/chrono/TestMinguoChronology.java + test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java + test/java/time/tck/java/time/format/TCKChronoPrinterParser.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatter.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatters.java - test/java/time/tck/java/time/format/TCKDateTimePrintException.java ! test/java/time/tck/java/time/format/TCKDateTimeTextPrinting.java ! test/java/time/tck/java/time/format/TCKLocalizedFieldParser.java ! test/java/time/tck/java/time/format/TCKLocalizedFieldPrinter.java + test/java/time/tck/java/time/format/TCKLocalizedPrinterParser.java + test/java/time/tck/java/time/format/TCKOffsetPrinterParser.java + test/java/time/tck/java/time/format/TCKPadPrinterParser.java + test/java/time/tck/java/time/format/TCKZoneIdPrinterParser.java - test/java/time/tck/java/time/temporal/TCKISOFields.java + test/java/time/tck/java/time/temporal/TCKIsoFields.java ! test/java/time/tck/java/time/temporal/TCKJulianFields.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/TCKWeekFields.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/TestChronoLocalDate.java ! test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java ! test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java - test/java/time/tck/java/time/temporal/TestISOChrono.java ! test/java/time/tck/java/time/zone/TCKFixedZoneRules.java ! test/java/time/tck/java/time/zone/TCKZoneOffsetTransition.java ! test/java/time/tck/java/time/zone/TCKZoneOffsetTransitionRule.java ! test/java/time/tck/java/time/zone/TCKZoneRules.java ! test/java/time/tck/java/time/zone/TCKZoneRulesProvider.java ! test/java/time/test/java/time/MockSimplePeriod.java ! test/java/time/test/java/time/TestDuration.java ! test/java/time/test/java/time/TestLocalDateTime.java ! test/java/time/test/java/time/TestLocalTime.java + test/java/time/test/java/time/TestMonthDay.java + test/java/time/test/java/time/TestOffsetDateTime.java + test/java/time/test/java/time/TestOffsetDateTime_instants.java + test/java/time/test/java/time/TestOffsetTime.java ! test/java/time/test/java/time/TestPeriod.java - test/java/time/test/java/time/TestPeriodParser.java + test/java/time/test/java/time/TestYear.java + test/java/time/test/java/time/TestYearMonth.java ! test/java/time/test/java/time/TestZoneId.java + test/java/time/test/java/time/chrono/TestExampleCode.java + test/java/time/test/java/time/chrono/TestIsoChronoImpl.java + test/java/time/test/java/time/chrono/TestServiceLoader.java ! test/java/time/test/java/time/format/TestCharLiteralParser.java ! test/java/time/test/java/time/format/TestCharLiteralPrinter.java + test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.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/TestDateTimeTextProvider.java ! test/java/time/test/java/time/format/TestFractionPrinterParser.java + test/java/time/test/java/time/format/TestNonIsoFormatter.java ! test/java/time/test/java/time/format/TestNumberParser.java ! test/java/time/test/java/time/format/TestNumberPrinter.java - test/java/time/test/java/time/format/TestPadParserDecorator.java ! test/java/time/test/java/time/format/TestPadPrinterDecorator.java ! test/java/time/test/java/time/format/TestReducedParser.java ! test/java/time/test/java/time/format/TestReducedPrinter.java ! test/java/time/test/java/time/format/TestSettingsParser.java ! test/java/time/test/java/time/format/TestStringLiteralParser.java ! test/java/time/test/java/time/format/TestStringLiteralPrinter.java ! test/java/time/test/java/time/format/TestTextParser.java ! test/java/time/test/java/time/format/TestTextPrinter.java - test/java/time/test/java/time/format/TestZoneIdParser.java ! test/java/time/test/java/time/format/TestZoneOffsetParser.java ! test/java/time/test/java/time/format/TestZoneOffsetPrinter.java ! test/java/time/test/java/time/format/TestZoneTextPrinterParser.java + test/java/time/test/java/time/format/ZoneName.java ! test/java/time/test/java/time/temporal/MockFieldNoValue.java ! test/java/time/test/java/time/temporal/MockFieldValue.java ! test/java/time/test/java/time/temporal/TestChronoUnit.java ! test/java/time/test/java/time/temporal/TestDateTimeBuilderCombinations.java - test/java/time/test/java/time/temporal/TestISOChronoImpl.java ! test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java + test/java/time/test/java/time/temporal/TestJulianFields.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/TestThaiBuddhistChronoImpl.java - test/java/time/test/java/time/temporal/TestYear.java - test/java/time/test/java/time/temporal/TestYearMonth.java ! test/java/time/test/java/time/zone/TestFixedZoneRules.java ! test/java/time/test/java/util/TestFormatter.java + test/java/util/Calendar/JavatimeTest.java ! test/java/util/TimeZone/OldIDMappingTest.java + test/java/util/TimeZone/TzIDOldMapping.java + test/sun/util/calendar/zi/BackEnd.java + test/sun/util/calendar/zi/Checksum.java + test/sun/util/calendar/zi/DayOfWeek.java + test/sun/util/calendar/zi/Gen.java + test/sun/util/calendar/zi/GenDoc.java + test/sun/util/calendar/zi/Main.java + test/sun/util/calendar/zi/Mappings.java + test/sun/util/calendar/zi/Month.java + test/sun/util/calendar/zi/Rule.java + test/sun/util/calendar/zi/RuleDay.java + test/sun/util/calendar/zi/RuleRec.java + test/sun/util/calendar/zi/Simple.java + test/sun/util/calendar/zi/TestZoneInfo310.java + test/sun/util/calendar/zi/Time.java + test/sun/util/calendar/zi/Timezone.java + test/sun/util/calendar/zi/TzIDOldMapping.java + test/sun/util/calendar/zi/Zone.java + test/sun/util/calendar/zi/ZoneInfoFile.java + test/sun/util/calendar/zi/ZoneInfoOld.java + test/sun/util/calendar/zi/ZoneRec.java + test/sun/util/calendar/zi/Zoneinfo.java + test/sun/util/calendar/zi/tzdata/VERSION + test/sun/util/calendar/zi/tzdata/africa + test/sun/util/calendar/zi/tzdata/antarctica + test/sun/util/calendar/zi/tzdata/asia + test/sun/util/calendar/zi/tzdata/australasia + test/sun/util/calendar/zi/tzdata/backward + test/sun/util/calendar/zi/tzdata/etcetera + test/sun/util/calendar/zi/tzdata/europe + test/sun/util/calendar/zi/tzdata/factory + test/sun/util/calendar/zi/tzdata/gmt + test/sun/util/calendar/zi/tzdata/iso3166.tab + test/sun/util/calendar/zi/tzdata/jdk11_backward + test/sun/util/calendar/zi/tzdata/leapseconds + test/sun/util/calendar/zi/tzdata/northamerica + test/sun/util/calendar/zi/tzdata/pacificnew + test/sun/util/calendar/zi/tzdata/solar87 + test/sun/util/calendar/zi/tzdata/solar88 + test/sun/util/calendar/zi/tzdata/solar89 + test/sun/util/calendar/zi/tzdata/southamerica + test/sun/util/calendar/zi/tzdata/systemv + test/sun/util/calendar/zi/tzdata/zone.tab + test/sun/util/calendar/zi/tzdata_jdk/gmt + test/sun/util/calendar/zi/tzdata_jdk/jdk11_backward + test/sun/util/calendar/zi/tzdata_jdk/jdk11_full_backward From kasperni at gmail.com Tue Feb 12 17:28:40 2013 From: kasperni at gmail.com (Kasper Nielsen) Date: Tue, 12 Feb 2013 18:28:40 +0100 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <5115316A.8050109@oracle.com> References: <5115316A.8050109@oracle.com> Message-ID: Jrockit mission control supports an "exception count" based on exception type. I have found the approach of just counting the total number of exception completely useless. Mainly because there are methods that throw exceptions as part of the normal flow. For example, Class.forName() is commonly used to test whether or not a certain class is on the classpath. And most developers will cringe whenever they see an exception count>0 for an application they think is bug free. On Fri, Feb 8, 2013 at 6:10 PM, Nils Loodin wrote: > It would be interesting to know the number of thrown throwables in the > JVM, to be able to do some high level application diagnostics / statistics. > A good way to put this number would be a performance counter, since it is > accessible both from Java and from the VM. > > http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=8007806 > http://cr.openjdk.java.net/~**nloodin/8007806/webrev.00/ > > Regards, > Nils Loodin > From xueming.shen at oracle.com Tue Feb 12 17:29:25 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 12 Feb 2013 17:29:25 +0000 Subject: hg: jdk8/tl: 8007392: JSR 310: DateTime API Updates Message-ID: <20130212172926.46541479E2@hg.openjdk.java.net> Changeset: fdb1e09519ed Author: sherman Date: 2013-02-12 09:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/fdb1e09519ed 8007392: JSR 310: DateTime API Updates Summary: Integration of JSR310 Date/Time API for M7 Reviewed-by: darcy, alanb, naoto Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com, masayoshi.okutsu at oracle.com, patrick.zhang at oracle.com ! common/makefiles/javadoc/CORE_PKGS.gmk From chris.hegarty at oracle.com Tue Feb 12 17:38:02 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 12 Feb 2013 17:38:02 +0000 Subject: FAILS: test/sun/management/jdp/JdpTest.sh: test: argument expected In-Reply-To: <20130212120441.B8CCD479D2@hg.openjdk.java.net> References: <20130212120441.B8CCD479D2@hg.openjdk.java.net> Message-ID: <511A7DFA.5030101@oracle.com> Dmitry, This test is now failing on several platforms, on jdk8 and 7u-dev ------- result: Passed. Compilation successful #section:shell ----------messages:(3/154)---------- command: shell JdpTest.sh [--jtreg, --no-compile] reason: User specified action: run shell JdpTest.sh --jtreg --no-compile elapsed time (seconds): 0.045 ----------System.out:(0/0)---------- ----------System.err:(1/110)---------- /export2/Users/chris/repos/jdk8/tl/master_top/jdk/test/sun/management/jdp/JdpTest.sh: test: argument expected result: Failed. Execution failed: exit code 1 test result: Failed. Execution failed: exit code 1 -Chris. On 02/12/2013 12:04 PM, dmitry.samersoff at oracle.com wrote: > Changeset: f7fb173ac833 > Author: dsamersoff > Date: 2013-02-12 16:02 +0400 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f7fb173ac833 > > 8007786: JDK-8002048 testcase doesn't work on Solaris > Summary: test built in into Solaris shell doesn't have -e operator > Reviewed-by: sla, sspitsyn > > ! test/sun/management/jdp/JdpTest.sh > From maurizio.cimadamore at oracle.com Tue Feb 12 19:25:52 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 12 Feb 2013 19:25:52 +0000 Subject: hg: jdk8/tl/langtools: 8007464: Add graph inference support Message-ID: <20130212192555.51CF1479EB@hg.openjdk.java.net> Changeset: 2154ed9ff6c8 Author: mcimadamore Date: 2013-02-12 19:25 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2154ed9ff6c8 8007464: Add graph inference support Summary: Add support for more aggressive type-inference scheme Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java + src/share/classes/com/sun/tools/javac/util/GraphUtils.java ! test/tools/javac/6758789/T6758789b.out ! test/tools/javac/Diagnostics/6799605/T6799605.out ! test/tools/javac/diags/examples/CantApplyDiamond1.java ! test/tools/javac/diags/examples/InferredDoNotConformToEq.java ! test/tools/javac/diags/examples/InferredDoNotConformToUpper.java ! test/tools/javac/diags/examples/WhereFreshTvar.java ! test/tools/javac/generics/7015430/T7015430.out ! test/tools/javac/generics/7151802/T7151802.out ! test/tools/javac/generics/diamond/neg/Neg06.out ! test/tools/javac/generics/inference/6278587/T6278587Neg.java ! test/tools/javac/generics/inference/6638712/T6638712d.out ! test/tools/javac/generics/inference/6638712/T6638712e.out ! test/tools/javac/generics/inference/7154127/T7154127.java ! test/tools/javac/generics/inference/7154127/T7154127.out ! test/tools/javac/generics/inference/7177306/T7177306a.out ! test/tools/javac/generics/inference/7177306/T7177306e.java ! test/tools/javac/generics/inference/7177306/T7177306e.out ! test/tools/javac/generics/odersky/BadTest4.java ! test/tools/javac/lambda/TargetType14.out ! test/tools/javac/lambda/TargetType20.java - test/tools/javac/lambda/TargetType20.out ! test/tools/javac/lambda/TargetType28.out ! test/tools/javac/lambda/TargetType50.java - test/tools/javac/lambda/TargetType50.out ! test/tools/javac/lambda/TargetType51.java ! test/tools/javac/lambda/TargetType52.java ! test/tools/javac/lambda/TargetType52.out + test/tools/javac/lambda/TargetType53.java + test/tools/javac/lambda/TargetType54.java + test/tools/javac/lambda/TargetType55.java + test/tools/javac/lambda/TargetType56.java + test/tools/javac/lambda/TargetType57.java + test/tools/javac/lambda/TargetType57.out + test/tools/javac/lambda/TargetType58.java + test/tools/javac/lambda/TargetType59.java + test/tools/javac/lambda/TargetType61.java + test/tools/javac/lambda/TargetType62.java From dmitry.samersoff at oracle.com Tue Feb 12 22:13:06 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 13 Feb 2013 02:13:06 +0400 Subject: FAILS: test/sun/management/jdp/JdpTest.sh: test: argument expected In-Reply-To: <6087B5C4-30D3-4CEF-A175-0D93638CC21A@oracle.com> References: <20130212120441.B8CCD479D2@hg.openjdk.java.net> <511A7DFA.5030101@oracle.com> <6087B5C4-30D3-4CEF-A175-0D93638CC21A@oracle.com> Message-ID: <511ABE72.7020504@oracle.com> Kelly, Good catch but this part of test is not executed under JTReg, and this mistake cause extra mkdir call but not a test error. -Dmitry On 2013-02-12 21:52, Kelly O'Hair wrote: > + if [ ! -f ${_testclasses} ] > needs to be > + if [ ! -d ${_testclasses} ] > > > -kto > > On Feb 12, 2013, at 9:38 AM, Chris Hegarty wrote: > >> Dmitry, >> >> This test is now failing on several platforms, on jdk8 and 7u-dev >> >> ------- >> >> result: Passed. Compilation successful >> >> #section:shell >> ----------messages:(3/154)---------- >> command: shell JdpTest.sh [--jtreg, --no-compile] >> reason: User specified action: run shell JdpTest.sh --jtreg --no-compile >> elapsed time (seconds): 0.045 >> ----------System.out:(0/0)---------- >> ----------System.err:(1/110)---------- >> /export2/Users/chris/repos/jdk8/tl/master_top/jdk/test/sun/management/jdp/JdpTest.sh: test: argument expected >> result: Failed. Execution failed: exit code 1 >> >> >> test result: Failed. Execution failed: exit code 1 >> >> -Chris. >> >> >> On 02/12/2013 12:04 PM, dmitry.samersoff at oracle.com wrote: >>> Changeset: f7fb173ac833 >>> Author: dsamersoff >>> Date: 2013-02-12 16:02 +0400 >>> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f7fb173ac833 >>> >>> 8007786: JDK-8002048 testcase doesn't work on Solaris >>> Summary: test built in into Solaris shell doesn't have -e operator >>> Reviewed-by: sla, sspitsyn >>> >>> ! test/sun/management/jdp/JdpTest.sh >>> > -- 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 Tue Feb 12 22:18:19 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 13 Feb 2013 02:18:19 +0400 Subject: FAILS: test/sun/management/jdp/JdpTest.sh: test: argument expected In-Reply-To: <6087B5C4-30D3-4CEF-A175-0D93638CC21A@oracle.com> References: <20130212120441.B8CCD479D2@hg.openjdk.java.net> <511A7DFA.5030101@oracle.com> <6087B5C4-30D3-4CEF-A175-0D93638CC21A@oracle.com> Message-ID: <511ABFAB.8030409@oracle.com> Kelly, Do you have an idea why I didn't see this failure under jprt? http://sthjprt.se.oracle.com/archives/2013/02/2013-02-08-192233.dsamerso.tl/ -Dmitry On 2013-02-12 21:52, Kelly O'Hair wrote: > + if [ ! -f ${_testclasses} ] > needs to be > + if [ ! -d ${_testclasses} ] > > > -kto > > On Feb 12, 2013, at 9:38 AM, Chris Hegarty wrote: > >> Dmitry, >> >> This test is now failing on several platforms, on jdk8 and 7u-dev >> >> ------- >> >> result: Passed. Compilation successful >> >> #section:shell >> ----------messages:(3/154)---------- >> command: shell JdpTest.sh [--jtreg, --no-compile] >> reason: User specified action: run shell JdpTest.sh --jtreg --no-compile >> elapsed time (seconds): 0.045 >> ----------System.out:(0/0)---------- >> ----------System.err:(1/110)---------- >> /export2/Users/chris/repos/jdk8/tl/master_top/jdk/test/sun/management/jdp/JdpTest.sh: test: argument expected >> result: Failed. Execution failed: exit code 1 >> >> >> test result: Failed. Execution failed: exit code 1 >> >> -Chris. >> >> >> On 02/12/2013 12:04 PM, dmitry.samersoff at oracle.com wrote: >>> Changeset: f7fb173ac833 >>> Author: dsamersoff >>> Date: 2013-02-12 16:02 +0400 >>> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f7fb173ac833 >>> >>> 8007786: JDK-8002048 testcase doesn't work on Solaris >>> Summary: test built in into Solaris shell doesn't have -e operator >>> Reviewed-by: sla, sspitsyn >>> >>> ! test/sun/management/jdp/JdpTest.sh >>> > -- 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 Tue Feb 12 22:19:44 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 12 Feb 2013 14:19:44 -0800 (PST) Subject: FAILS: test/sun/management/jdp/JdpTest.sh: test: argument expected In-Reply-To: <511A7DFA.5030101@oracle.com> References: <20130212120441.B8CCD479D2@hg.openjdk.java.net> <511A7DFA.5030101@oracle.com> Message-ID: <511AC000.5080506@oracle.com> Chris, I'm not able to reproduce it locally. Do you have a link to jprt job you see this failure? -Dmitry On 2013-02-12 21:38, Chris Hegarty wrote: > Dmitry, > > This test is now failing on several platforms, on jdk8 and 7u-dev > > ------- > > result: Passed. Compilation successful > > #section:shell > ----------messages:(3/154)---------- > command: shell JdpTest.sh [--jtreg, --no-compile] > reason: User specified action: run shell JdpTest.sh --jtreg --no-compile > elapsed time (seconds): 0.045 > ----------System.out:(0/0)---------- > ----------System.err:(1/110)---------- > /export2/Users/chris/repos/jdk8/tl/master_top/jdk/test/sun/management/jdp/JdpTest.sh: > test: argument expected > result: Failed. Execution failed: exit code 1 > > > test result: Failed. Execution failed: exit code 1 > > -Chris. > > > On 02/12/2013 12:04 PM, dmitry.samersoff at oracle.com wrote: >> Changeset: f7fb173ac833 >> Author: dsamersoff >> Date: 2013-02-12 16:02 +0400 >> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f7fb173ac833 >> >> 8007786: JDK-8002048 testcase doesn't work on Solaris >> Summary: test built in into Solaris shell doesn't have -e operator >> Reviewed-by: sla, sspitsyn >> >> ! test/sun/management/jdp/JdpTest.sh >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From alejandro.murillo at oracle.com Tue Feb 12 22:34:29 2013 From: alejandro.murillo at oracle.com (alejandro murillo) Date: Tue, 12 Feb 2013 15:34:29 -0700 Subject: FAILS: test/sun/management/jdp/JdpTest.sh: test: argument expected In-Reply-To: <511ABFAB.8030409@oracle.com> References: <20130212120441.B8CCD479D2@hg.openjdk.java.net> <511A7DFA.5030101@oracle.com> <6087B5C4-30D3-4CEF-A175-0D93638CC21A@oracle.com> <511ABFAB.8030409@oracle.com> Message-ID: <511AC375.2050703@oracle.com> Dmitry, you have to use "-testset core" to run this test via JPRT. It's not run on regular jobs. Alejandro On 2/12/2013 3:18 PM, Dmitry Samersoff wrote: > Kelly, > > Do you have an idea why I didn't see this failure under jprt? > > http://sthjprt.se.oracle.com/archives/2013/02/2013-02-08-192233.dsamerso.tl/ > > -Dmitry > > > On 2013-02-12 21:52, Kelly O'Hair wrote: >> + if [ ! -f ${_testclasses} ] >> needs to be >> + if [ ! -d ${_testclasses} ] >> >> >> -kto >> >> On Feb 12, 2013, at 9:38 AM, Chris Hegarty wrote: >> >>> Dmitry, >>> >>> This test is now failing on several platforms, on jdk8 and 7u-dev >>> >>> ------- >>> >>> result: Passed. Compilation successful >>> >>> #section:shell >>> ----------messages:(3/154)---------- >>> command: shell JdpTest.sh [--jtreg, --no-compile] >>> reason: User specified action: run shell JdpTest.sh --jtreg --no-compile >>> elapsed time (seconds): 0.045 >>> ----------System.out:(0/0)---------- >>> ----------System.err:(1/110)---------- >>> /export2/Users/chris/repos/jdk8/tl/master_top/jdk/test/sun/management/jdp/JdpTest.sh: test: argument expected >>> result: Failed. Execution failed: exit code 1 >>> >>> >>> test result: Failed. Execution failed: exit code 1 >>> >>> -Chris. >>> >>> >>> On 02/12/2013 12:04 PM, dmitry.samersoff at oracle.com wrote: >>>> Changeset: f7fb173ac833 >>>> Author: dsamersoff >>>> Date: 2013-02-12 16:02 +0400 >>>> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f7fb173ac833 >>>> >>>> 8007786: JDK-8002048 testcase doesn't work on Solaris >>>> Summary: test built in into Solaris shell doesn't have -e operator >>>> Reviewed-by: sla, sspitsyn >>>> >>>> ! test/sun/management/jdp/JdpTest.sh >>>> > From mike.duigou at oracle.com Tue Feb 12 23:30:24 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 12 Feb 2013 15:30:24 -0800 Subject: RFR (S) CR 8006627/8007398: Improve performance of Long.toUnsignedString0, Integer.toUnsignedString0, UUID(String) and UUID.toString In-Reply-To: <7DDE01A1-0845-4FE7-9454-958CC5F585FF@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> Message-ID: <9E63A0FB-47D8-4993-94DD-258ED9A4EDDA@oracle.com> 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/ I am currently running the jtreg regression suite across the changes. Mike On Feb 11 2013, at 21:18 , Steven Schlansker wrote: > On Feb 11, 2013, at 9:04 PM, Mike Duigou wrote: > >> I have been following up on this issue. I am going to have to adapt the code a bit because there have been some changes in JDK8. >> >> I won't forget this issue though. It is possible I may not have time to backport it to Java 7. >> > > Please let me know if I can be of any help in a way that doesn't actually cost more work than I end up contributing :-) > >> Mile >> >> On Feb 3 2013, at 21:26 , Steven Schlansker wrote: >> >>> >>> On Feb 1, 2013, at 11:42 AM, Mike Duigou wrote: >>>> >>>> I have created another issue 8007398 for the changes to Long. We can even test and push the two issues at the same time. Separating them into two changesets makes the intent easier to follow for future maintainers. >>>> >>>> We can use the same webrev. There's no need to create another. >>>> >>>>>> - I would like to see if performed of toString() can be improved further by using String(char[] value, boolean share) constructor via a sun.miscSharedSecret.JavaLangAccesss method to construct the string directly from the character array. You could test to see if this has positive benefit by temporarily using a static char array. >>>>> >>>>> I will incorporate this into my next revision >>>>> >>>>>> >>>>>> - public static String toString(long msb, long lsb) should be private. There's no compelling reason to add this to the API. >>>>> >>>>>> - Have you run this code against any of the existing regression tests? >>>>> >>>>> Yes, I ran the jtreg UUID and Long tests, all pass. I ran the Apache Harmony UUID test cases against the pre-integrated version of the code. (There should only have been minor modifications since then, variable renamings, whatnot?) >>>> >>>> OK, once we have a final webrev then I will run final tests and push this! >>> >>> Hi, >>> >>> Here are the updates to the webrev. I hope the changes are in line with what you'd had in mind: >>> http://dl.dropbox.com/u/1422321/uuid_webrev/index.html >>> http://dl.dropbox.com/u/1422321/uuid_webrev.zip >>> >>> Please let me know if there are any further modifications I should make. >>> >>> Thanks! >>> Steven >>> >> > From jonathan.gibbons at oracle.com Wed Feb 13 01:16:05 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 13 Feb 2013 01:16:05 +0000 Subject: hg: jdk8/tl/langtools: 8008077: update reference impl for type-annotations Message-ID: <20130213011609.95D9047A01@hg.openjdk.java.net> Changeset: bc456436c613 Author: jjg Date: 2013-02-12 17:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bc456436c613 8008077: update reference impl for type-annotations Reviewed-by: jjg Contributed-by: wmdietl at cs.washington.edu ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/classfile/TypeAnnotation.java ! src/share/classes/com/sun/tools/javac/code/TargetType.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.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/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javap/AnnotationWriter.java + test/tools/javac/annotations/typeAnnotations/failures/LazyConstantValue.java + test/tools/javac/annotations/typeAnnotations/failures/TypeVariable.java ! test/tools/javac/annotations/typeAnnotations/failures/VoidGenericMethod.java + test/tools/javac/annotations/typeAnnotations/newlocations/Lambda.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/Lambda.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodParameters.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/TypeCasts.java From Ulf.Zibis at CoSoCo.de Wed Feb 13 01:24:12 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Wed, 13 Feb 2013 02:24:12 +0100 Subject: RFR (S) CR 8006627/8007398: Improve performance of Long.toUnsignedString0, Integer.toUnsignedString0, UUID(String) and UUID.toString In-Reply-To: <9E63A0FB-47D8-4993-94DD-258ED9A4EDDA@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> Message-ID: <511AEB3C.6050309@CoSoCo.de> 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 ? Instead of calculating the mask each time, you could use: 309 private static String toUnsignedString(int i, int shift, int mask) { Additionally in e.g. Integer.toString(int i, int radix) you could provide the fast version with: 134 /* Use the faster version */ 135 switch (radix) { 136 case 2: return toString(i, 1, 0x1); 136 case 4: return toString(i, 2, 0x3); 136 case 8: return toString(i, 3, 0x7); 136 case 10: return toString(i); 136 case 16: return toString(i, 4, 0xF); 136 case 32: return toString(i, 5, 0x1F); 137 } -Ulf From mike.duigou at oracle.com Wed Feb 13 01:34:33 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 12 Feb 2013 17:34:33 -0800 Subject: RFR (S) CR 8006627/8007398: Improve performance of Long.toUnsignedString0, Integer.toUnsignedString0, UUID(String) and UUID.toString In-Reply-To: <511AEB3C.6050309@CoSoCo.de> 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> Message-ID: <0AA1CB21-D478-4FF5-A880-9B01E5052268@oracle.com> 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. > Additionally in e.g. Integer.toString(int i, int radix) you could provide the fast version with: I think the only change I will make is to Integer.toUnsignedString() which becomes : return Long.toUnsignedString(toUnsignedLong(i), radix); Mike From Ulf.Zibis at CoSoCo.de Wed Feb 13 01:42:58 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Wed, 13 Feb 2013 02:42:58 +0100 Subject: RFR (S) CR 8006627/8007398: Improve performance of Long.toUnsignedString0, Integer.toUnsignedString0, UUID(String) and UUID.toString In-Reply-To: <9E63A0FB-47D8-4993-94DD-258ED9A4EDDA@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> Message-ID: <511AEFA2.50407@CoSoCo.de> 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/ In java.lang.System: There is a space missing before '{' 1189 sun.misc.SharedSecrets.setJavaLangAccess(new sun.misc.JavaLangAccess(){ Additionally I more would like "clazz" instead "klass" for following parameters. -Ulf From Ulf.Zibis at CoSoCo.de Wed Feb 13 02:25:54 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Wed, 13 Feb 2013 03:25:54 +0100 Subject: RFR (S) CR 8006627/8007398: Improve performance of Long.toUnsignedString0, Integer.toUnsignedString0, UUID(String) and UUID.toString In-Reply-To: <0AA1CB21-D478-4FF5-A880-9B01E5052268@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> Message-ID: <511AF9B2.6060601@CoSoCo.de> 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 joel.franck at oracle.com Wed Feb 13 09:34:40 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Wed, 13 Feb 2013 09:34:40 +0000 Subject: hg: jdk8/tl/langtools: 8007279: Rename javax.l.model.element.Element.getAnnotations(Class) to getAnnotationsByType(Class) Message-ID: <20130213093444.F348847A14@hg.openjdk.java.net> Changeset: aeadaf905d78 Author: jfranck Date: 2013-02-13 10:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/aeadaf905d78 8007279: Rename javax.l.model.element.Element.getAnnotations(Class) to getAnnotationsByType(Class) Reviewed-by: darcy, abuckley ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/javax/lang/model/element/Element.java ! test/tools/javac/processing/model/element/repeatingAnnotations/ElementRepAnnoTester.java From yekaterina.kantserova at oracle.com Wed Feb 13 09:47:32 2013 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 13 Feb 2013 10:47:32 +0100 Subject: RFR (XS) 8008089: Delete OS dependent check in JdkFinder.getExecutable() Message-ID: <511B6134.3010005@oracle.com> Hi everyone, This small fixconcerns jdk.testlibrary.JdkFinder utility class. The check below is too OS dependent and should be deleted. ... binPath += File.separatorChar + "bin" + File.separatorChar + executable; File toolFile = new File(binPath); ==> if (!toolFile.exists()) { throw new RuntimeException(binPath + " does not exist"); } ... On windows if executable is specified as e.g. 'java', without '.exe', the File exists() will fail. But it's still possible to run executable. Webrev: http://cr.openjdk.java.net/~ykantser/8008089/webrev.00/ Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008089 Testing: JPRT Thanks, Katja From joel.franck at oracle.com Wed Feb 13 10:24:12 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Wed, 13 Feb 2013 10:24:12 +0000 Subject: hg: jdk8/tl/jdk: 8007278: Rename j.l.r.AnnotatedElement.getAnnotations(Class) to getAnnotationsByType(Class) Message-ID: <20130213102440.E03F147A17@hg.openjdk.java.net> Changeset: 2cd67a8c7abc Author: jfranck Date: 2013-02-13 10:36 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2cd67a8c7abc 8007278: Rename j.l.r.AnnotatedElement.getAnnotations(Class) to getAnnotationsByType(Class) Reviewed-by: darcy, abuckley ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/reflect/AccessibleObject.java ! src/share/classes/java/lang/reflect/AnnotatedElement.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Parameter.java ! src/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java ! test/java/lang/annotation/TypeParamAnnotation.java ! test/java/lang/annotation/repeatingAnnotations/RepeatedUnitTest.java From chris.hegarty at oracle.com Wed Feb 13 10:53:58 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 13 Feb 2013 10:53:58 +0000 Subject: FAILS: test/sun/management/jdp/JdpTest.sh: test: argument expected In-Reply-To: <511AC000.5080506@oracle.com> References: <20130212120441.B8CCD479D2@hg.openjdk.java.net> <511A7DFA.5030101@oracle.com> <511AC000.5080506@oracle.com> Message-ID: <511B70C6.4040609@oracle.com> Dmitry, I have a trivial patch that resolves this issue. I would like to push it to jdk8/tl today before we freeze for M7, and have this failure escape into master. The change is to simply use conditions that are also supported by bourne shell . diff -r 7dcb74c3ffba test/sun/management/jdp/JdpTest.sh --- a/test/sun/management/jdp/JdpTest.sh Tue Feb 12 09:25:43 2013 -0800 +++ b/test/sun/management/jdp/JdpTest.sh Wed Feb 13 10:48:28 2013 +0000 @@ -51,7 +51,7 @@ _do_compile(){ # sun.* packages is not included to symbol file lib/ct.sym so we have # to ignore it - if [ ! -f ${_testclasses} ] + if [ ! -d ${_testclasses} ] then mkdir -p ${_testclasses} fi @@ -319,7 +319,7 @@ rm -f ${_logname} rm -f ${_logname} rm -f ${_policyname} -if [ -e ${_testsrc}/policy.tpl ] +if [ -f ${_testsrc}/policy.tpl ] then cat ${_testsrc}/policy.tpl | \ -Chris. On 12/02/2013 22:19, Dmitry Samersoff wrote: > Chris, > > I'm not able to reproduce it locally. Do you have a link to jprt job you > see this failure? > > -Dmitry > > On 2013-02-12 21:38, Chris Hegarty wrote: >> Dmitry, >> >> This test is now failing on several platforms, on jdk8 and 7u-dev >> >> ------- >> >> result: Passed. Compilation successful >> >> #section:shell >> ----------messages:(3/154)---------- >> command: shell JdpTest.sh [--jtreg, --no-compile] >> reason: User specified action: run shell JdpTest.sh --jtreg --no-compile >> elapsed time (seconds): 0.045 >> ----------System.out:(0/0)---------- >> ----------System.err:(1/110)---------- >> /export2/Users/chris/repos/jdk8/tl/master_top/jdk/test/sun/management/jdp/JdpTest.sh: >> test: argument expected >> result: Failed. Execution failed: exit code 1 >> >> >> test result: Failed. Execution failed: exit code 1 >> >> -Chris. >> >> >> On 02/12/2013 12:04 PM, dmitry.samersoff at oracle.com wrote: >>> Changeset: f7fb173ac833 >>> Author: dsamersoff >>> Date: 2013-02-12 16:02 +0400 >>> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f7fb173ac833 >>> >>> 8007786: JDK-8002048 testcase doesn't work on Solaris >>> Summary: test built in into Solaris shell doesn't have -e operator >>> Reviewed-by: sla, sspitsyn >>> >>> ! test/sun/management/jdp/JdpTest.sh >>> > > From dmitry.samersoff at oracle.com Wed Feb 13 11:11:22 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 13 Feb 2013 15:11:22 +0400 Subject: FAILS: test/sun/management/jdp/JdpTest.sh: test: argument expected In-Reply-To: <511B70C6.4040609@oracle.com> References: <20130212120441.B8CCD479D2@hg.openjdk.java.net> <511A7DFA.5030101@oracle.com> <511AC000.5080506@oracle.com> <511B70C6.4040609@oracle.com> Message-ID: <511B74DA.40506@oracle.com> Chris, Will push it in few hours. -Dmitry On 2013-02-13 14:53, Chris Hegarty wrote: > Dmitry, > > I have a trivial patch that resolves this issue. I would like to push it > to jdk8/tl today before we freeze for M7, and have this failure escape > into master. > > The change is to simply use conditions that are also supported by bourne > shell . > > diff -r 7dcb74c3ffba test/sun/management/jdp/JdpTest.sh > --- a/test/sun/management/jdp/JdpTest.sh Tue Feb 12 09:25:43 2013 > -0800 > +++ b/test/sun/management/jdp/JdpTest.sh Wed Feb 13 10:48:28 2013 > +0000 > @@ -51,7 +51,7 @@ _do_compile(){ > # sun.* packages is not included to symbol file lib/ct.sym so we have > # to ignore it > > - if [ ! -f ${_testclasses} ] > + if [ ! -d ${_testclasses} ] > then > mkdir -p ${_testclasses} > fi > @@ -319,7 +319,7 @@ rm -f ${_logname} > rm -f ${_logname} > rm -f ${_policyname} > > -if [ -e ${_testsrc}/policy.tpl ] > +if [ -f ${_testsrc}/policy.tpl ] > then > > cat ${_testsrc}/policy.tpl | \ > > -Chris. > > On 12/02/2013 22:19, Dmitry Samersoff wrote: >> Chris, >> >> I'm not able to reproduce it locally. Do you have a link to jprt job you >> see this failure? >> >> -Dmitry >> >> On 2013-02-12 21:38, Chris Hegarty wrote: >>> Dmitry, >>> >>> This test is now failing on several platforms, on jdk8 and 7u-dev >>> >>> ------- >>> >>> result: Passed. Compilation successful >>> >>> #section:shell >>> ----------messages:(3/154)---------- >>> command: shell JdpTest.sh [--jtreg, --no-compile] >>> reason: User specified action: run shell JdpTest.sh --jtreg --no-compile >>> elapsed time (seconds): 0.045 >>> ----------System.out:(0/0)---------- >>> ----------System.err:(1/110)---------- >>> /export2/Users/chris/repos/jdk8/tl/master_top/jdk/test/sun/management/jdp/JdpTest.sh: >>> >>> test: argument expected >>> result: Failed. Execution failed: exit code 1 >>> >>> >>> test result: Failed. Execution failed: exit code 1 >>> >>> -Chris. >>> >>> >>> On 02/12/2013 12:04 PM, dmitry.samersoff at oracle.com wrote: >>>> Changeset: f7fb173ac833 >>>> Author: dsamersoff >>>> Date: 2013-02-12 16:02 +0400 >>>> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f7fb173ac833 >>>> >>>> 8007786: JDK-8002048 testcase doesn't work on Solaris >>>> Summary: test built in into Solaris shell doesn't have -e operator >>>> Reviewed-by: sla, sspitsyn >>>> >>>> ! test/sun/management/jdp/JdpTest.sh >>>> >> >> -- 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 Wed Feb 13 14:40:56 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 13 Feb 2013 18:40:56 +0400 Subject: RR(S): 8008095.JDP-TEST3 (was Re: FAILS: test/sun/management/jdp/JdpTest.sh: test: argument expected) In-Reply-To: <511B70C6.4040609@oracle.com> References: <20130212120441.B8CCD479D2@hg.openjdk.java.net> <511A7DFA.5030101@oracle.com> <511AC000.5080506@oracle.com> <511B70C6.4040609@oracle.com> Message-ID: <511BA5F8.5070502@oracle.com> Chris, Please take a look at the final changes: http://cr.openjdk.java.net/~dsamersoff/8008095.JDP-TEST3/webrev.01/jdk/ I still not able to get valuable results from jprt but tried couple of different solaris machines and hope this time the problem with this test is gone. I'm ready to push it right after your response. -Dmitry On 2013-02-13 14:53, Chris Hegarty wrote: > Dmitry, > > I have a trivial patch that resolves this issue. I would like to push it > to jdk8/tl today before we freeze for M7, and have this failure escape > into master. > > The change is to simply use conditions that are also supported by bourne > shell . > > diff -r 7dcb74c3ffba test/sun/management/jdp/JdpTest.sh > --- a/test/sun/management/jdp/JdpTest.sh Tue Feb 12 09:25:43 2013 > -0800 > +++ b/test/sun/management/jdp/JdpTest.sh Wed Feb 13 10:48:28 2013 > +0000 > @@ -51,7 +51,7 @@ _do_compile(){ > # sun.* packages is not included to symbol file lib/ct.sym so we have > # to ignore it > > - if [ ! -f ${_testclasses} ] > + if [ ! -d ${_testclasses} ] > then > mkdir -p ${_testclasses} > fi > @@ -319,7 +319,7 @@ rm -f ${_logname} > rm -f ${_logname} > rm -f ${_policyname} > > -if [ -e ${_testsrc}/policy.tpl ] > +if [ -f ${_testsrc}/policy.tpl ] > then > > cat ${_testsrc}/policy.tpl | \ > > -Chris. > > On 12/02/2013 22:19, Dmitry Samersoff wrote: >> Chris, >> >> I'm not able to reproduce it locally. Do you have a link to jprt job you >> see this failure? >> >> -Dmitry >> >> On 2013-02-12 21:38, Chris Hegarty wrote: >>> Dmitry, >>> >>> This test is now failing on several platforms, on jdk8 and 7u-dev >>> >>> ------- >>> >>> result: Passed. Compilation successful >>> >>> #section:shell >>> ----------messages:(3/154)---------- >>> command: shell JdpTest.sh [--jtreg, --no-compile] >>> reason: User specified action: run shell JdpTest.sh --jtreg --no-compile >>> elapsed time (seconds): 0.045 >>> ----------System.out:(0/0)---------- >>> ----------System.err:(1/110)---------- >>> /export2/Users/chris/repos/jdk8/tl/master_top/jdk/test/sun/management/jdp/JdpTest.sh: >>> >>> test: argument expected >>> result: Failed. Execution failed: exit code 1 >>> >>> >>> test result: Failed. Execution failed: exit code 1 >>> >>> -Chris. >>> >>> >>> On 02/12/2013 12:04 PM, dmitry.samersoff at oracle.com wrote: >>>> Changeset: f7fb173ac833 >>>> Author: dsamersoff >>>> Date: 2013-02-12 16:02 +0400 >>>> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f7fb173ac833 >>>> >>>> 8007786: JDK-8002048 testcase doesn't work on Solaris >>>> Summary: test built in into Solaris shell doesn't have -e operator >>>> Reviewed-by: sla, sspitsyn >>>> >>>> ! test/sun/management/jdp/JdpTest.sh >>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From zhengyu.gu at oracle.com Wed Feb 13 15:14:55 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Wed, 13 Feb 2013 15:14:55 +0000 Subject: hg: jdk8/tl/jdk: 8006691: Remove jvm_version_info->is_kernel_jvm field Message-ID: <20130213151507.412A047A21@hg.openjdk.java.net> Changeset: cd111064d4e9 Author: zgu Date: 2013-02-12 14:47 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd111064d4e9 8006691: Remove jvm_version_info->is_kernel_jvm field Summary: Remove is_kernel_jvm field in jvm_version_info structure, as kernel VM has been deprecated Reviewed-by: mchung ! src/share/javavm/export/jvm.h From vincent.x.ryan at oracle.com Wed Feb 13 16:04:18 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Wed, 13 Feb 2013 16:04:18 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130213160452.06FAF47A29@hg.openjdk.java.net> Changeset: bf64f83aa0cd Author: vinnie Date: 2013-02-13 16:01 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bf64f83aa0cd 8007934: algorithm parameters for PBE Scheme 2 not decoded correctly in PKCS12 keystore Reviewed-by: mullan ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! test/java/security/KeyStore/PBETest.java Changeset: ceb7c712c693 Author: vinnie Date: 2013-02-13 16:03 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ceb7c712c693 Merge From maurizio.cimadamore at oracle.com Wed Feb 13 17:04:51 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 13 Feb 2013 17:04:51 +0000 Subject: hg: jdk8/tl/langtools: 8006345: Report Synthesized Parameters in java.lang.reflect.Parameter API; ... Message-ID: <20130213170456.BF6DA47A2F@hg.openjdk.java.net> Changeset: d04960f05593 Author: mcimadamore Date: 2013-02-13 17:04 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d04960f05593 8006345: Report Synthesized Parameters in java.lang.reflect.Parameter API 8006896: ClassReader doesn't see MethodParameters attr for method of anon inner class 8007098: Output Synthesized Parameters to MethodParameters Attributes Summary: Correctly report synthesized and mandated parameters Reviewed-by: mcimadamore, jjg Contributed-by: eric.mccorkle at oracle.com ! src/share/classes/com/sun/tools/classfile/AccessFlags.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Symbol.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/ClassWriter.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java From dmitry.samersoff at oracle.com Wed Feb 13 17:07:34 2013 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Wed, 13 Feb 2013 17:07:34 +0000 Subject: hg: jdk8/tl/jdk: 8008095: TEST_BUG: JDK-8002048 one more testcase failure on Solaris Message-ID: <20130213170800.8425947A30@hg.openjdk.java.net> Changeset: 8181be9a3538 Author: dsamersoff Date: 2013-02-13 21:06 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8181be9a3538 8008095: TEST_BUG: JDK-8002048 one more testcase failure on Solaris Summary: fixed couple of more Solaris shell incompatibilities Reviewed-by: chegar ! test/sun/management/jdp/JdpTest.sh From chris.hegarty at oracle.com Wed Feb 13 17:21:16 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 13 Feb 2013 17:21:16 +0000 Subject: RR(S): 8008095.JDP-TEST3 (was Re: FAILS: test/sun/management/jdp/JdpTest.sh: test: argument expected) In-Reply-To: <511BA5F8.5070502@oracle.com> References: <20130212120441.B8CCD479D2@hg.openjdk.java.net> <511A7DFA.5030101@oracle.com> <511AC000.5080506@oracle.com> <511B70C6.4040609@oracle.com> <511BA5F8.5070502@oracle.com> Message-ID: <511BCB8C.2040205@oracle.com> Looks fine to me. -Chris. On 13/02/2013 14:40, Dmitry Samersoff wrote: > Chris, > > Please take a look at the final changes: > > http://cr.openjdk.java.net/~dsamersoff/8008095.JDP-TEST3/webrev.01/jdk/ > > I still not able to get valuable results from jprt but tried couple of > different solaris machines and hope this time the problem with this test > is gone. > > I'm ready to push it right after your response. > > -Dmitry > > On 2013-02-13 14:53, Chris Hegarty wrote: >> Dmitry, >> >> I have a trivial patch that resolves this issue. I would like to push it >> to jdk8/tl today before we freeze for M7, and have this failure escape >> into master. >> >> The change is to simply use conditions that are also supported by bourne >> shell . >> >> diff -r 7dcb74c3ffba test/sun/management/jdp/JdpTest.sh >> --- a/test/sun/management/jdp/JdpTest.sh Tue Feb 12 09:25:43 2013 >> -0800 >> +++ b/test/sun/management/jdp/JdpTest.sh Wed Feb 13 10:48:28 2013 >> +0000 >> @@ -51,7 +51,7 @@ _do_compile(){ >> # sun.* packages is not included to symbol file lib/ct.sym so we have >> # to ignore it >> >> - if [ ! -f ${_testclasses} ] >> + if [ ! -d ${_testclasses} ] >> then >> mkdir -p ${_testclasses} >> fi >> @@ -319,7 +319,7 @@ rm -f ${_logname} >> rm -f ${_logname} >> rm -f ${_policyname} >> >> -if [ -e ${_testsrc}/policy.tpl ] >> +if [ -f ${_testsrc}/policy.tpl ] >> then >> >> cat ${_testsrc}/policy.tpl | \ >> >> -Chris. >> >> On 12/02/2013 22:19, Dmitry Samersoff wrote: >>> Chris, >>> >>> I'm not able to reproduce it locally. Do you have a link to jprt job you >>> see this failure? >>> >>> -Dmitry >>> >>> On 2013-02-12 21:38, Chris Hegarty wrote: >>>> Dmitry, >>>> >>>> This test is now failing on several platforms, on jdk8 and 7u-dev >>>> >>>> ------- >>>> >>>> result: Passed. Compilation successful >>>> >>>> #section:shell >>>> ----------messages:(3/154)---------- >>>> command: shell JdpTest.sh [--jtreg, --no-compile] >>>> reason: User specified action: run shell JdpTest.sh --jtreg --no-compile >>>> elapsed time (seconds): 0.045 >>>> ----------System.out:(0/0)---------- >>>> ----------System.err:(1/110)---------- >>>> /export2/Users/chris/repos/jdk8/tl/master_top/jdk/test/sun/management/jdp/JdpTest.sh: >>>> >>>> test: argument expected >>>> result: Failed. Execution failed: exit code 1 >>>> >>>> >>>> test result: Failed. Execution failed: exit code 1 >>>> >>>> -Chris. >>>> >>>> >>>> On 02/12/2013 12:04 PM, dmitry.samersoff at oracle.com wrote: >>>>> Changeset: f7fb173ac833 >>>>> Author: dsamersoff >>>>> Date: 2013-02-12 16:02 +0400 >>>>> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f7fb173ac833 >>>>> >>>>> 8007786: JDK-8002048 testcase doesn't work on Solaris >>>>> Summary: test built in into Solaris shell doesn't have -e operator >>>>> Reviewed-by: sla, sspitsyn >>>>> >>>>> ! test/sun/management/jdp/JdpTest.sh >>>>> >>> >>> > > From mandy.chung at oracle.com Wed Feb 13 17:29:34 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 13 Feb 2013 09:29:34 -0800 Subject: RFR (S) : JDK-8007736 - VerifyError for use of static method in interface In-Reply-To: <511B0C17.60803@oracle.com> References: <51159F10.70407@oracle.com> <5115ACCB.4020705@oracle.com> <5116329F.9040700@univ-mlv.fr> <5116D42F.4060402@oracle.com> <51190C81.4080200@oracle.com> <51198D50.2040002@oracle.com> <5119992A.9000203@oracle.com> <511B0C17.60803@oracle.com> Message-ID: <511BCD7E.5090600@oracle.com> Bharadwaj, I'm including core-libs-dev so that they know this fix is coming. > http://cr.openjdk.java.net/~bharadwaj/8007736/jdk8-tl-jdk/webrev/ The jdk change looks okay to me. Minor nit: L1250-1251: some identation will help. You can follow the original formatting - breaking '?' and ':" in the newlines. Can you include the new regression test in the jdk repo as well (test/vm/verifier directory)? That'll make sure this test is run by core-libs and JPRT job (it's part of the default testset). Thanks Mandy On 2/12/2013 7:44 PM, S. Bharadwaj Yadavalli wrote: > On 2/12/2013 2:17 PM, Karen Kinnear wrote: >> Code looks good. I like this length of test too :-) > > Thanks for the review, Karen. > >> Please check -XX:-UseSplitVerifier to see if we also need to fix the >> old verifier for new >> classfiles. > > I checked with -XX:-UseSplitVerifier and found that I needed to fix > the old verifier. > > I updated the webrev with my changes which now need to be made to jdk > tree as well as hotspot tree. > The changes to hotspot tree remain the same as reviewed previously by > David Holmes, Krystal Mo and > Remi Forax. > > Please review the jdk tree changes (to the old verifier). > > Updated webrevs > hotspot-rt tree : > http://cr.openjdk.java.net/~bharadwaj/8007736/hotspot-rt/webrev > jdk8/tl/jdl tree : > http://cr.openjdk.java.net/~bharadwaj/8007736/jdk8-tl-jdk/webrev/ > > Bug fixed : https://jbs.oracle.com/bugs/browse/JDK-8007736 > > Summary of changes : > Java 8 allows public static interface methods. To accommodate > for this, the proposed change modifies bytecode verification of Java > 8 classfiles to allow invokestatic to refer to static interface > methods in CONSTANT_InterfaceMethodref as well as static class > methods in CONSTANT_Methodref. > > New test added : > A new jtreg test in hotspot/test/runtime is added. > > Thanks, > > Bharadwaj > From bharadwaj.yadavalli at oracle.com Wed Feb 13 18:04:57 2013 From: bharadwaj.yadavalli at oracle.com (S. Bharadwaj Yadavalli) Date: Wed, 13 Feb 2013 13:04:57 -0500 Subject: RFR (S) : JDK-8007736 - VerifyError for use of static method in interface In-Reply-To: <511BCD7E.5090600@oracle.com> References: <51159F10.70407@oracle.com> <5115ACCB.4020705@oracle.com> <5116329F.9040700@univ-mlv.fr> <5116D42F.4060402@oracle.com> <51190C81.4080200@oracle.com> <51198D50.2040002@oracle.com> <5119992A.9000203@oracle.com> <511B0C17.60803@oracle.com> <511BCD7E.5090600@oracle.com> Message-ID: <511BD5C9.2070300@oracle.com> Mandy, Thanks for the review. I made the suggested changes and updated the webrev. Thanks, Bharadwaj On 2/13/2013 12:29 PM, Mandy Chung wrote: > Bharadwaj, > > I'm including core-libs-dev so that they know this fix is coming. > >> http://cr.openjdk.java.net/~bharadwaj/8007736/jdk8-tl-jdk/webrev/ > > The jdk change looks okay to me. Minor nit: L1250-1251: some > identation will help. You can follow the original formatting - > breaking '?' and ':" in the newlines. > > Can you include the new regression test in the jdk repo as well > (test/vm/verifier directory)? That'll make sure this test is run by > core-libs and JPRT job (it's part of the default testset). > > Thanks > Mandy > > On 2/12/2013 7:44 PM, S. Bharadwaj Yadavalli wrote: >> On 2/12/2013 2:17 PM, Karen Kinnear wrote: >>> Code looks good. I like this length of test too :-) >> >> Thanks for the review, Karen. >> >>> Please check -XX:-UseSplitVerifier to see if we also need to fix the >>> old verifier for new >>> classfiles. >> >> I checked with -XX:-UseSplitVerifier and found that I needed to fix >> the old verifier. >> >> I updated the webrev with my changes which now need to be made to jdk >> tree as well as hotspot tree. >> The changes to hotspot tree remain the same as reviewed previously by >> David Holmes, Krystal Mo and >> Remi Forax. >> >> Please review the jdk tree changes (to the old verifier). >> >> Updated webrevs >> hotspot-rt tree : >> http://cr.openjdk.java.net/~bharadwaj/8007736/hotspot-rt/webrev >> jdk8/tl/jdl tree : >> http://cr.openjdk.java.net/~bharadwaj/8007736/jdk8-tl-jdk/webrev/ >> >> Bug fixed : https://jbs.oracle.com/bugs/browse/JDK-8007736 >> >> Summary of changes : >> Java 8 allows public static interface methods. To accommodate >> for this, the proposed change modifies bytecode verification of Java >> 8 classfiles to allow invokestatic to refer to static interface >> methods in CONSTANT_InterfaceMethodref as well as static class >> methods in CONSTANT_Methodref. >> >> New test added : >> A new jtreg test in hotspot/test/runtime is added. >> >> Thanks, >> >> Bharadwaj >> From mandy.chung at oracle.com Wed Feb 13 19:02:02 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 13 Feb 2013 11:02:02 -0800 Subject: RFR (S) : JDK-8007736 - VerifyError for use of static method in interface In-Reply-To: <511BD5C9.2070300@oracle.com> References: <51159F10.70407@oracle.com> <5115ACCB.4020705@oracle.com> <5116329F.9040700@univ-mlv.fr> <5116D42F.4060402@oracle.com> <51190C81.4080200@oracle.com> <51198D50.2040002@oracle.com> <5119992A.9000203@oracle.com> <511B0C17.60803@oracle.com> <511BCD7E.5090600@oracle.com> <511BD5C9.2070300@oracle.com> Message-ID: <511BE32A.8060009@oracle.com> Thumbs up. Thanks for adding the regression test. Is there any test in jdk/test/ProblemList.txt excluded due to this bug? AFAIK no but just to double check. Thanks Mandy On 2/13/2013 10:04 AM, S. Bharadwaj Yadavalli wrote: > Mandy, > > Thanks for the review. > > I made the suggested changes and updated the webrev. > > Thanks, > > Bharadwaj > > On 2/13/2013 12:29 PM, Mandy Chung wrote: >> Bharadwaj, >> >> I'm including core-libs-dev so that they know this fix is coming. >> >>> http://cr.openjdk.java.net/~bharadwaj/8007736/jdk8-tl-jdk/webrev/ >> >> The jdk change looks okay to me. Minor nit: L1250-1251: some >> identation will help. You can follow the original formatting - >> breaking '?' and ':" in the newlines. >> >> Can you include the new regression test in the jdk repo as well >> (test/vm/verifier directory)? That'll make sure this test is run by >> core-libs and JPRT job (it's part of the default testset). >> >> Thanks >> Mandy >> >> On 2/12/2013 7:44 PM, S. Bharadwaj Yadavalli wrote: >>> On 2/12/2013 2:17 PM, Karen Kinnear wrote: >>>> Code looks good. I like this length of test too :-) >>> >>> Thanks for the review, Karen. >>> >>>> Please check -XX:-UseSplitVerifier to see if we also need to fix >>>> the old verifier for new >>>> classfiles. >>> >>> I checked with -XX:-UseSplitVerifier and found that I needed to fix >>> the old verifier. >>> >>> I updated the webrev with my changes which now need to be made to >>> jdk tree as well as hotspot tree. >>> The changes to hotspot tree remain the same as reviewed previously >>> by David Holmes, Krystal Mo and >>> Remi Forax. >>> >>> Please review the jdk tree changes (to the old verifier). >>> >>> Updated webrevs >>> hotspot-rt tree : >>> http://cr.openjdk.java.net/~bharadwaj/8007736/hotspot-rt/webrev >>> jdk8/tl/jdl tree : >>> http://cr.openjdk.java.net/~bharadwaj/8007736/jdk8-tl-jdk/webrev/ >>> >>> Bug fixed : https://jbs.oracle.com/bugs/browse/JDK-8007736 >>> >>> Summary of changes : >>> Java 8 allows public static interface methods. To accommodate >>> for this, the proposed change modifies bytecode verification of Java >>> 8 classfiles to allow invokestatic to refer to static interface >>> methods in CONSTANT_InterfaceMethodref as well as static class >>> methods in CONSTANT_Methodref. >>> >>> New test added : >>> A new jtreg test in hotspot/test/runtime is added. >>> >>> Thanks, >>> >>> Bharadwaj >>> > From xueming.shen at oracle.com Wed Feb 13 19:02:50 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 13 Feb 2013 11:02:50 -0800 Subject: [Review Request] 8008161: Regression: j.u.TimeZone.getAvailableIDs(rawOffset) returns non-sorted list Message-ID: <511BE35A.2000709@oracle.com> Hi, This is the "regression" triggered by my changeset 8007572: Replace existing jdk timezone data at /lib/zi with JSR310's tzdb. While the specification does not specify that the returned list from j.u.TimeZone.getAvailableIDs(rawOffset) should be sorted, this has been the implementation for years. It appears there are at least some tests may have dependency on this. Here is the webrev to restore the existing behavior. http://cr.openjdk.java.net/~sherman/8008161/webrev Please help review. Thanks! -Sherman From Lance.Andersen at oracle.com Wed Feb 13 19:09:40 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 13 Feb 2013 14:09:40 -0500 Subject: [Review Request] 8008161: Regression: j.u.TimeZone.getAvailableIDs(rawOffset) returns non-sorted list In-Reply-To: <511BE35A.2000709@oracle.com> References: <511BE35A.2000709@oracle.com> Message-ID: <1AA0C2C6-C5CE-4F00-80DB-6F275C981C09@oracle.com> +1 On Feb 13, 2013, at 2:02 PM, Xueming Shen wrote: > Hi, > > This is the "regression" triggered by my changeset > 8007572: Replace existing jdk timezone data at /lib/zi with JSR310's tzdb. > > While the specification does not specify that the returned list from > j.u.TimeZone.getAvailableIDs(rawOffset) should be sorted, this has > been the implementation for years. It appears there are at least some > tests may have dependency on this. > > Here is the webrev to restore the existing behavior. > > http://cr.openjdk.java.net/~sherman/8008161/webrev > > Please help review. > > Thanks! > -Sherman -------------- 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 vincent.x.ryan at oracle.com Wed Feb 13 19:42:10 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Wed, 13 Feb 2013 19:42:10 +0000 Subject: hg: jdk8/tl/jdk: 8007755: Support the logical grouping of keystores Message-ID: <20130213194232.73EDE47A36@hg.openjdk.java.net> Changeset: 11438befdd4c Author: vinnie Date: 2013-02-13 19:40 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11438befdd4c 8007755: Support the logical grouping of keystores Reviewed-by: mullan ! src/share/classes/java/security/KeyStore.java + src/share/classes/sun/security/provider/DomainKeyStore.java ! src/share/classes/sun/security/provider/PolicyParser.java ! src/share/classes/sun/security/provider/Sun.java ! src/share/classes/sun/security/provider/SunEntries.java ! src/share/classes/sun/security/util/Resources.java + test/sun/security/provider/KeyStore/DKSTest.java + test/sun/security/provider/KeyStore/DKSTest.sh + test/sun/security/provider/KeyStore/domains.cfg ! test/sun/security/tools/keytool/AltProviderPath.sh ! test/sun/security/tools/keytool/DummyProvider.java From xueming.shen at oracle.com Wed Feb 13 19:51:04 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 13 Feb 2013 19:51:04 +0000 Subject: hg: jdk8/tl/jdk: 8008161: Regression: j.u.TimeZone.getAvailableIDs(rawOffset) returns non-sorted list Message-ID: <20130213195117.CDB8747A38@hg.openjdk.java.net> Changeset: efc66fe16f91 Author: sherman Date: 2013-02-13 11:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/efc66fe16f91 8008161: Regression: j.u.TimeZone.getAvailableIDs(rawOffset) returns non-sorted list Summary: to return a sorted list Reviewed-by: lancea, naoto ! src/share/classes/sun/util/calendar/ZoneInfoFile.java ! test/sun/util/calendar/zi/TestZoneInfo310.java From lana.steuck at oracle.com Wed Feb 13 20:11:38 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 13 Feb 2013 20:11:38 +0000 Subject: hg: jdk8/tl: 9 new changesets Message-ID: <20130213201139.8AD2D47A39@hg.openjdk.java.net> Changeset: 6e296219633d Author: tbell Date: 2013-01-31 13:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6e296219633d 8006933: Need to use nawk on Solaris to avoid awk limitations Reviewed-by: erikj, dholmes, dsamersoff ! common/makefiles/IdlCompilation.gmk Changeset: 12782ec1da5f Author: ohrstrom Date: 2013-01-31 14:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/12782ec1da5f 8006872: Stop creating four jars with identical content in the new build system. Reviewed-by: erikj ! common/autoconf/spec.gmk.in ! common/makefiles/JavaCompilation.gmk ! common/makefiles/javadoc/Javadoc.gmk Changeset: 7e584be2ee58 Author: ohrstrom Date: 2013-02-01 11:22 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/7e584be2ee58 Merge Changeset: 339e4df096a2 Author: erikj Date: 2013-02-04 10:53 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/339e4df096a2 8007093: build-infra: Make should fail if spec is older than configure files Reviewed-by: tbell ! common/makefiles/Main.gmk Changeset: dea045cc48ca Author: erikj Date: 2013-02-04 11:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/dea045cc48ca 8007275: build-infra: Create final-images target Reviewed-by: tbell ! common/autoconf/generated-configure.sh ! common/makefiles/Jprt.gmk Changeset: d3d9ab8ee7b0 Author: erikj Date: 2013-02-05 16:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/d3d9ab8ee7b0 8007524: build-infra: Incremental build of tools.jar broken Reviewed-by: tbell ! common/makefiles/JavaCompilation.gmk Changeset: 278af9fc67e7 Author: katleman Date: 2013-02-05 18:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/278af9fc67e7 Merge Changeset: 3933eebc659d Author: katleman Date: 2013-02-07 12:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/3933eebc659d Added tag jdk8-b76 for changeset 278af9fc67e7 ! .hgtags Changeset: 76808fb4194a Author: lana Date: 2013-02-13 11:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/76808fb4194a Merge ! common/makefiles/Main.gmk From lana.steuck at oracle.com Wed Feb 13 20:11:38 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 13 Feb 2013 20:11:38 +0000 Subject: hg: jdk8/tl/corba: 3 new changesets Message-ID: <20130213201141.D1F8D47A3A@hg.openjdk.java.net> Changeset: ce106b6b7394 Author: ohrstrom Date: 2013-01-31 14:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/ce106b6b7394 8006872: Stop creating four jars with identical content in the new build system. Reviewed-by: erikj ! makefiles/BuildCorba.gmk Changeset: 58be6ca3c060 Author: katleman Date: 2013-02-05 18:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/58be6ca3c060 Merge Changeset: 35684a40c584 Author: katleman Date: 2013-02-07 12:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/35684a40c584 Added tag jdk8-b76 for changeset 58be6ca3c060 ! .hgtags From lana.steuck at oracle.com Wed Feb 13 20:11:43 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 13 Feb 2013 20:11:43 +0000 Subject: hg: jdk8/tl/jaxws: 3 new changesets Message-ID: <20130213201151.53CD647A3B@hg.openjdk.java.net> Changeset: 54beebb17494 Author: ohrstrom Date: 2013-01-31 14:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/54beebb17494 8006872: Stop creating four jars with identical content in the new build system. Reviewed-by: erikj ! makefiles/BuildJaxws.gmk Changeset: c4853f3f0e89 Author: katleman Date: 2013-02-05 18:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c4853f3f0e89 Merge Changeset: 64dfba1bad16 Author: katleman Date: 2013-02-07 12:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/64dfba1bad16 Added tag jdk8-b76 for changeset c4853f3f0e89 ! .hgtags From lana.steuck at oracle.com Wed Feb 13 20:11:43 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 13 Feb 2013 20:11:43 +0000 Subject: hg: jdk8/tl/jaxp: 4 new changesets Message-ID: <20130213201155.6354047A3C@hg.openjdk.java.net> Changeset: 8f6ca8755f46 Author: ohrstrom Date: 2013-01-31 14:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/8f6ca8755f46 8006872: Stop creating four jars with identical content in the new build system. Reviewed-by: erikj ! makefiles/BuildJaxp.gmk Changeset: 0c08593944d0 Author: katleman Date: 2013-02-05 18:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/0c08593944d0 Merge Changeset: 02195d0e96b9 Author: katleman Date: 2013-02-07 12:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/02195d0e96b9 Added tag jdk8-b76 for changeset 0c08593944d0 ! .hgtags Changeset: 573e789c187a Author: lana Date: 2013-02-11 16:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/573e789c187a Merge From lana.steuck at oracle.com Wed Feb 13 20:11:49 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 13 Feb 2013 20:11:49 +0000 Subject: hg: jdk8/tl/langtools: 5 new changesets Message-ID: <20130213201205.3D4A047A3D@hg.openjdk.java.net> Changeset: 2d6789a725a4 Author: ohrstrom Date: 2013-01-31 14:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2d6789a725a4 8006872: Stop creating four jars with identical content in the new build system. Reviewed-by: erikj ! makefiles/BuildLangtools.gmk Changeset: e81839b32337 Author: katleman Date: 2013-02-05 18:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e81839b32337 Merge Changeset: 6fde20398015 Author: katleman Date: 2013-02-07 12:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6fde20398015 Added tag jdk8-b76 for changeset e81839b32337 ! .hgtags Changeset: 89c664151689 Author: lana Date: 2013-02-11 16:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/89c664151689 Merge Changeset: 3f9875aa5d67 Author: lana Date: 2013-02-13 11:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3f9875aa5d67 Merge From lana.steuck at oracle.com Wed Feb 13 20:12:20 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 13 Feb 2013 20:12:20 +0000 Subject: hg: jdk8/tl/hotspot: 74 new changesets Message-ID: <20130213201507.A029A47A3E@hg.openjdk.java.net> Changeset: da53cb17186a Author: katleman Date: 2013-02-07 12:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/da53cb17186a Added tag jdk8-b76 for changeset 20b605466ccb ! .hgtags Changeset: 6fbe8a57549d Author: amurillo Date: 2013-01-25 03:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6fbe8a57549d 8006827: new hotspot build - hs25-b18 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 3c327c2b6782 Author: jmasa Date: 2013-01-03 15:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3c327c2b6782 8004895: NPG: JMapPermCore test failure caused by warnings about missing field Reviewed-by: johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/binaryTreeDictionary.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ef1e11845e18 Author: jmasa Date: 2013-02-04 12:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ef1e11845e18 Merge ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 5daaddd917a1 Author: coleenp Date: 2013-01-23 10:34 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5daaddd917a1 8006040: NPG: on_stack processing wastes space in ConstantPool Summary: Added on_stack bit to flags. Also MetadataMarkOnStack is used for more than JVMTI so had to be moved. Reviewed-by: dholmes, stefank ! src/share/vm/classfile/classLoaderData.cpp + src/share/vm/classfile/metadataOnStackMark.cpp + src/share/vm/classfile/metadataOnStackMark.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp Changeset: 6cf2530f7fd3 Author: minqi Date: 2013-01-24 23:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6cf2530f7fd3 8005278: Serviceability Agent: jmap -heap and jstack -m fail Summary: BinaryTreeDictionary is typedef'ed as AFLBinaryTreeDictionary in vmStructs and in SA we still use old name for that. FreeList now is a template based class which is not reflect in SA type library. When SA does calculation of heap for CMS, the former will cause failure to retrieve BinaryTreeDictionary sine the rename. The later will fail wherever it is used in SA. Reviewed-by: dholmes, sla, coleenp Contributed-by: yunda.mly at taobao.com + agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java - agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java ! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java ! agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp Changeset: 8b46b0196eb0 Author: zgu Date: 2013-01-25 10:04 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8b46b0196eb0 8000692: Remove old KERNEL code Summary: Removed depreciated kernel VM source code from hotspot VM Reviewed-by: dholmes, acorn ! make/Makefile ! make/bsd/makefiles/dtrace.make ! make/solaris/Makefile ! make/solaris/makefiles/dtrace.make - make/solaris/makefiles/kernel.make ! make/windows/build.bat ! make/windows/create_obj_files.sh ! make/windows/makefiles/defs.make ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/vm.make ! src/cpu/x86/vm/assembler_x86.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/prims/jniCheck.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiCodeBlobEvents.hpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExtensions.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/prims/jvmtiRawMonitor.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiTagMap.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/attachListener.hpp Changeset: edd76a5856f7 Author: sspitsyn Date: 2013-01-24 22:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/edd76a5856f7 8005128: JSR 292: the mlvm redefineClassInBootstrap test crashes in ConstantPool::compare_entry_to Summary: When constant pool is copied in merge_constant_pools the invokedynamic operands must be copied before. Reviewed-by: coleenp, twisti Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 4a0dd3799a44 Author: minqi Date: 2013-01-25 04:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4a0dd3799a44 Merge Changeset: 8d1fb417a42d Author: minqi Date: 2013-01-25 13:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8d1fb417a42d Merge ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: cf8470eaf7e5 Author: acorn Date: 2013-01-27 21:58 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cf8470eaf7e5 Merge - agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java - make/solaris/makefiles/kernel.make ! src/cpu/x86/vm/assembler_x86.hpp ! src/share/vm/classfile/vmSymbols.hpp Changeset: 16fb9f942703 Author: acorn Date: 2013-01-25 15:06 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/16fb9f942703 6479360: PrintClassHistogram improvements Summary: jcmd GC.class_stats (UnlockDiagnosticVMOptions) Reviewed-by: coleenp, hseigel, sla, acorn Contributed-by: ioi.lam at oracle.com ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/oops/annotations.cpp ! src/share/vm/oops/annotations.hpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.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/method.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp Changeset: 0d26ce8e9251 Author: acorn Date: 2013-01-28 10:34 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0d26ce8e9251 Merge - make/solaris/makefiles/kernel.make ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp Changeset: 815957d0203e Author: acorn Date: 2013-01-28 10:55 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/815957d0203e 8004967: Default method cause VerifyError: Illegal use of nonvirtual Summary: Recognize VM generated method in old verifier Reviewed-by: acorn, coleenp Contributed-by: bharadwaj.yadavelli at oracle.com ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: 7885e162c30f Author: acorn Date: 2013-01-28 09:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7885e162c30f Merge Changeset: 9be6cde7919d Author: ctornqvi Date: 2013-01-25 10:14 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9be6cde7919d 8006413: Add utility classes for writing better multiprocess tests in jtreg Summary: Add a few utility classes to test/testlibrary to support multi process testing in jtreg tests. Added a test case for one of the utility classes. Also reviewed by Vitaly Davidovich Reviewed-by: brutisso, dholmes, vlivanov, nloodin, mgerdin + test/testlibrary/OutputAnalyzerTest.java + test/testlibrary/com/oracle/java/testlibrary/JDKToolFinder.java + test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java + test/testlibrary/com/oracle/java/testlibrary/OutputBuffer.java + test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java + test/testlibrary/com/oracle/java/testlibrary/StreamPumper.java Changeset: baf7fac3167e Author: hseigel Date: 2013-02-01 14:14 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/baf7fac3167e 8006298: Specifying malformed JFR options (-XX:+FlightRecorderOptions) outputs non-sensical error Summary: Change error messages for malformed options so the messages are more useful. Reviewed-by: mikael, kvn, nloodin ! src/share/vm/runtime/arguments.cpp Changeset: 4c75576d18d0 Author: hseigel Date: 2013-02-01 13:30 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4c75576d18d0 Merge Changeset: 9bf5f643d1cf Author: sspitsyn Date: 2013-01-31 20:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9bf5f643d1cf 8006542: JSR 292: the VM_RedefineClasses::append_entry() must support invokedynamic entry kinds Summary: Need a support for invokedynamic entry kinds when new and old constant pools are merged. Reviewed-by: coleenp, twisti Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp Changeset: dc31f560d6e7 Author: sspitsyn Date: 2013-01-31 20:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dc31f560d6e7 8006546: JSR 292: typos in the ConstantPool::copy_cp_impl() Summary: Simple typos that need to be fixed Reviewed-by: coleenp, twisti Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/oops/constantPool.cpp Changeset: 79c1bb8fce5d Author: sspitsyn Date: 2013-01-31 20:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/79c1bb8fce5d 8006731: JSR 292: the VM_RedefineClasses::rewrite_cp_refs_in_method() must support invokedynamic Summary: The invokedynamic bytecode ref to a CP entry needs to be checked and fixed as well. Reviewed-by: coleenp, twisti Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 9a9f870325cf Author: minqi Date: 2013-02-01 10:57 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9a9f870325cf Merge Changeset: b935589d2807 Author: minqi Date: 2013-02-01 14:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b935589d2807 Merge Changeset: 44c5fcd9cb25 Author: iklam Date: 2013-01-24 10:57 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/44c5fcd9cb25 8006280: Need to reorder metadata structures to reduce size (64-bit) Summary: Reordered Klass, InstanceKlass and Method to save 8 bytes each Reviewed-by: coleenp, jiangli Contributed-by: ioi.lam at oracle.com ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.hpp Changeset: 1eae78177059 Author: jiangli Date: 2013-02-01 15:25 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1eae78177059 Merge - make/solaris/makefiles/kernel.make ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.hpp Changeset: dc8ad3fd7050 Author: jiangli Date: 2013-02-01 19:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dc8ad3fd7050 Merge Changeset: 4102b59539ce Author: ctornqvi Date: 2013-02-01 23:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4102b59539ce 8005012: Add WB APIs to better support NMT testing Summary: Add WB API functions to enable better NMT testing Reviewed-by: dholmes, zgu ! src/share/tools/whitebox/sun/hotspot/WhiteBox.java ! src/share/vm/memory/allocation.hpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memPtr.cpp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memRecorder.cpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memTrackWorker.cpp ! src/share/vm/services/memTrackWorker.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: 4460acf8687b Author: ctornqvi Date: 2013-02-02 07:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4460acf8687b Merge Changeset: 9fe95b01ad32 Author: ctornqvi Date: 2013-02-02 08:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9fe95b01ad32 Merge Changeset: 43badbe2717a Author: minqi Date: 2013-01-31 17:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/43badbe2717a 8000973: SA on windows thread inspection is broken Summary: After bug 7161732, On Windows SA could not find correct address of thread_id of OSThread since _thread_id moved to end of the class . The presupposition of the address is following thread handle no longer stands. Fix by adding thread_id field to OSThread and getting the address directly from OSThread. Reviewed-by: nloodin, sspitsyn Contributed-by: yumin.qi at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/amd64/WindbgAMD64Thread.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/x86/WindbgX86Thread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/OSThread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/win32_amd64/Win32AMD64JavaThreadPDAccess.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/win32_x86/Win32X86JavaThreadPDAccess.java Changeset: 65b632b77a97 Author: minqi Date: 2013-02-01 22:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/65b632b77a97 Merge Changeset: ff5401ad5635 Author: minqi Date: 2013-02-02 03:51 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ff5401ad5635 Merge Changeset: 879c6de913d6 Author: ctornqvi Date: 2013-02-02 16:34 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/879c6de913d6 8005013: Add NMT tests Summary: Add tests for the Native Memory Tracking feature, includes regression tests for 8005936 and 8004802 Reviewed-by: zgu, coleenp ! test/TEST.ROOT + test/runtime/NMT/AllocTestType.java + test/runtime/NMT/BaselineWithParameter.java + test/runtime/NMT/CommandLineDetail.java + test/runtime/NMT/CommandLineEmptyArgument.java + test/runtime/NMT/CommandLineInvalidArgument.java + test/runtime/NMT/CommandLineSummary.java + test/runtime/NMT/CommandLineTurnOffNMT.java + test/runtime/NMT/JcmdScale.java + test/runtime/NMT/JcmdWithNMTDisabled.java + test/runtime/NMT/PrintNMTStatistics.java + test/runtime/NMT/PrintNMTStatisticsWithNMTDisabled.java + test/runtime/NMT/ShutdownTwice.java + test/runtime/NMT/SummaryAfterShutdown.java + test/runtime/NMT/SummarySanityCheck.java Changeset: a7f9a1195d86 Author: ctornqvi Date: 2013-02-02 20:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a7f9a1195d86 8000363: runtime/7158988/FieldMonitor.java fails with exception Summary: Removed unnecessary shell script in the test. Reviewed-by: coleenp, sla ! test/runtime/7158988/FieldMonitor.java - test/runtime/7158988/TestFieldMonitor.sh Changeset: 8f696cf1a0fb Author: dsamersoff Date: 2013-02-03 22:28 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8f696cf1a0fb 8002048: Protocol to discovery of manageable Java processes on a network Summary: Introduce a protocol to discover manageble Java instances across a network subnet, JDP Reviewed-by: sla, dfuchs ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp Changeset: c4ef3380a70b Author: hseigel Date: 2013-02-03 16:49 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c4ef3380a70b 7197672: There are issues with shared data on windows Summary: On Windows, set rw protection on the CDS file just before removing it. Reviewed-by: dcubed, iklam ! src/share/vm/memory/filemap.cpp Changeset: ce5467120c84 Author: hseigel Date: 2013-02-03 17:12 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ce5467120c84 Merge Changeset: 10d5f25a7c67 Author: hseigel Date: 2013-02-04 08:26 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/10d5f25a7c67 8000968: NPG: UseCompressedKlassPointers asserts with ObjectAlignmentInBytes for > 32G CompressedOops Summary: Pick a base that works for both CompressedOpps alignment and CompressedKlassPtrs alignment. Reviewed-by: kvn, roland ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/runtime/arguments.cpp + test/runtime/8000968/Test8000968.sh Changeset: 24a91505f9d5 Author: emc Date: 2013-02-04 13:05 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/24a91505f9d5 8006949: Update hotspot for MethodParameters format change 8006907: Hotspot should reject classfiles with multiple MethodParameters attributes Summary: Update to Hotspot's processing of MethodParameters attributes in classfiles Reviewed-by: coleenp, jrose ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/prims/jvm.cpp Changeset: 42ea5e1fad75 Author: coleenp Date: 2013-02-04 13:51 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/42ea5e1fad75 Merge Changeset: ab826603e572 Author: simonis Date: 2013-02-04 13:14 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ab826603e572 8007475: Memory stomp with UseMallocOnly Summary: Fix off-by-one error Reviewed-by: coleenp, hseigel ! src/share/vm/classfile/stackMapFrame.hpp + test/runtime/8007475/StackMapFrameTest.java Changeset: a401757763f9 Author: coleenp Date: 2013-02-04 22:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a401757763f9 Merge Changeset: 12285410684f Author: dholmes Date: 2013-02-04 23:53 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/12285410684f 8006508: Wrong frame constructor is called in os_linux_x86.cpp Reviewed-by: dholmes, coleenp Contributed-by: Jeremy Manson ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp Changeset: f3ea1af9207a Author: dholmes Date: 2013-02-05 00:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f3ea1af9207a Merge Changeset: 454d7cc622ab Author: dcubed Date: 2013-02-06 15:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/454d7cc622ab Merge - agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java - make/solaris/makefiles/kernel.make ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp - test/runtime/7158988/TestFieldMonitor.sh Changeset: fcc9e7681d63 Author: vlivanov Date: 2013-02-01 02:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fcc9e7681d63 8006410: allocating without ResourceMark when CompileCommand was specified Reviewed-by: kvn, vlivanov Contributed-by: Igor Ignatyev ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/oops/symbol.cpp Changeset: 60bba1398c51 Author: vlivanov Date: 2013-02-01 03:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/60bba1398c51 8005439: no message about inline method if it specifed by CompileCommand Reviewed-by: kvn, vlivanov Contributed-by: Igor Ignatyev ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/parse.hpp Changeset: e4bb0bda20a4 Author: morris Date: 2013-01-25 16:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e4bb0bda20a4 8005811: Turn off TierdCompilation in JDK8 trunk for all platforms Summary: Disable tiered compilation in jdk8 because of CodeCache and performance anomalies Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp Changeset: 76341426b645 Author: drchase Date: 2013-01-25 16:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/76341426b645 8006500: compiler/8004741/Test8004741.java fails intermediately Summary: rewrote the test to be more reliable, add test for invalid size exception Reviewed-by: kvn ! test/compiler/8004741/Test8004741.java Changeset: 9fae07c31641 Author: morris Date: 2013-01-25 16:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9fae07c31641 6518907: cleanup IA64 specific code in Hotspot Summary: removed unused IA64 specific code Reviewed-by: twisti, kvn, dholmes ! agent/src/os/linux/LinuxDebuggerLocal.c ! agent/src/os/linux/libproc.h ! agent/src/os/win32/windbg/sawindbg.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/opto/generateOptoStub.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/vframeArray.cpp Changeset: 37c18711a0df Author: roland Date: 2013-02-04 09:11 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/37c18711a0df 8005114: VM is crashing in ciKlass*ciObjArrayKlass::element_klass() if metaspaces are full Summary: missing test for loaded klass in c1 Reviewed-by: kvn ! src/share/vm/c1/c1_Instruction.cpp Changeset: 39901f2f1abe Author: mikael Date: 2013-02-04 10:28 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/39901f2f1abe 8007403: Incorrect format arguments in adlparse.cpp Reviewed-by: kvn, twisti ! src/share/vm/adlc/adlparse.cpp Changeset: 8bd61471a109 Author: roland Date: 2013-02-04 11:30 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8bd61471a109 8007144: Incremental inlining mistakes some call sites for dead ones and doesn't inline them Summary: wrong detection for dead call sites. Reviewed-by: kvn ! src/share/vm/opto/callGenerator.cpp Changeset: 6a51fc70a15e Author: vlivanov Date: 2013-02-05 08:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6a51fc70a15e 8006613: adding reason to made_not_compilable Reviewed-by: kvn, vlivanov Contributed-by: Igor Ignatyev ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/runtime/deoptimization.cpp Changeset: 4fcf990aa34a Author: drchase Date: 2013-02-06 11:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4fcf990aa34a 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray Summary: check ndimensions before accessing length[i] element Reviewed-by: kvn Contributed-by: volker.simonis at gmail.com ! src/share/vm/opto/parse3.cpp Changeset: d05ff4bf41b3 Author: vlivanov Date: 2013-02-07 12:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d05ff4bf41b3 Merge ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/methodData.hpp Changeset: db9981fd3124 Author: jprovino Date: 2013-01-23 13:02 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/db9981fd3124 8005915: Unify SERIALGC and INCLUDE_ALTERNATE_GCS Summary: Rename INCLUDE_ALTERNATE_GCS to INCLUDE_ALL_GCS and replace SERIALGC with INCLUDE_ALL_GCS. Reviewed-by: coleenp, stefank ! make/bsd/makefiles/minimal1.make ! make/excludeSrc.make ! make/linux/makefiles/minimal1.make ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/zero/vm/assembler_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/shared/allocationStats.cpp ! src/share/vm/gc_implementation/shared/allocationStats.hpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.hpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.cpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/gcAdaptivePolicyCounters.hpp ! src/share/vm/gc_implementation/shared/hSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/immutableSpace.cpp ! src/share/vm/gc_implementation/shared/isGCActiveMark.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/gc_implementation/shared/spaceCounters.cpp ! src/share/vm/gc_implementation/shared/spaceCounters.hpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/freeList.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/generationSpec.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/specialized_oop_closures.hpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/memory/tenuredGeneration.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceClassLoaderKlass.cpp ! src/share/vm/oops/instanceClassLoaderKlass.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceMirrorKlass.cpp ! src/share/vm/oops/instanceMirrorKlass.hpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/instanceRefKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassPS.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/oops/objArrayKlass.inline.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oop.pcgc.inline.hpp ! src/share/vm/oops/oop.psgc.inline.hpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/classLoadingService.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp ! src/share/vm/services/g1MemoryPool.hpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/memReporter.hpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/psMemoryPool.hpp ! src/share/vm/services/runtimeService.cpp ! src/share/vm/utilities/macros.hpp ! src/share/vm/utilities/top.hpp ! src/share/vm/utilities/yieldingWorkgroup.cpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: 8391fdd36e1f Author: dlong Date: 2013-01-27 01:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8391fdd36e1f Merge ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/heapDumper.cpp Changeset: 3c9bc17b9403 Author: bpittore Date: 2013-02-07 16:05 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3c9bc17b9403 Merge ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/universe.cpp ! 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/oop.inline.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp Changeset: df8462fbe585 Author: vladidan Date: 2013-02-07 20:40 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/df8462fbe585 Merge ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: ec0c4951286c Author: stefank Date: 2013-01-29 10:51 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ec0c4951286c 8004710: NPG: jmap could throw sun.jvm.hotspot.types.WrongTypeException after PermGen removal Summary: When calculating live object regions, make sure that the alignment reserve, at the end of a TLAB, is excluded. Reviewed-by: jmasa, brutisso ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/share/vm/runtime/vmStructs.cpp Changeset: 4700e77d44c1 Author: johnc Date: 2013-02-01 13:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4700e77d44c1 8006894: G1: Number of marking threads missing from PrintFlagsFinal output Summary: Set ConcGCThreads to the calculated number of marking threads. Reviewed-by: jmasa, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: d9058e388631 Author: mikael Date: 2013-02-01 17:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d9058e388631 8007257: NPG: metaspace.cpp: Incorrect arguments in calls to err_msg Summary: Fix size checks in assert and corrected some print formats. Also reviewed by vitalyd at gmail.com. Reviewed-by: coleenp, sspitsyn ! src/share/vm/memory/metaspace.cpp Changeset: 256d3f43c177 Author: johnc Date: 2013-01-31 10:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/256d3f43c177 8005875: G1: Kitchensink fails with ParallelGCThreads=0 Summary: Check that the concurrent marking worker gang exists in ConcurrentMark::print_worker_threads_on(). Changes were also reviewed by Vitaly Davidovich . Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp Changeset: 80518f4ecf32 Author: jmasa Date: 2013-02-04 12:51 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/80518f4ecf32 Merge ! src/share/vm/runtime/vmStructs.cpp Changeset: f2f0cf0f5444 Author: jmasa Date: 2013-02-04 13:26 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f2f0cf0f5444 Merge Changeset: 06fd03af6ce4 Author: johnc Date: 2013-02-04 13:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/06fd03af6ce4 8001384: G1: assert(!is_null(v)) failed: narrow oop value can never be zero Summary: Flush any deferred card mark before a Java thread exits. Reviewed-by: brutisso, jmasa ! src/share/vm/runtime/thread.cpp Changeset: 84304a77c4e3 Author: johnc Date: 2013-02-04 19:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/84304a77c4e3 Merge Changeset: 95ccff9eee8e Author: jwilhelm Date: 2013-01-28 15:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/95ccff9eee8e 6348447: Specifying -XX:OldSize crashes 64-bit VMs Summary: Heap size will be set to allow for OldSize to fit. Also reviewed by vitalyd at gmail.com Reviewed-by: ehelin, jmasa ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp Changeset: f90b9bceb8e5 Author: johnc Date: 2013-02-05 09:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f90b9bceb8e5 8005032: G1: Cleanup serial reference processing closures in concurrent marking Summary: Reuse the parallel reference processing oop closures during serial reference processing. Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp Changeset: 50d3b37d5bcd Author: johnc Date: 2013-02-05 22:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/50d3b37d5bcd Merge Changeset: 1135141fb97e Author: brutisso Date: 2013-02-08 10:08 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1135141fb97e Merge ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 412d722168bc Author: amurillo Date: 2013-02-08 08:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/412d722168bc Merge - agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java - make/solaris/makefiles/kernel.make - test/runtime/7158988/TestFieldMonitor.sh Changeset: cdb46031e718 Author: amurillo Date: 2013-02-08 08:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cdb46031e718 Added tag hs25-b18 for changeset 412d722168bc ! .hgtags From lana.steuck at oracle.com Wed Feb 13 20:12:29 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 13 Feb 2013 20:12:29 +0000 Subject: hg: jdk8/tl/jdk: 17 new changesets Message-ID: <20130213201754.188E447A3F@hg.openjdk.java.net> Changeset: c5a7ac2a721f Author: ohrstrom Date: 2013-01-31 14:03 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c5a7ac2a721f 8006872: Stop creating four jars with identical content in the new build system. Reviewed-by: erikj ! makefiles/CreateJars.gmk ! makefiles/GensrcSwing.gmk ! makefiles/Setup.gmk Changeset: 35cf77f633c9 Author: tbell Date: 2013-02-01 09:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/35cf77f633c9 8006808: mapfile use check in jdk/make/common/shared/Defs-solaris.gmk is throwing 'egrep: syntax error' Summary: Use a valid egrep expression in the non-SPARC case Reviewed-by: dholmes ! make/common/shared/Defs-solaris.gmk Changeset: 5692ebe15321 Author: erikj Date: 2013-02-04 10:58 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5692ebe15321 8007268: build-infra: configure reports Solaris needs gcc for deploy, but logs don't indicate it's used. Reviewed-by: tbell, katleman ! make/common/shared/Sanity.gmk Changeset: 3a2630528661 Author: katleman Date: 2013-02-05 18:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3a2630528661 Merge Changeset: 933742f4bb4c Author: katleman Date: 2013-02-07 12:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/933742f4bb4c Added tag jdk8-b76 for changeset 3a2630528661 ! .hgtags Changeset: e63e7ee18412 Author: bae Date: 2013-02-01 20:06 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e63e7ee18412 8004801: The image of BufferedImage.TYPE_INT_ARGB is blank. Reviewed-by: prr ! src/share/native/sun/awt/image/awt_parseImage.c ! src/solaris/native/sun/awt/awt_Mlib.c ! src/solaris/native/sun/awt/awt_Mlib.h ! src/windows/native/sun/windows/awt_Mlib.cpp ! src/windows/native/sun/windows/awt_Mlib.h + test/java/awt/image/LookupOp/IntImageReverseTest.java Changeset: 1df2944db538 Author: serb Date: 2013-02-04 19:50 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1df2944db538 8004821: Graphics2D.drawPolygon() fails with IllegalPathStateException Reviewed-by: prr, flar ! src/share/classes/sun/java2d/pipe/PixelToShapeConverter.java + test/sun/java2d/pipe/Test8004821.java Changeset: 8fc3e4015b09 Author: jgodinez Date: 2013-02-04 12:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8fc3e4015b09 8005052: [parfait] #416 X11SurfaceData.c UNINITIALISED OR MISSING RETURN VALUE 8005054: [parfait] #417 X11SurfaceData.c UNINITIALISED OR MISSING RETURN VALUE Reviewed-by: prr, vadim Contributed-by: jia-hong.chen at oracle.com ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c Changeset: fd61fcc1a5a9 Author: leonidr Date: 2013-01-31 18:25 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fd61fcc1a5a9 8007006: [macosx] Closing subwindow loses main window menus Reviewed-by: anthony ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 452deb976c92 Author: ptbrunet Date: 2013-01-31 18:51 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/452deb976c92 7179482: Component.accessibleContext and JComponent.accessibleContext refactoring Reviewed-by: art, anthony, alexsch ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/javax/swing/JComponent.java Changeset: 0b56a169295f Author: pchelko Date: 2013-02-04 13:54 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0b56a169295f 8005405: [macosx] Drag and Drop: wrong animation when dropped outside any drop target. Summary: Changed the calculation of the drag image offset Reviewed-by: serb, kizune ! src/macosx/classes/sun/lwawt/macosx/CDragSourceContextPeer.java ! src/macosx/native/sun/awt/CDragSource.m Changeset: 171443b1eb3b Author: kshefov Date: 2013-02-04 16:01 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/171443b1eb3b 7077259: [TEST_BUG] [macosx] Test work correctly only when default L&F is Metal Reviewed-by: serb, alexsch ! test/javax/swing/JSlider/4252173/bug4252173.java ! test/javax/swing/JSpinner/6532833/bug6532833.java ! test/javax/swing/plaf/metal/MetalSliderUI/Test6657026.java Changeset: 0e929be3a9da Author: lana Date: 2013-02-05 11:10 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0e929be3a9da Merge Changeset: f26b539bf1d5 Author: lana Date: 2013-02-05 11:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f26b539bf1d5 Merge - src/share/classes/java/lang/annotation/ContainedBy.java - src/share/classes/java/lang/annotation/ContainerFor.java - test/java/net/URL/abnormal_http_urls - test/java/net/URL/ftp_urls - test/java/net/URL/jar_urls - test/java/net/URL/normal_http_urls - test/java/net/URL/runconstructor.sh - test/java/net/URL/share_file_urls - test/java/net/URL/win32_file_urls - test/sun/net/www/EncDec.doc - test/sun/net/www/MarkResetTest.java - test/sun/net/www/MarkResetTest.sh - test/sun/security/util/Oid/S11N.sh - test/sun/security/util/Oid/SerialTest.java Changeset: b2fc8e31cecc Author: lana Date: 2013-02-11 16:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b2fc8e31cecc Merge - src/share/classes/java/lang/annotation/ContainedBy.java - src/share/classes/java/lang/annotation/ContainerFor.java - test/java/net/URL/abnormal_http_urls - test/java/net/URL/ftp_urls - test/java/net/URL/jar_urls - test/java/net/URL/normal_http_urls - test/java/net/URL/runconstructor.sh - test/java/net/URL/share_file_urls - test/java/net/URL/win32_file_urls - test/sun/net/www/EncDec.doc - test/sun/net/www/MarkResetTest.java - test/sun/net/www/MarkResetTest.sh - test/sun/security/util/Oid/S11N.sh - test/sun/security/util/Oid/SerialTest.java Changeset: ff80a6b2ae9b Author: lana Date: 2013-02-13 11:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff80a6b2ae9b Merge Changeset: a5aad284904e Author: lana Date: 2013-02-13 11:57 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a5aad284904e Merge From mike.duigou at oracle.com Wed Feb 13 20:21:48 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 13 Feb 2013 12:21:48 -0800 Subject: IdentityHashMap.[keySet|values|entrySet].toArray speed-up In-Reply-To: <50C8494E.5030402@gmail.com> References: <50C8494E.5030402@gmail.com> Message-ID: This looks like excellent contribution Peter! I will proceed with the testing needed to integrate your improved toArray()/toArray(T[]) implementations. I have created an issue, JDK-8008167, for this patch. I am surprised that this didn't get more attention back in December as it does seem to offer significant benefits for size and performance. Thanks, Mike On Dec 12 2012, at 01:07 , Peter Levart wrote: > Hi all, > > I propose a patch to java.util.IdentityHashMap to speed-up toArray methods of it's keySet, values and entrySet views: > > http://dl.dropbox.com/u/101777488/jdk8-tl/IdentityHashMap/webrev.01/index.html > > I toyed with the possibility to replace HashMap-s, that are used in java.lang.Class and java.lang.reflect.[Field|Method|Constructor] to hold cached annotations, with IdentityHashMap-s. They are a perfect replacement, since keys in these maps are java.lang.Class objects. > > They are more compact then HashMap-s. This is the comparison of allocated heap bytes between HashMap and IdentityHashMap for various sizes and corresponding capacities which takes into account the size of the Map object, the size of allocated array and the size of Map.Entry-s in case of HM (IHM doesn't have them) and the size of associated values Collection view (allocated when dumping annotations to array). HM-s for annotations are currently allocated with default initial capacity (16). I propose to allocate IHM-s with initial capacity 8 that fits to hold 5 entries which is enough for typical annotation use cases on one hand and still makes improvement for any case on the other: > > 32 bit JVM: > > | HashMap | IdentityHashMap | > size|capacity bytes|capacity bytes|IHM.bytes-HM.bytes > --------+-----------------+-----------------+------------------ > 0| 16 144| 8 136| -8 > 1| 16 168| 8 136| -32 > 2| 16 192| 8 136| -56 > 3| 16 216| 8 136| -80 > 4| 16 240| 8 136| -104 > 5| 16 264| 8 136| -128 > 6| 16 288| 16 200| -88 > 7| 16 312| 16 200| -112 > 8| 16 336| 16 200| -136 > 9| 16 360| 16 200| -160 > 10| 16 384| 16 200| -184 > 11| 16 408| 16 200| -208 > 12| 16 432| 32 328| -104 > 13| 32 520| 32 328| -192 > 14| 32 544| 32 328| -216 > 15| 32 568| 32 328| -240 > 16| 32 592| 32 328| -264 > 17| 32 616| 32 328| -288 > 18| 32 640| 32 328| -312 > 19| 32 664| 32 328| -336 > 20| 32 688| 32 328| -360 > 40| 64 1296| 64 584| -712 > 60| 128 2032| 128 1096| -936 > 80| 128 2512| 128 1096| -1416 > 100| 256 3504| 256 2120| -1384 > 120| 256 3984| 256 2120| -1864 > 140| 256 4464| 256 2120| -2344 > 160| 256 4944| 256 2120| -2824 > 180| 256 5424| 512 4168| -1256 > > 64 bit JVM: > > | HashMap | IdentityHashMap | > size|capacity bytes|capacity bytes|IHM.bytes-HM.bytes > --------+-----------------+-----------------+------------------ > 0| 16 248| 8 240| -8 > 1| 16 296| 8 240| -56 > 2| 16 344| 8 240| -104 > 3| 16 392| 8 240| -152 > 4| 16 440| 8 240| -200 > 5| 16 488| 8 240| -248 > 6| 16 536| 16 368| -168 > 7| 16 584| 16 368| -216 > 8| 16 632| 16 368| -264 > 9| 16 680| 16 368| -312 > 10| 16 728| 16 368| -360 > 11| 16 776| 16 368| -408 > 12| 16 824| 32 624| -200 > 13| 32 1000| 32 624| -376 > 14| 32 1048| 32 624| -424 > 15| 32 1096| 32 624| -472 > 16| 32 1144| 32 624| -520 > 17| 32 1192| 32 624| -568 > 18| 32 1240| 32 624| -616 > 19| 32 1288| 32 624| -664 > 20| 32 1336| 32 624| -712 > 40| 64 2552| 64 1136| -1416 > 60| 128 4024| 128 2160| -1864 > 80| 128 4984| 128 2160| -2824 > 100| 256 6968| 256 4208| -2760 > 120| 256 7928| 256 4208| -3720 > 140| 256 8888| 256 4208| -4680 > 160| 256 9848| 256 4208| -5640 > 180| 256 10808| 512 8304| -2504 > > I hope I've got that tables right. This is the program to compute them: > > https://raw.github.com/plevart/jdk8-tl/JEP-149.2/test/src/test/IHMvsHMsizes.java > > IHM is also more performant when retrieving the values by keys. The only area in which it lags behind HashMap and is important for accessing annotations in bulk is the toArray method of the values view. In particular for small sizes. The above patch speeds-up those methods by using index iteration instead of Iterator. > > Here are some speed-up comparisons: > > https://raw.github.com/plevart/jdk8-tl/JEP-149.2/test/IHM_benchmark_results_i7-2600K.txt > > They are obtained by running the following micro benchmark: > > https://raw.github.com/plevart/jdk8-tl/JEP-149.2/test/src/test/IdentityHashMapTest.java > > Even if IHM doesn't replace HM for holding annotations, a speed-up improvement is an improvement. > > > Regards, Peter > From martinrb at google.com Wed Feb 13 20:47:12 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 13 Feb 2013 12:47:12 -0800 Subject: IdentityHashMap.[keySet|values|entrySet].toArray speed-up In-Reply-To: <50C8494E.5030402@gmail.com> References: <50C8494E.5030402@gmail.com> Message-ID: Seems pretty good overall. Thanks for doing this. Style: put your open braces at the end of the line. --- + int si = 0; + while (si < tab.length) { why not the more readable: for (int i = 0, len = tab.length; i < len; i += 2) { Object key = tab[i]; if (key != null) { ... From kumar.x.srinivasan at oracle.com Wed Feb 13 21:04:06 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Wed, 13 Feb 2013 21:04:06 +0000 Subject: hg: jdk8/tl/jdk: 8005750: [parfait] Memory leak at jdk/src/share/bin/parse_manifest.c Message-ID: <20130213210430.BEEF847A44@hg.openjdk.java.net> Changeset: 83c09292f5ad Author: ksrini Date: 2013-02-13 12:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/83c09292f5ad 8005750: [parfait] Memory leak at jdk/src/share/bin/parse_manifest.c Reviewed-by: jjh ! src/share/bin/parse_manifest.c From daniel.daugherty at oracle.com Wed Feb 13 21:23:16 2013 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Wed, 13 Feb 2013 21:23:16 +0000 Subject: hg: jdk8/tl/jdk: 8007935: java/lang/instrument/RedefineSubclassWithTwoInterfaces.sh should use $COMPILEJAVA for javac Message-ID: <20130213212336.BAB1B47A4B@hg.openjdk.java.net> Changeset: b13247d5408d Author: dcubed Date: 2013-02-13 13:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b13247d5408d 8007935: java/lang/instrument/RedefineSubclassWithTwoInterfaces.sh should use $COMPILEJAVA for javac Reviewed-by: sspitsyn, alanb ! test/java/lang/instrument/RedefineSubclassWithTwoInterfaces.sh From karen.kinnear at oracle.com Wed Feb 13 21:33:42 2013 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Wed, 13 Feb 2013 21:33:42 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130213213406.00F8047A4C@hg.openjdk.java.net> Changeset: 4f520ce7ba3f Author: acorn Date: 2013-02-13 16:09 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4f520ce7ba3f 8007888: jdk fix default method: VerifyError: Illegal use of nonvirtual Summary: Recognize VM generated method in old verifier. With 8004967 Reviewed-by: coleenp, acorn Contributed-by: bharadwaj.yadavalli at oracle.com ! src/share/javavm/export/jvm.h ! src/share/native/common/check_code.c Changeset: e6f34051c60c Author: acorn Date: 2013-02-13 16:15 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e6f34051c60c Merge From mike.duigou at oracle.com Wed Feb 13 22:45:30 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 13 Feb 2013 14:45:30 -0800 Subject: RFR (S) CR 8006627/8007398: Improve performance of Long.toUnsignedString0, Integer.toUnsignedString0, UUID(String) and UUID.toString In-Reply-To: <511AF9B2.6060601@CoSoCo.de> 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> Message-ID: <0D2150A5-DF5A-41CF-8405-C7D19959F3EC@oracle.com> 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/ 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 masayoshi.okutsu at oracle.com Wed Feb 13 23:46:44 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 14 Feb 2013 08:46:44 +0900 Subject: [Review Request] 8008161: Regression: j.u.TimeZone.getAvailableIDs(rawOffset) returns non-sorted list In-Reply-To: <511BE35A.2000709@oracle.com> References: <511BE35A.2000709@oracle.com> Message-ID: <511C25E4.407@oracle.com> The change is fine. But it's neither the spec nor guaranteed in the previous implementation to return a sorted list. The caller needed to sort the return value if a sorted list is required. Masayoshi On 2/14/2013 4:02 AM, Xueming Shen wrote: > Hi, > > This is the "regression" triggered by my changeset > 8007572: Replace existing jdk timezone data at /lib/zi with > JSR310's tzdb. > > While the specification does not specify that the returned list from > j.u.TimeZone.getAvailableIDs(rawOffset) should be sorted, this has > been the implementation for years. It appears there are at least some > tests may have dependency on this. > > Here is the webrev to restore the existing behavior. > > http://cr.openjdk.java.net/~sherman/8008161/webrev > > Please help review. > > Thanks! > -Sherman From martinrb at google.com Thu Feb 14 01:14:40 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 13 Feb 2013 17:14:40 -0800 Subject: Define JNIEXPORT as visibility default with GCC? In-Reply-To: References: Message-ID: This seems like an obvious improvement. There are already bunches of places in the jdk sources that do things like: ./hotspot/src/cpu/x86/vm/jni_x86.h #if defined(SOLARIS) || defined(LINUX) || defined(_ALLBSD_SOURCE) #if defined(__GNUC__) && (__GNUC__ > 4) || (__GNUC__ == 4) && (__GNUC_MINOR__ > 2) #define JNIEXPORT __attribute__((visibility("default"))) #define JNIIMPORT __attribute__((visibility("default"))) #else #define JNIEXPORT #define JNIIMPORT #endif This is *crazy*. The visibility feature has nothing to do with x86, or SOLARIS, or LINUX, or BSD. JNIEXPORT should be defined to __attribute__((visibility("default"))) #if #and #only #if: defined(__GNUC__) && (__GNUC__ > 4) || (__GNUC__ == 4) && (__GNUC_MINOR__ > 2) and that change should simply be made to the public exported jdk jni headers Martin On Mon, Feb 11, 2013 at 10:26 AM, Jeremy Manson wrote: > Hi folks, > > Pardon if this has come up before; a quick search didn't indicate > anything, but the mailing list archives are kind of hard to search. > > I wonder if it makes sense to define JNIEXPORT as meaning __attribute__ > ((visibility ("default"))) when compiling with gcc. Currently, anyone > building JNI code with -fvisibility=hidden and a stock Oracle JDK is at a > loss: their JNI exports will be hidden along with everything else. > > I notice that both IcedTea and OS X have made this change independently, > and it has been added to Hotspot's JNIEXPORT definition (so HS can be built > with -fvisibility=hidden), but the change isn't present in the latest JDK8 > bits: > > > http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/933742f4bb4c/src/solaris/javavm/export/jni_md.h > > The workaround is pretty ugly: people who want to use -fvisibility=hidden > have to redefine JNIEXPORT. Upstream, it would be a pretty simple change > to jni_md.h, along the lines of: > > #if defined(__GNUC__) && __GNUC__ >= 4 > #define JNIEXPORT __attribute__ ((visibility ("default"))) > #else > #define JNIEXPORT > #endif > > Any thoughts? > > Jeremy > From martinrb at google.com Thu Feb 14 01:32:40 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 13 Feb 2013 17:32:40 -0800 Subject: Define JNIEXPORT as visibility default with GCC? In-Reply-To: References: Message-ID: So, here's an obvious patch. Any reason not to do this? (although we can do even better, as always) http://cr.openjdk.java.net/~martin/webrevs/openjdk8/JNIEXPORT/ # HG changeset patch # User martin # Date 1360805180 28800 # Node ID 0d31e5e0a2c8e4a40c669a6c1c59530aa5f705bb # Parent 397424fe9fb52dd622af409ed2e3f1fc3463ee8d 6666666: JNIEXPORT should use gcc visibility "default" Summary: Define JNIEXPORT diff --git a/src/solaris/javavm/export/jni_md.h b/src/solaris/javavm/export/jni_md.h --- a/src/solaris/javavm/export/jni_md.h +++ b/src/solaris/javavm/export/jni_md.h @@ -26,8 +26,14 @@ #ifndef _JAVASOFT_JNI_MD_H_ #define _JAVASOFT_JNI_MD_H_ -#define JNIEXPORT -#define JNIIMPORT +#if defined(__GNUC__) && (__GNUC__ > 4) || (__GNUC__ == 4) && (__GNUC_MINOR__ > 2) + #define JNIEXPORT __attribute__((visibility("default"))) + #define JNIIMPORT __attribute__((visibility("default"))) +#else + #define JNIEXPORT + #define JNIIMPORT +#endif + #define JNICALL typedef int jint; On Wed, Feb 13, 2013 at 5:14 PM, Martin Buchholz wrote: > This seems like an obvious improvement. > There are already bunches of places in the jdk sources that do things like: > > ./hotspot/src/cpu/x86/vm/jni_x86.h > #if defined(SOLARIS) || defined(LINUX) || defined(_ALLBSD_SOURCE) > > #if defined(__GNUC__) && (__GNUC__ > 4) || (__GNUC__ == 4) && > (__GNUC_MINOR__ > 2) > #define JNIEXPORT __attribute__((visibility("default"))) > #define JNIIMPORT __attribute__((visibility("default"))) > #else > #define JNIEXPORT > #define JNIIMPORT > #endif > > This is *crazy*. The visibility feature has nothing to do with x86, or > SOLARIS, or LINUX, or BSD. > JNIEXPORT should be defined to __attribute__((visibility("default"))) > #if #and #only #if: > defined(__GNUC__) && (__GNUC__ > 4) || (__GNUC__ == 4) && (__GNUC_MINOR__ > > 2) > > and that change should simply be made to the public exported jdk jni > headers > > Martin > > On Mon, Feb 11, 2013 at 10:26 AM, Jeremy Manson wrote: > >> Hi folks, >> >> Pardon if this has come up before; a quick search didn't indicate >> anything, but the mailing list archives are kind of hard to search. >> >> I wonder if it makes sense to define JNIEXPORT as meaning __attribute__ >> ((visibility ("default"))) when compiling with gcc. Currently, anyone >> building JNI code with -fvisibility=hidden and a stock Oracle JDK is at a >> loss: their JNI exports will be hidden along with everything else. >> >> I notice that both IcedTea and OS X have made this change independently, >> and it has been added to Hotspot's JNIEXPORT definition (so HS can be built >> with -fvisibility=hidden), but the change isn't present in the latest JDK8 >> bits: >> >> >> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/933742f4bb4c/src/solaris/javavm/export/jni_md.h >> >> The workaround is pretty ugly: people who want to use -fvisibility=hidden >> have to redefine JNIEXPORT. Upstream, it would be a pretty simple change >> to jni_md.h, along the lines of: >> >> #if defined(__GNUC__) && __GNUC__ >= 4 >> #define JNIEXPORT __attribute__ ((visibility ("default"))) >> #else >> #define JNIEXPORT >> #endif >> >> Any thoughts? >> >> Jeremy >> > > From mandy.chung at oracle.com Thu Feb 14 01:52:37 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 13 Feb 2013 17:52:37 -0800 Subject: Review for 8006225: tools/jdeps/Basic.java fails with AssertionError Message-ID: <511C4365.1000906@oracle.com> This fixes 8006225: tools/jdeps/Basic.java fails with AssertionError. Webrev: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8006225/webrev.00/ jdeps maintains a static list of analyzed classes, each of which is expected to be from one archive. test/tools/jdeps/Basic.java calls com.sun.tools.jdeps.Main multiple times with different classpath and thus the same class came from different path in a different invocation of jdeps. Fix jdeps to keep the data in instance variables. I refactored the analysis from JdepsTask into a new Analyzer class to ease further enhancement. Thanks Mandy From Ulf.Zibis at CoSoCo.de Thu Feb 14 03:11:29 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 14 Feb 2013 04:11:29 +0100 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: <511C55E1.1010803@CoSoCo.de> Am 13.02.2013 23:45, schrieb Mike Duigou: > 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/ Fine, but I still see the typo in j.l.System. -Ulf From joe.darcy at oracle.com Thu Feb 14 07:05:28 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 14 Feb 2013 07:05:28 +0000 Subject: hg: jdk8/tl/langtools: 8001457: New tests needed for library-side changes for repeating annotations Message-ID: <20130214070531.6FABF47A6A@hg.openjdk.java.net> Changeset: 63872da94576 Author: darcy Date: 2013-02-13 23:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/63872da94576 8001457: New tests needed for library-side changes for repeating annotations Reviewed-by: darcy Contributed-by: sonali.goel at oracle.com ! test/tools/javac/annotations/repeatingAnnotations/combo/Helper.java + test/tools/javac/annotations/repeatingAnnotations/combo/ReflectionTest.java + test/tools/javac/annotations/repeatingAnnotations/combo/expectedFiles/ExpectedBase.java + test/tools/javac/annotations/repeatingAnnotations/combo/expectedFiles/ExpectedContainer.java From martinrb at google.com Thu Feb 14 07:43:26 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 13 Feb 2013 23:43:26 -0800 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: I like the optimizations in this change, especially the avoidance of copies. Was there some good reason the jdk never before used JavaLangAccess to avoid String creation copies? I am tempted to micro-optimize this some more, e.g. specialize the hex printing code. I might get rid of the digits table and compute ASCII characters simply: ((i < 10) ? '0' : ('a' - 10)) + i Why not formatUnsignedInt? Why not make the new format methods public? Is there a better name than createStringSharedChars? We hope those chars will *not* be shared! How about newStringUnsafe(char[] chars) The spec for + int formatUnsignedLong(long val, int shift, char[] buf, int offset, int len); should make it clearer whose responsibility getting the size right is. It looks like the caller has to ensure there will be enough space, so perhaps the caller should just pass one offset instead of offset plus len. + * @return the lowest character location used stray space On Wed, 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/ > > 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 me at hildeberto.com Thu Feb 14 08:15:02 2013 From: me at hildeberto.com (=?ISO-8859-1?Q?Hildeberto_Mendon=E7a?=) Date: Thu, 14 Feb 2013 09:15:02 +0100 Subject: Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer In-Reply-To: <511A4455.9030106@CoSoCo.de> References: <51190059.4000505@CoSoCo.de> <51194E7E.6080101@CoSoCo.de> <51198AF8.3010805@CoSoCo.de> <511A4455.9030106@CoSoCo.de> Message-ID: I think the "+" syntax in all possible cases with the maximal performance would be the best option indeed. While we are not there yet, we could go for this small change to improve existing code since the difference of performance is significant. To make this proposal more explicit, I'm going to propose a patch soon. Thanks for the constructive discussion! Hildeberto On Tue, Feb 12, 2013 at 2:32 PM, Ulf Zibis wrote: > Am 12.02.2013 01:45, schrieb Vitaly Davidovich: > > >> javac will not replace concat ops across loop iterations, it will replace >> whichever ones are inside one loop iteration. This will still create >> temporary StringBuilder instances. >> >> As for JIT optimizing further, it would have to fully unroll the loop to >> have a chance at eliminating this; I'd be really surprised if loops with >> nontrivial (and non compile time constant) trip counts get eliminated. I'd >> also not rely on JIT here and do the "right" thing manually :). You also >> may not have C2 compiler available or may not even be running on hotspot. >> >> > Thanks for your clarification, Vitaly. > > I was just advocating not to throw away readable syntax for suspicious > performance advantage. > > So this brings me to a new idea: > > Extend the "+"-syntax over all classes of CharSequence !!! > > -Ulf > > -- Hildeberto Mendon?a, Ph.D Blog: http://www.hildeberto.com Twitter: https://twitter.com/htmfilho From fweimer at redhat.com Thu Feb 14 09:28:44 2013 From: fweimer at redhat.com (Florian Weimer) Date: Thu, 14 Feb 2013 10:28:44 +0100 Subject: Define JNIEXPORT as visibility default with GCC? In-Reply-To: References: Message-ID: <511CAE4C.2000002@redhat.com> On 02/14/2013 02:32 AM, Martin Buchholz wrote: > +#if defined(__GNUC__) && (__GNUC__ > 4) || (__GNUC__ == 4) && > (__GNUC_MINOR__ > 2) > + #define JNIEXPORT __attribute__((visibility("default"))) > + #define JNIIMPORT __attribute__((visibility("default"))) The default compiler in Xcode 4.1 is llvm-gcc 4.2, it seems. The conditional above excludes that. Is this intentional? If Xcode 4.1 supports visibility properly, you can drop the comparisons because the minimum GCC version on other architectures is already 4.3. (And that's from an outdated README-builds.html?we might require a more recent version in practice.) -- Florian Weimer / Red Hat Product Security Team From chris.hegarty at oracle.com Thu Feb 14 11:11:53 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 14 Feb 2013 11:11:53 +0000 Subject: RFR 8008201: Add java/lang/Class/asSubclass/BasicUnit.java to the ProblemList Message-ID: <511CC679.6040707@oracle.com> This test started failing since the integration of new inference scheme in javac [1]. The javac issue is being tracked by 8008200, so I am simply proposing to add this test to the ProblemList until the underlying issue can be resolved. >: hg diff ProblemList.txt diff -r e6f34051c60c test/ProblemList.txt --- a/test/ProblemList.txt Wed Feb 13 16:15:09 2013 -0500 +++ b/test/ProblemList.txt Thu Feb 14 11:11:05 2013 +0000 @@ -133,6 +133,9 @@ java/lang/management/MemoryMXBean/ResetP # 7196801 java/lang/management/MemoryMXBean/LowMemoryTest2.sh generic-all + +# 8008200 +java/lang/Class/asSubclass/BasicUnit.java generic-all ############################################################################ -Chris. [1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2154ed9ff6c8 From maurizio.cimadamore at oracle.com Thu Feb 14 11:17:17 2013 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 14 Feb 2013 11:17:17 +0000 Subject: RFR 8008201: Add java/lang/Class/asSubclass/BasicUnit.java to the ProblemList In-Reply-To: <511CC679.6040707@oracle.com> References: <511CC679.6040707@oracle.com> Message-ID: <511CC7BD.6010404@oracle.com> If we really care about running the test, javac has an hidden flag that can be used to force the old inference scheme (I left that as an emergency hatch in cases like these) - so I believe the test can be compiled by using -XDuseLegacyInference That will essentially force a JDK 7-like behavior of type-inference - not really recommended if the source contains JDK 8 features such as lambda expressions - but it's not the case here. Maurizio On 14/02/13 11:11, Chris Hegarty wrote: > This test started failing since the integration of new inference > scheme in javac [1]. The javac issue is being tracked by 8008200, so I > am simply proposing to add this test to the ProblemList until the > underlying issue can be resolved. > > >: hg diff ProblemList.txt > diff -r e6f34051c60c test/ProblemList.txt > --- a/test/ProblemList.txt Wed Feb 13 16:15:09 2013 -0500 > +++ b/test/ProblemList.txt Thu Feb 14 11:11:05 2013 +0000 > @@ -133,6 +133,9 @@ java/lang/management/MemoryMXBean/ResetP > > # 7196801 > java/lang/management/MemoryMXBean/LowMemoryTest2.sh generic-all > + > +# 8008200 > +java/lang/Class/asSubclass/BasicUnit.java generic-all > > > ############################################################################ > > > > -Chris. > > [1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2154ed9ff6c8 From chris.hegarty at oracle.com Thu Feb 14 11:18:58 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 14 Feb 2013 11:18:58 +0000 Subject: RFR 8008201: Add java/lang/Class/asSubclass/BasicUnit.java to the ProblemList In-Reply-To: <511CC7BD.6010404@oracle.com> References: <511CC679.6040707@oracle.com> <511CC7BD.6010404@oracle.com> Message-ID: <511CC822.5030801@oracle.com> I think it is fine to simply exclude the test for now. It can be re-enabled whenever the issue is resolved in javac. -Chris. On 02/14/2013 11:17 AM, Maurizio Cimadamore wrote: > If we really care about running the test, javac has an hidden flag that > can be used to force the old inference scheme (I left that as an > emergency hatch in cases like these) - so I believe the test can be > compiled by using > > -XDuseLegacyInference > > That will essentially force a JDK 7-like behavior of type-inference - > not really recommended if the source contains JDK 8 features such as > lambda expressions - but it's not the case here. > > Maurizio > > On 14/02/13 11:11, Chris Hegarty wrote: >> This test started failing since the integration of new inference >> scheme in javac [1]. The javac issue is being tracked by 8008200, so I >> am simply proposing to add this test to the ProblemList until the >> underlying issue can be resolved. >> >> >: hg diff ProblemList.txt >> diff -r e6f34051c60c test/ProblemList.txt >> --- a/test/ProblemList.txt Wed Feb 13 16:15:09 2013 -0500 >> +++ b/test/ProblemList.txt Thu Feb 14 11:11:05 2013 +0000 >> @@ -133,6 +133,9 @@ java/lang/management/MemoryMXBean/ResetP >> >> # 7196801 >> java/lang/management/MemoryMXBean/LowMemoryTest2.sh generic-all >> + >> +# 8008200 >> +java/lang/Class/asSubclass/BasicUnit.java generic-all >> >> >> ############################################################################ >> >> >> >> -Chris. >> >> [1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2154ed9ff6c8 > From maurizio.cimadamore at oracle.com Thu Feb 14 12:15:56 2013 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 14 Feb 2013 12:15:56 +0000 Subject: RFR 8008201: Add java/lang/Class/asSubclass/BasicUnit.java to the ProblemList In-Reply-To: <511CC822.5030801@oracle.com> References: <511CC679.6040707@oracle.com> <511CC7BD.6010404@oracle.com> <511CC822.5030801@oracle.com> Message-ID: <511CD57C.20502@oracle.com> On 14/02/13 11:18, Chris Hegarty wrote: > I think it is fine to simply exclude the test for now. It can be > re-enabled whenever the issue is resolved in javac. Looks fine - go ahead. Thanks Maurizio > > -Chris. > > On 02/14/2013 11:17 AM, Maurizio Cimadamore wrote: >> If we really care about running the test, javac has an hidden flag that >> can be used to force the old inference scheme (I left that as an >> emergency hatch in cases like these) - so I believe the test can be >> compiled by using >> >> -XDuseLegacyInference >> >> That will essentially force a JDK 7-like behavior of type-inference - >> not really recommended if the source contains JDK 8 features such as >> lambda expressions - but it's not the case here. >> >> Maurizio >> >> On 14/02/13 11:11, Chris Hegarty wrote: >>> This test started failing since the integration of new inference >>> scheme in javac [1]. The javac issue is being tracked by 8008200, so I >>> am simply proposing to add this test to the ProblemList until the >>> underlying issue can be resolved. >>> >>> >: hg diff ProblemList.txt >>> diff -r e6f34051c60c test/ProblemList.txt >>> --- a/test/ProblemList.txt Wed Feb 13 16:15:09 2013 -0500 >>> +++ b/test/ProblemList.txt Thu Feb 14 11:11:05 2013 +0000 >>> @@ -133,6 +133,9 @@ java/lang/management/MemoryMXBean/ResetP >>> >>> # 7196801 >>> java/lang/management/MemoryMXBean/LowMemoryTest2.sh generic-all >>> + >>> +# 8008200 >>> +java/lang/Class/asSubclass/BasicUnit.java generic-all >>> >>> >>> ############################################################################ >>> >>> >>> >>> >>> -Chris. >>> >>> [1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2154ed9ff6c8 >> From chris.hegarty at oracle.com Thu Feb 14 13:01:56 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 14 Feb 2013 13:01:56 +0000 Subject: hg: jdk8/tl/jdk: 8008201: Add java/lang/Class/asSubclass/BasicUnit.java to the ProblemList Message-ID: <20130214130218.73A3C47A79@hg.openjdk.java.net> Changeset: 153884b550f0 Author: chegar Date: 2013-02-14 13:01 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/153884b550f0 8008201: Add java/lang/Class/asSubclass/BasicUnit.java to the ProblemList Reviewed-by: mcimadamore ! test/ProblemList.txt From peter.levart at gmail.com Thu Feb 14 13:24:28 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 14 Feb 2013 14:24:28 +0100 Subject: IdentityHashMap.[keySet|values|entrySet].toArray speed-up In-Reply-To: References: <50C8494E.5030402@gmail.com> Message-ID: <511CE58C.2000404@gmail.com> Hello Mike, On 02/13/2013 09:21 PM, Mike Duigou wrote: > This looks like excellent contribution Peter! > > I will proceed with the testing needed to integrate your improved toArray()/toArray(T[]) implementations. I have created an issue, JDK-8008167, for this patch. > > I am surprised that this didn't get more attention back in December as it does seem to offer significant benefits for size and performance. It would if IdentityHashMap was used instead of HashMap for annotations caching. But that's something that should be done on the global basis (there are various places where Maps of annotations are constructed: reflection classes, AnnotationParser, ...). There's also opportunity to use IdentityHashMap instead of LinkedHashMap (totally unnecessary, since it is never iterated !!??) for holding member values of annotation instances (the Map is keyed by String objects, but they could be interned at map creation time - the same string values are interned already, since they are equal to names of methods of the annotation interfaces and retrieval is already using the interned Strings: Method.getName() - see AnnotationInvocationHandler)... Let me know if testing finds anything or if there's anything I can do (regarding coding style, etc). Regards, Peter > > Thanks, > > Mike > > On Dec 12 2012, at 01:07 , Peter Levart wrote: > >> Hi all, >> >> I propose a patch to java.util.IdentityHashMap to speed-up toArray methods of it's keySet, values and entrySet views: >> >> http://dl.dropbox.com/u/101777488/jdk8-tl/IdentityHashMap/webrev.01/index.html >> >> I toyed with the possibility to replace HashMap-s, that are used in java.lang.Class and java.lang.reflect.[Field|Method|Constructor] to hold cached annotations, with IdentityHashMap-s. They are a perfect replacement, since keys in these maps are java.lang.Class objects. >> >> They are more compact then HashMap-s. This is the comparison of allocated heap bytes between HashMap and IdentityHashMap for various sizes and corresponding capacities which takes into account the size of the Map object, the size of allocated array and the size of Map.Entry-s in case of HM (IHM doesn't have them) and the size of associated values Collection view (allocated when dumping annotations to array). HM-s for annotations are currently allocated with default initial capacity (16). I propose to allocate IHM-s with initial capacity 8 that fits to hold 5 entries which is enough for typical annotation use cases on one hand and still makes improvement for any case on the other: >> >> 32 bit JVM: >> >> | HashMap | IdentityHashMap | >> size|capacity bytes|capacity bytes|IHM.bytes-HM.bytes >> --------+-----------------+-----------------+------------------ >> 0| 16 144| 8 136| -8 >> 1| 16 168| 8 136| -32 >> 2| 16 192| 8 136| -56 >> 3| 16 216| 8 136| -80 >> 4| 16 240| 8 136| -104 >> 5| 16 264| 8 136| -128 >> 6| 16 288| 16 200| -88 >> 7| 16 312| 16 200| -112 >> 8| 16 336| 16 200| -136 >> 9| 16 360| 16 200| -160 >> 10| 16 384| 16 200| -184 >> 11| 16 408| 16 200| -208 >> 12| 16 432| 32 328| -104 >> 13| 32 520| 32 328| -192 >> 14| 32 544| 32 328| -216 >> 15| 32 568| 32 328| -240 >> 16| 32 592| 32 328| -264 >> 17| 32 616| 32 328| -288 >> 18| 32 640| 32 328| -312 >> 19| 32 664| 32 328| -336 >> 20| 32 688| 32 328| -360 >> 40| 64 1296| 64 584| -712 >> 60| 128 2032| 128 1096| -936 >> 80| 128 2512| 128 1096| -1416 >> 100| 256 3504| 256 2120| -1384 >> 120| 256 3984| 256 2120| -1864 >> 140| 256 4464| 256 2120| -2344 >> 160| 256 4944| 256 2120| -2824 >> 180| 256 5424| 512 4168| -1256 >> >> 64 bit JVM: >> >> | HashMap | IdentityHashMap | >> size|capacity bytes|capacity bytes|IHM.bytes-HM.bytes >> --------+-----------------+-----------------+------------------ >> 0| 16 248| 8 240| -8 >> 1| 16 296| 8 240| -56 >> 2| 16 344| 8 240| -104 >> 3| 16 392| 8 240| -152 >> 4| 16 440| 8 240| -200 >> 5| 16 488| 8 240| -248 >> 6| 16 536| 16 368| -168 >> 7| 16 584| 16 368| -216 >> 8| 16 632| 16 368| -264 >> 9| 16 680| 16 368| -312 >> 10| 16 728| 16 368| -360 >> 11| 16 776| 16 368| -408 >> 12| 16 824| 32 624| -200 >> 13| 32 1000| 32 624| -376 >> 14| 32 1048| 32 624| -424 >> 15| 32 1096| 32 624| -472 >> 16| 32 1144| 32 624| -520 >> 17| 32 1192| 32 624| -568 >> 18| 32 1240| 32 624| -616 >> 19| 32 1288| 32 624| -664 >> 20| 32 1336| 32 624| -712 >> 40| 64 2552| 64 1136| -1416 >> 60| 128 4024| 128 2160| -1864 >> 80| 128 4984| 128 2160| -2824 >> 100| 256 6968| 256 4208| -2760 >> 120| 256 7928| 256 4208| -3720 >> 140| 256 8888| 256 4208| -4680 >> 160| 256 9848| 256 4208| -5640 >> 180| 256 10808| 512 8304| -2504 >> >> I hope I've got that tables right. This is the program to compute them: >> >> https://raw.github.com/plevart/jdk8-tl/JEP-149.2/test/src/test/IHMvsHMsizes.java >> >> IHM is also more performant when retrieving the values by keys. The only area in which it lags behind HashMap and is important for accessing annotations in bulk is the toArray method of the values view. In particular for small sizes. The above patch speeds-up those methods by using index iteration instead of Iterator. >> >> Here are some speed-up comparisons: >> >> https://raw.github.com/plevart/jdk8-tl/JEP-149.2/test/IHM_benchmark_results_i7-2600K.txt >> >> They are obtained by running the following micro benchmark: >> >> https://raw.github.com/plevart/jdk8-tl/JEP-149.2/test/src/test/IdentityHashMapTest.java >> >> Even if IHM doesn't replace HM for holding annotations, a speed-up improvement is an improvement. >> >> >> Regards, Peter >> From Alan.Bateman at oracle.com Thu Feb 14 15:43:36 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Feb 2013 15:43:36 +0000 Subject: Review for 8006225: tools/jdeps/Basic.java fails with AssertionError In-Reply-To: <511C4365.1000906@oracle.com> References: <511C4365.1000906@oracle.com> Message-ID: <511D0628.8090308@oracle.com> On 14/02/2013 01:52, Mandy Chung wrote: > This fixes 8006225: tools/jdeps/Basic.java fails with AssertionError. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8006225/webrev.00/ > > jdeps maintains a static list of analyzed classes, each of which is > expected to be from one archive. test/tools/jdeps/Basic.java calls > com.sun.tools.jdeps.Main multiple times with different classpath and > thus the same class came from different path in a different invocation > of jdeps. Fix jdeps to keep the data in instance variables. I > refactored the analysis from JdepsTask into a new Analyzer class to > ease further enhancement. This looks okay to me, I guess it's only going to be a test that runs it more than once in the same VM that would have noticed this, someone using the tool from the command-line would not. -Alan From mike.duigou at oracle.com Thu Feb 14 17:11:35 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 14 Feb 2013 09:11:35 -0800 Subject: IdentityHashMap.[keySet|values|entrySet].toArray speed-up In-Reply-To: <511CE58C.2000404@gmail.com> References: <50C8494E.5030402@gmail.com> <511CE58C.2000404@gmail.com> Message-ID: <6C4FD916-8F34-4EEA-BCA8-6A77EAFDE51C@oracle.com> On Feb 14 2013, at 05:24 , Peter Levart wrote: > Hello Mike, > > On 02/13/2013 09:21 PM, Mike Duigou wrote: >> This looks like excellent contribution Peter! >> >> I will proceed with the testing needed to integrate your improved toArray()/toArray(T[]) implementations. I have created an issue, JDK-8008167, for this patch. >> >> I am surprised that this didn't get more attention back in December as it does seem to offer significant benefits for size and performance. > > It would if IdentityHashMap was used instead of HashMap for annotations caching. But that's something that should be done on the global basis (there are various places where Maps of annotations are constructed: reflection classes, AnnotationParser, ...). > > There's also opportunity to use IdentityHashMap instead of LinkedHashMap (totally unnecessary, since it is never iterated !!??) for holding member values of annotation instances (the Map is keyed by String objects, but they could be interned at map creation time - the same string values are interned already, since they are equal to names of methods of the annotation interfaces and retrieval is already using the interned Strings: Method.getName() - see AnnotationInvocationHandler)... > > Let me know if testing finds anything or if there's anything I can do (regarding coding style, etc). I have made the style changes (method brackets placement, while->for) suggested by Martin but didn't make any other changes. Build farm regression testing passed with flying colours so I will integrate the patch today. I encourage you to pursue the replacement of LinkedHashMap and HashMap with IdentityHashMap for annotations. Mike > > Regards, Peter > >> >> Thanks, >> >> Mike >> On Dec 12 2012, at 01:07 , Peter Levart wrote: >> >>> Hi all, >>> >>> I propose a patch to java.util.IdentityHashMap to speed-up toArray methods of it's keySet, values and entrySet views: >>> >>> http://dl.dropbox.com/u/101777488/jdk8-tl/IdentityHashMap/webrev.01/index.html >>> >>> I toyed with the possibility to replace HashMap-s, that are used in java.lang.Class and java.lang.reflect.[Field|Method|Constructor] to hold cached annotations, with IdentityHashMap-s. They are a perfect replacement, since keys in these maps are java.lang.Class objects. >>> >>> They are more compact then HashMap-s. This is the comparison of allocated heap bytes between HashMap and IdentityHashMap for various sizes and corresponding capacities which takes into account the size of the Map object, the size of allocated array and the size of Map.Entry-s in case of HM (IHM doesn't have them) and the size of associated values Collection view (allocated when dumping annotations to array). HM-s for annotations are currently allocated with default initial capacity (16). I propose to allocate IHM-s with initial capacity 8 that fits to hold 5 entries which is enough for typical annotation use cases on one hand and still makes improvement for any case on the other: >>> >>> 32 bit JVM: >>> >>> | HashMap | IdentityHashMap | >>> size|capacity bytes|capacity bytes|IHM.bytes-HM.bytes >>> --------+-----------------+-----------------+------------------ >>> 0| 16 144| 8 136| -8 >>> 1| 16 168| 8 136| -32 >>> 2| 16 192| 8 136| -56 >>> 3| 16 216| 8 136| -80 >>> 4| 16 240| 8 136| -104 >>> 5| 16 264| 8 136| -128 >>> 6| 16 288| 16 200| -88 >>> 7| 16 312| 16 200| -112 >>> 8| 16 336| 16 200| -136 >>> 9| 16 360| 16 200| -160 >>> 10| 16 384| 16 200| -184 >>> 11| 16 408| 16 200| -208 >>> 12| 16 432| 32 328| -104 >>> 13| 32 520| 32 328| -192 >>> 14| 32 544| 32 328| -216 >>> 15| 32 568| 32 328| -240 >>> 16| 32 592| 32 328| -264 >>> 17| 32 616| 32 328| -288 >>> 18| 32 640| 32 328| -312 >>> 19| 32 664| 32 328| -336 >>> 20| 32 688| 32 328| -360 >>> 40| 64 1296| 64 584| -712 >>> 60| 128 2032| 128 1096| -936 >>> 80| 128 2512| 128 1096| -1416 >>> 100| 256 3504| 256 2120| -1384 >>> 120| 256 3984| 256 2120| -1864 >>> 140| 256 4464| 256 2120| -2344 >>> 160| 256 4944| 256 2120| -2824 >>> 180| 256 5424| 512 4168| -1256 >>> >>> 64 bit JVM: >>> >>> | HashMap | IdentityHashMap | >>> size|capacity bytes|capacity bytes|IHM.bytes-HM.bytes >>> --------+-----------------+-----------------+------------------ >>> 0| 16 248| 8 240| -8 >>> 1| 16 296| 8 240| -56 >>> 2| 16 344| 8 240| -104 >>> 3| 16 392| 8 240| -152 >>> 4| 16 440| 8 240| -200 >>> 5| 16 488| 8 240| -248 >>> 6| 16 536| 16 368| -168 >>> 7| 16 584| 16 368| -216 >>> 8| 16 632| 16 368| -264 >>> 9| 16 680| 16 368| -312 >>> 10| 16 728| 16 368| -360 >>> 11| 16 776| 16 368| -408 >>> 12| 16 824| 32 624| -200 >>> 13| 32 1000| 32 624| -376 >>> 14| 32 1048| 32 624| -424 >>> 15| 32 1096| 32 624| -472 >>> 16| 32 1144| 32 624| -520 >>> 17| 32 1192| 32 624| -568 >>> 18| 32 1240| 32 624| -616 >>> 19| 32 1288| 32 624| -664 >>> 20| 32 1336| 32 624| -712 >>> 40| 64 2552| 64 1136| -1416 >>> 60| 128 4024| 128 2160| -1864 >>> 80| 128 4984| 128 2160| -2824 >>> 100| 256 6968| 256 4208| -2760 >>> 120| 256 7928| 256 4208| -3720 >>> 140| 256 8888| 256 4208| -4680 >>> 160| 256 9848| 256 4208| -5640 >>> 180| 256 10808| 512 8304| -2504 >>> >>> I hope I've got that tables right. This is the program to compute them: >>> >>> https://raw.github.com/plevart/jdk8-tl/JEP-149.2/test/src/test/IHMvsHMsizes.java >>> >>> IHM is also more performant when retrieving the values by keys. The only area in which it lags behind HashMap and is important for accessing annotations in bulk is the toArray method of the values view. In particular for small sizes. The above patch speeds-up those methods by using index iteration instead of Iterator. >>> >>> Here are some speed-up comparisons: >>> >>> https://raw.github.com/plevart/jdk8-tl/JEP-149.2/test/IHM_benchmark_results_i7-2600K.txt >>> >>> They are obtained by running the following micro benchmark: >>> >>> https://raw.github.com/plevart/jdk8-tl/JEP-149.2/test/src/test/IdentityHashMapTest.java >>> >>> Even if IHM doesn't replace HM for holding annotations, a speed-up improvement is an improvement. >>> >>> >>> Regards, Peter >>> > From lowasser at google.com Thu Feb 14 17:17:10 2013 From: lowasser at google.com (Louis Wasserman) Date: Thu, 14 Feb 2013 09:17:10 -0800 Subject: [PATCH] Sunbug 7131192: Optimize BigInteger.doubleValue(), floatValue() In-Reply-To: References: <4FFE758E.1000003@redhat.com> <4FFEA51B.4030107@redhat.com> <5000C965.7070101@oracle.com> Message-ID: Any update on when this could get reviewed? On Thu, Dec 13, 2012 at 3:36 PM, Louis Wasserman wrote: > Hi, > > I'm working at Google now, but I'd like to revive this patch as a > contribution from Google. At the moment, what's mainly needed is review > for http://bugs.sun.com/view_bug.do?bug_id=7192954, the fix to > Float.parseFloat's rounding behavior, before we can go anywhere with the > patch to optimize BigInteger.floatValue() and doubleValue(). > >> Would anyone be able to review that patch so these can start moving > forward? > > Thanks, > >> Louis Wasserman > Java Core Libraries Team @ Google > guava-libraries.googlecode.com > > ---------- Forwarded message ---------- >> From: Louis Wasserman >> Date: Sat, Jul 14, 2012 at 5:32 AM >> Subject: Re: [PATCH] Sunbug 7131192: Optimize BigInteger.doubleValue(), >> floatValue() >> To: Joseph Darcy >> Cc: Andrew Haley , core-libs-dev at openjdk.java.net >> >> >> Understood. FYI, testing for this change revealed a bug in >> Float.parseFloat, a patch for which has been separately sent to this >> mailing list under the subject line "[PATCH] Sunbug 6358355: Rounding error >> in Float.parseFloat". (As a result, the BigInteger patch may fail some of >> the provided tests at the moment, but that is truly because the reference >> implementation it's being tested against is faulty.) >> >> Louis Wasserman >> wasserman.louis at gmail.com >> http://profiles.google.com/wasserman.louis >> >> >> On Sat, Jul 14, 2012 at 2:20 AM, Joseph Darcy wrote: >> >>> Hello, >>> >>> Thanks for the patch Louis. >>> >>> >>> On 7/12/2012 3:21 AM, Andrew Haley wrote: >>> >>>> On 07/12/2012 10:32 AM, Louis Wasserman wrote: >>>> >>>>> It was attached to the previous message? I don't know if this list >>>>> works >>>>> with attachments. Alternately, the patch was attached here: >>>>> https://bugs.openjdk.java.net/**show_bug.cgi?id=100222 >>>>> >>>>> I'm not sure what you mean by double-rounding bugs, though. It's >>>>> not difficult to actually implement the HALF_EVEN rounding behavior >>>>> with bit twiddling. >>>>> >>>> Sure, as long as you've thought about it and done it carefully. The >>>> bit twiddling is easy to do, and easy to get wrong. >>>> >>>> > From the supplied patch it looks like you've done a good job, but >>>> there was no way to tell without it. I presume the listserv dropped >>>> it on the floor. >>>> >>>> Andrew. >>>> >>> >>> I've taken a quick look at the patch. The concept for the change is >>> good; the current path of converting to float/double through a string is a >>> simple but very roundabout way to accomplish this task. >>> >>> Unfortunately, I'm saturated with the JDK bug migration [1] and will >>> continue to be saturated for at least several more weeks so I won't be able >>> to take a more detailed look at the patch for a while. I suspect some more >>> directly test cases will be needed to test tricky rounding situations. >>> >>> Thanks, >>> >>> -Joe >>> >>> [1] https://blogs.oracle.com/**darcy/entry/moving_monarchs_**dragons >>> >> >> >> > > > -- > Louis Wasserman > -- Louis Wasserman From mandy.chung at oracle.com Thu Feb 14 17:19:19 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 14 Feb 2013 09:19:19 -0800 Subject: Review for 8006225: tools/jdeps/Basic.java fails with AssertionError In-Reply-To: <511D0628.8090308@oracle.com> References: <511C4365.1000906@oracle.com> <511D0628.8090308@oracle.com> Message-ID: <511D1C97.2000905@oracle.com> On 2/14/13 7:43 AM, Alan Bateman wrote: > On 14/02/2013 01:52, Mandy Chung wrote: >> This fixes 8006225: tools/jdeps/Basic.java fails with AssertionError. >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8006225/webrev.00/ >> >> jdeps maintains a static list of analyzed classes, each of which is >> expected to be from one archive. test/tools/jdeps/Basic.java calls >> com.sun.tools.jdeps.Main multiple times with different classpath and >> thus the same class came from different path in a different >> invocation of jdeps. Fix jdeps to keep the data in instance >> variables. I refactored the analysis from JdepsTask into a new >> Analyzer class to ease further enhancement. > This looks okay to me, I guess it's only going to be a test that runs > it more than once in the same VM that would have noticed this, someone > using the tool from the command-line would not. > Right. The tool from command-line doesn't run into that issue. Thanks for the review. Mandy From mandy.chung at oracle.com Thu Feb 14 17:44:18 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 14 Feb 2013 17:44:18 +0000 Subject: hg: jdk8/tl/langtools: 8006225: tools/jdeps/Basic.java failes with AssertionError Message-ID: <20130214174421.CF37B47A95@hg.openjdk.java.net> Changeset: 88286a36bb34 Author: mchung Date: 2013-02-14 09:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/88286a36bb34 8006225: tools/jdeps/Basic.java failes with AssertionError Reviewed-by: alanb + src/share/classes/com/sun/tools/jdeps/Analyzer.java ! src/share/classes/com/sun/tools/jdeps/Archive.java ! src/share/classes/com/sun/tools/jdeps/JdepsTask.java ! test/tools/jdeps/Basic.java From mike.duigou at oracle.com Thu Feb 14 17:55:14 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 14 Feb 2013 17:55:14 +0000 Subject: hg: jdk8/tl/jdk: 8008167: IdentityHashMap.[keySet|values|entrySet].toArray speed-up Message-ID: <20130214175538.236EC47A96@hg.openjdk.java.net> Changeset: e57019d2f34a Author: mduigou Date: 2013-02-13 14:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e57019d2f34a 8008167: IdentityHashMap.[keySet|values|entrySet].toArray speed-up Reviewed-by: mduigou, martin Contributed-by: Peter Levart ! src/share/classes/java/util/IdentityHashMap.java From mark.sheppard at oracle.com Thu Feb 14 18:34:35 2013 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Thu, 14 Feb 2013 18:34:35 +0000 Subject: RFR JDK-8002390 problems moving files between zip file systems Message-ID: <511D2E3B.4030307@oracle.com> Hi Please oblige and review the webrev at http://cr.openjdk.java.net/~sherman/8002390/webrev/ which addresses the issue raised in JDK-8002390 Description: While working with the new ZipFileSystem to modify the contents of a zip file, encountered some issues. The issue occurs when a file within a zip file is moved to a different location within the same zip and a FileVisitor is invoked by Files.walkFileTree the original (no longer existing file) will attempted to be visited by ZipFileSystemProvider and throw a NoSuchFileException. This is an issue with the ZipFileSystem demonstration code, which provides a concrete example of the java.nio.file FileSystem and associated functionality. The issue arises when the file system is created, closed, then re-opened followed by a file move operation within the ZipFileSystem. This arises from the fact that the internal data structures representing the ZipFileSystem, when it is initially created are slightly different to those when the file system is re-opened after a close. The ZipFileSystem.copyFile() processing flow, which is the end result of the Files.move(), needed to be amended to allow for this subtle difference. This is represented in the changes in the update() and removeFromTree() methods. Additionally, the logic for handling a rename, earlier in the processing flow was amended, also. relevant tests have been updated. regards Mark From david.dehaven at oracle.com Thu Feb 14 19:07:42 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 14 Feb 2013 11:07:42 -0800 Subject: Define JNIEXPORT as visibility default with GCC? In-Reply-To: References: Message-ID: > This seems like an obvious improvement. > There are already bunches of places in the jdk sources that do things like: > > ./hotspot/src/cpu/x86/vm/jni_x86.h > #if defined(SOLARIS) || defined(LINUX) || defined(_ALLBSD_SOURCE) > > #if defined(__GNUC__) && (__GNUC__ > 4) || (__GNUC__ == 4) && > (__GNUC_MINOR__ > 2) > #define JNIEXPORT __attribute__((visibility("default"))) > #define JNIIMPORT __attribute__((visibility("default"))) > #else > #define JNIEXPORT > #define JNIIMPORT > #endif That version check didn't work for me running on Mac OS X (using llvm-gcc 4.2). If that's what hotspot is using then they may not be getting the desired effect. The problem is __GNUC_MINOR__ is 2, so it needs to be changed to >= 2. Gnu recommends just using "#if __GNUC__ >= 4", and everything I've read about it says it's 4.0 and later, so I don't understand why the minor version check is even in there. -DrD- From david.dehaven at oracle.com Thu Feb 14 19:09:37 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 14 Feb 2013 11:09:37 -0800 Subject: Define JNIEXPORT as visibility default with GCC? In-Reply-To: <511CAE4C.2000002@redhat.com> References: <511CAE4C.2000002@redhat.com> Message-ID: <4974FD20-B6DD-40F5-A7E9-B78F09E9C2A1@oracle.com> >> +#if defined(__GNUC__) && (__GNUC__ > 4) || (__GNUC__ == 4) && >> (__GNUC_MINOR__ > 2) >> + #define JNIEXPORT __attribute__((visibility("default"))) >> + #define JNIIMPORT __attribute__((visibility("default"))) > > The default compiler in Xcode 4.1 is llvm-gcc 4.2, it seems. The conditional above excludes that. Is this intentional? It's *is* gcc, with a LLVM backend. -DrD- From mandy.chung at oracle.com Thu Feb 14 19:09:30 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 14 Feb 2013 19:09:30 +0000 Subject: hg: jdk8/tl/jdk: 8007736: VerifyError for use of static method in interface Message-ID: <20130214190943.2B08D47A98@hg.openjdk.java.net> Changeset: 1405ad6afb1e Author: bharadwaj Date: 2013-02-14 11:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1405ad6afb1e 8007736: VerifyError for use of static method in interface Reviewed-by: mchung ! src/share/native/common/check_code.c + test/vm/verifier/TestStaticIF.java From fweimer at redhat.com Thu Feb 14 21:43:43 2013 From: fweimer at redhat.com (Florian Weimer) Date: Thu, 14 Feb 2013 22:43:43 +0100 Subject: Define JNIEXPORT as visibility default with GCC? In-Reply-To: <4974FD20-B6DD-40F5-A7E9-B78F09E9C2A1@oracle.com> References: <511CAE4C.2000002@redhat.com> <4974FD20-B6DD-40F5-A7E9-B78F09E9C2A1@oracle.com> Message-ID: <511D5A8F.7050403@redhat.com> On 02/14/2013 08:09 PM, David DeHaven wrote: > >>> +#if defined(__GNUC__) && (__GNUC__ > 4) || (__GNUC__ == 4) && >>> (__GNUC_MINOR__ > 2) >>> + #define JNIEXPORT __attribute__((visibility("default"))) >>> + #define JNIIMPORT __attribute__((visibility("default"))) >> >> The default compiler in Xcode 4.1 is llvm-gcc 4.2, it seems. The conditional above excludes that. Is this intentional? > > It's *is* gcc, with a LLVM backend. Yes, but it identifies itself as GCC 4.2, so the conditional doesn't fire. If Xcode is fine with the #define, I suggest to drop the version check completely. We already do not support compiling with GCC versions which are so old that they lack visibility support. -- Florian Weimer / Red Hat Product Security Team From dmitry.degrave at oracle.com Thu Feb 14 21:51:11 2013 From: dmitry.degrave at oracle.com (dmitry.degrave at oracle.com) Date: Thu, 14 Feb 2013 21:51:11 +0000 Subject: hg: jdk8/tl/corba: 7199858: Marshal exception is wrong Message-ID: <20130214215111.D1D6247AA0@hg.openjdk.java.net> Changeset: e725dd195858 Author: dmeetry Date: 2013-02-15 01:49 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/e725dd195858 7199858: Marshal exception is wrong Reviewed-by: lancea ! src/share/classes/com/sun/corba/se/impl/corba/TypeCodeImpl.java From martinrb at google.com Thu Feb 14 23:00:50 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 14 Feb 2013 15:00:50 -0800 Subject: Define JNIEXPORT as visibility default with GCC? In-Reply-To: References: Message-ID: Alright, let's use gcc's recommended test, and let's add a test for clang (completely untested): diff --git a/src/solaris/javavm/export/jni_md.h b/src/solaris/javavm/export/jni_md.h --- a/src/solaris/javavm/export/jni_md.h +++ b/src/solaris/javavm/export/jni_md.h @@ -26,8 +26,14 @@ #ifndef _JAVASOFT_JNI_MD_H_ #define _JAVASOFT_JNI_MD_H_ -#define JNIEXPORT -#define JNIIMPORT +#if (defined(__GNUC__) && __GNUC__ >= 4) || (defined(__has_attribute) && __has_attribute(visibility)) + #define JNIEXPORT __attribute__((visibility("default"))) + #define JNIIMPORT __attribute__((visibility("default"))) +#else + #define JNIEXPORT + #define JNIIMPORT +#endif + #define JNICALL typedef int jint; On Thu, Feb 14, 2013 at 11:07 AM, David DeHaven wrote: > > > This seems like an obvious improvement. > > There are already bunches of places in the jdk sources that do things > like: > > > > ./hotspot/src/cpu/x86/vm/jni_x86.h > > #if defined(SOLARIS) || defined(LINUX) || defined(_ALLBSD_SOURCE) > > > > #if defined(__GNUC__) && (__GNUC__ > 4) || (__GNUC__ == 4) && > > (__GNUC_MINOR__ > 2) > > #define JNIEXPORT __attribute__((visibility("default"))) > > #define JNIIMPORT __attribute__((visibility("default"))) > > #else > > #define JNIEXPORT > > #define JNIIMPORT > > #endif > > That version check didn't work for me running on Mac OS X (using llvm-gcc > 4.2). If that's what hotspot is using then they may not be getting the > desired effect. The problem is __GNUC_MINOR__ is 2, so it needs to be > changed to >= 2. > > Gnu recommends just using "#if __GNUC__ >= 4", and everything I've read > about it says it's 4.0 and later, so I don't understand why the minor > version check is even in there. > > -DrD- > > From david.dehaven at oracle.com Thu Feb 14 23:01:38 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 14 Feb 2013 15:01:38 -0800 Subject: Define JNIEXPORT as visibility default with GCC? In-Reply-To: <511D5A8F.7050403@redhat.com> References: <511CAE4C.2000002@redhat.com> <4974FD20-B6DD-40F5-A7E9-B78F09E9C2A1@oracle.com> <511D5A8F.7050403@redhat.com> Message-ID: >>>> +#if defined(__GNUC__) && (__GNUC__ > 4) || (__GNUC__ == 4) && >>>> (__GNUC_MINOR__ > 2) >>>> + #define JNIEXPORT __attribute__((visibility("default"))) >>>> + #define JNIIMPORT __attribute__((visibility("default"))) >>> >>> The default compiler in Xcode 4.1 is llvm-gcc 4.2, it seems. The conditional above excludes that. Is this intentional? >> >> It's *is* gcc, with a LLVM backend. > > Yes, but it identifies itself as GCC 4.2, so the conditional doesn't fire. I assume this was not the intent and the version check is just wrong. > If Xcode is fine with the #define, I suggest to drop the version check completely. We already do not support compiling with GCC versions which are so old that they lack visibility support. If it were Mac only, I'd agree. The same header is currently used for all "unix-like" OS's (which may change, if I have my way), so Solaris and Linux would also be affected. Most Linux distros have used gcc 4 for quite a while now, I've no idea what Solaris uses and embedded targets are a wild mishmash of whatever someone manages to cobble together, so the simpler __GNUC__ check may still be appropriate. -DrD- From mandy.chung at oracle.com Thu Feb 14 23:31:22 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 14 Feb 2013 15:31:22 -0800 Subject: Review 8007703: Remove com.sun.servicetag API Message-ID: <511D73CA.90503@oracle.com> Remove com.sun.servicetag that we no longer support. This includes updates the makefiles and so include build-infra to review this change. 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 xueming.shen at oracle.com Fri Feb 15 01:19:09 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 15 Feb 2013 01:19:09 +0000 Subject: hg: jdk8/tl/jdk: 8008254: j.u.Calendar.JavatimeTest failed at TL b78 pit testing Message-ID: <20130215011921.2050947AB0@hg.openjdk.java.net> Changeset: 1ce1a307cded Author: sherman Date: 2013-02-15 01:17 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1ce1a307cded 8008254: j.u.Calendar.JavatimeTest failed at TL b78 pit testing Summary: to use j.t.ZoneId zone name to keep round-trip Reviewed-by: okutsu ! test/java/util/Calendar/JavatimeTest.java From brian.burkhalter at oracle.com Fri Feb 15 01:23:46 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 14 Feb 2013 17:23:46 -0800 Subject: Review: 4396272 - Parsing doubles fails to follow IEEE for largest decimal that should yield 0 Message-ID: <4412AB7C-A91F-48A9-ACF2-3816480C28E1@oracle.com> The patch below is as submitted to OpenJDK bugzilla but with enhanced comments. It pertains to the correction loop in the doubleValue() method of FloatingDecimal. The situation appears to arise when the candidate value is less than 2*Double.MIN_NORMAL as for such values the ULP is less than 2*Double.MIN_VALUE so that the intermediate result 0.5*ULP is less than Double.MIN_VALUE which rounds to zero per FP-strict and the correction is therefore zero. Thus the candidate value is unchanged. The fix is to add the ULP to twice the candidate value, obtain the intermediate result, and then halve it to obtain the adjusted candidate. I am relatively new to IEEE-754 and this area of the code so any comments would be appreciated. Thanks, Brian diff -r 1405ad6afb1e -r 36482ed9bb7e src/share/classes/sun/misc/FloatingDecimal.java --- a/src/share/classes/sun/misc/FloatingDecimal.java Thu Feb 14 11:09:07 2013 -0800 +++ b/src/share/classes/sun/misc/FloatingDecimal.java Thu Feb 14 16:47:53 2013 -0800 @@ -35,8 +35,16 @@ int decExponent; char digits[]; int nDigits; + + // = ((doubleAsLongBits & expMask) >>> expShift) - expBias + 1 - bigIntNBits + // Set by doubleToBigInt(). int bigIntExp; + + // Number of bits from the high order 1 bit to the low order 1 bit, + // inclusive, of the fractional (significand) part of a double. + // Set by doubleToBigInt(). int bigIntNBits; + boolean mustSetRoundDir = false; boolean fromHex = false; int roundDir = 0; // set by doubleValue @@ -1604,7 +1612,50 @@ } else if ( cmpResult == 0 ){ // difference is exactly half an ULP // round to some other value maybe, then finish - dValue += 0.5*ulp( dValue, overvalue ); + // Fix of bug 4396272. This method has strictfp modifier now. + // Nevertheless, the two comments below explain why it can work without strictfp too. + // + // In the logical expression tested on the if-block, + // bigIntExp = expBiased - expBias + 1 - bigIntNBits so that + // bigIntExp+bigIntNBits = expBiased - expBias + 1 so the inequality tested is + // expBiased - expBias + 1 > -expBias+2 or expBiased > 1 which implies + // exUnbiased > 1 - expBias = -1022 or expUnbiased > -1021 so that + // old dValue > 2^(-1021) = 2*2^(-1022) = 2*Double.MIN_NORMAL. + // Either ">" or ">=" could be used in the logical expression + // as both branches evaluate to the same result when equality obtains. + // + // As dValue becomes smaller, the ULP descreases reaching + // Double.MIN_VALUE for dValue == 2*Double.MIN_NORMAL. Below + // this the intermediate result 0.5*ULP will be rounded to + // zero per FP-strict. As a result no correction to dValue + // will occur. To prevent this, 2*dValue + ULP is first + // computed so that the effect of adding half the ULP is not + // lost, then this intermediate result is halved. + // + if ( bigIntExp+bigIntNBits > -expBias+2 ) { + // Here old dValue > 2*Double.MIN_NORMAL + // + // Non-FP-strict case: + // If overvalue == false then ulp(dValue,false) >= 2*Double.MIN_VALUE and 0.5*ulp is exact. + // If overvalue == true and dValue > 2*Double.MIN_NORMAL then ulp(dValue,true) <= -2*Double.MIN_VALUE and 0.5*ulp is exact. + // If overvalue == true and dValue == 2*Double.MIN_NORMAL then ulp(dValue,true) == -Double.MIN_VALUE. + // Hence 0.5*ulp is rounded to 0 in double value set and 0.5*ulp is exact in double-extended-exponent value set. + // In both value sets new dValue is rounded to 2*Double.MIN_NOPMAL as expected + dValue += 0.5*ulp( dValue, overvalue ); + } else { + // Here old dValue <= 2*Double.MIN_NORMAL + // + // Non-FP-strict case: + // If overvalue == false then ulp(dValue,false) == Double.MIN_VALUE + // If dValue >= Double.MIN_NORMAL then dValue*2 + ulp rounds to nearest even and 0.5*(...) is exact + // If dValue < Double.MIN_NORMAL then dValue*2 + ulp is exact and 0.5*(...) rounds to nearest even in double value set + // and is exact in double-extended-exponent value set and then rounds to nearest even double before storing to new dValue. + // If overvalue == true then ulp(dValue,true) == -Double.MIN_VALUE + // If dValue > Double.MIN_NORMAL then dValue*2 + ulp rounds to nearest even and 0.5*(...) is exact + // If dValue <= Double.MIN_NORMAL then dValue*2 + ulp is exact and 0.5*(...) rounds to nearest even in double value set + // and is exact in double-extended-exponent value set and then rounds to nearest even double before storing to new dValue. + dValue = 0.5*(dValue*2 + ulp( dValue, overvalue)); + } // should check for bigIntNBits == 1 here?? if (mustSetRoundDir) { roundDir = overvalue ? -1 : 1; diff -r 1405ad6afb1e -r 36482ed9bb7e test/java/lang/Double/ParseDouble.java --- a/test/java/lang/Double/ParseDouble.java Thu Feb 14 11:09:07 2013 -0800 +++ b/test/java/lang/Double/ParseDouble.java Thu Feb 14 16:47:53 2013 -0800 @@ -23,7 +23,7 @@ /* * @test - * @bug 4160406 4705734 4707389 4826774 4895911 4421494 7021568 7039369 + * @bug 4160406 4705734 4707389 4826774 4895911 4421494 7021568 7039369 4396272 * @summary Test for Double.parseDouble method and acceptance regex */ @@ -560,17 +560,18 @@ * region that should convert to that value. */ private static void testSubnormalPowers() { + boolean failed = false; BigDecimal TWO = BigDecimal.valueOf(2); // An ulp is the same for all subnormal values BigDecimal ulp_BD = new BigDecimal(Double.MIN_VALUE); - // Test subnormal powers of two - for(int i = -1074; i <= -1022; i++) { + // Test subnormal powers of two (except Double.MIN_VALUE) + for(int i = -1073; i <= -1022; i++) { double d = Math.scalb(1.0, i); /* * The region [d - ulp/2, d + ulp/2] should round to d. - */ + */ BigDecimal d_BD = new BigDecimal(d); BigDecimal lowerBound = d_BD.subtract(ulp_BD.divide(TWO)); @@ -578,17 +579,52 @@ double convertedLowerBound = Double.parseDouble(lowerBound.toString()); double convertedUpperBound = Double.parseDouble(upperBound.toString()); + if (convertedLowerBound != d) { + failed = true; + System.out.printf("2^%d lowerBound converts as %a %s%n", + i, convertedLowerBound, lowerBound); + } + if (convertedUpperBound != d) { + failed = true; + System.out.printf("2^%d upperBound converts as %a %s%n", + i, convertedUpperBound, upperBound); + } } + /* + * Double.MIN_VALUE + * The region ]0.5*Double.MIN_VALUE, 1.5*Double.MIN_VALUE[ should round to Double.MIN_VALUE . + */ + BigDecimal minValue = new BigDecimal(Double.MIN_VALUE); + if (Double.parseDouble(minValue.multiply(new BigDecimal(0.5)).toString()) != 0.0) { + failed = true; + System.out.printf("0.5*MIN_VALUE doesn't convert 0%n"); + } + if (Double.parseDouble(minValue.multiply(new BigDecimal(0.50000000001)).toString()) != Double.MIN_VALUE) { + failed = true; + System.out.printf("0.50000000001*MIN_VALUE doesn't convert to MIN_VALUE%n"); + } + if (Double.parseDouble(minValue.multiply(new BigDecimal(1.49999999999)).toString()) != Double.MIN_VALUE) { + failed = true; + System.out.printf("1.49999999999*MIN_VALUE doesn't convert to MIN_VALUE%n"); + } + if (Double.parseDouble(minValue.multiply(new BigDecimal(1.5)).toString()) != 2*Double.MIN_VALUE) { + failed = true; + System.out.printf("1.5*MIN_VALUE doesn't convert to 2*MIN_VALUE%n"); + } + + if (failed) + throw new RuntimeException("Inconsistent conversion"); } private static void testStrictness() { - final double expected = 0x0.0000008000001p-1022; + final double expected = 0x0.0000008000000p-1022; +// final double expected = 0x0.0000008000001p-1022; boolean failed = false; double conversion = 0.0; double sum = 0.0; // Prevent conversion from being optimized away - //2^-1047 + 2^-1075 + //2^-1047 + 2^-1075 rounds to 2^-1047 String decimal = "6.631236871469758276785396630275967243399099947355303144249971758736286630139265439618068200788048744105960420552601852889715006376325666595539603330361800519107591783233358492337208057849499360899425128640718856616503093444922854759159988160304439909868291973931426625698663157749836252274523485312442358651207051292453083278116143932569727918709786004497872322193856150225415211997283078496319412124640111777216148110752815101775295719811974338451936095907419622417538473679495148632480391435931767981122396703443803335529756003353209830071832230689201383015598792184172909927924176339315507402234836120730914783168400715462440053817592702766213559042115986763819482654128770595766806872783349146967171293949598850675682115696218943412532098591327667236328125E-316"; for(int i = 0; i <= 12_000; i++) { From xueming.shen at oracle.com Fri Feb 15 01:23:27 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 14 Feb 2013 17:23:27 -0800 Subject: RFR JDK-8002390 problems moving files between zip file systems In-Reply-To: <511D2E3B.4030307@oracle.com> References: <511D2E3B.4030307@oracle.com> Message-ID: <511D8E0F.4020109@oracle.com> looks good. On 2/14/13 10:34 AM, Mark Sheppard wrote: > Hi > > Please oblige and review the webrev at > > http://cr.openjdk.java.net/~sherman/8002390/webrev/ > > which addresses the issue raised in JDK-8002390 > > Description: While working with the new ZipFileSystem to modify the > contents of a zip file, encountered some issues. > The issue occurs when a file within a zip file is moved to a different > location within the same zip and a FileVisitor is invoked by > Files.walkFileTree the original (no longer existing file) will > attempted to be visited by ZipFileSystemProvider and throw a > NoSuchFileException. > > > This is an issue with the ZipFileSystem demonstration code, which > provides a concrete example of the java.nio.file FileSystem and > associated functionality. > The issue arises when the file system is created, closed, then > re-opened followed by > a file move operation within the ZipFileSystem. > > This arises from the fact that the internal data structures > representing the ZipFileSystem, > when it is initially created are slightly different to those when the > file system is re-opened after a close. > The ZipFileSystem.copyFile() processing flow, which is the end result > of the Files.move(), > needed to be amended to allow for this subtle difference. This is > represented in the changes in the update() and > removeFromTree() methods. Additionally, the logic for handling a > rename, earlier in the processing > flow was amended, also. > > relevant tests have been updated. > > > regards > Mark From joe.darcy at oracle.com Fri Feb 15 05:54:18 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 14 Feb 2013 21:54:18 -0800 Subject: RFR - 6480539: BigDecimal.stripTrailingZeros() should specify no-op on zero BigDecimals In-Reply-To: References: <51100C97.4040504@oracle.com> <51104CE4.10506@oracle.com> <1BA5F227-8369-4AC4-A108-165A094BD763@oracle.com> <511358A2.9090408@paradise.net.nz> <511560C3.9070009@oracle.com> Message-ID: <511DCD8A.60206@oracle.com> On 02/08/2013 02:37 PM, Stephen Colebourne wrote: > We've established that it causes problems (me and Paul) and that likely > workarounds of the bug would not be broken by a fix. The adaptation you and Paul have for the current behavior would not be impacted by a change in the behavior of stringTrailingZeros. That just leaves all the other Java programmers to check with ;-) Since any angry emails on changing the behavior would come the way of Brian and I (probably in a few years time), Brian has agreed to do some additional research on how stripTrailingZeros is used in existing code to gauge what impact there could be to altering the long-standing behavior. If the impact is small, we can make the change in JDK 8. -Joe > > The getMethods case is very different as the spec clearly allowed the > behavior. Here the spec and method name are also clear on the expected > behavior. The proposal would make the behavior out of line with the method > name and of no earthly use to users. ie, as a user of that method, I would > never be calling it for any reason other than to remove all the trailing > zeroes. > > Mostly the JDK team gets it right. But not this time. > > Stephen > >> On 8 Feb 2013 20:32, "Joe Darcy" wrote: >>> Hello, >>> >>> On 2/6/2013 11:32 PM, Bruce Chapman wrote: >>>> Stephen, In your case(s) would the workaround fail to work if the bug > was fixed? >>>> Working around a bug is quite different to taking advantage of the > buggy behaviour. If fixing the bug would break code that works around it > that can be seen as a problem, while breaking code that relies on the bug > is IMHO much less of an issue since anyone that does that is taking a known > risk, or a risk that should reasonably be expected to be known. >>>> I am finding it hard to imagine a genuine attempt at a workaround that > would not still work (though redundantly) if the bug was fixed. >>>> Also bear in mind that there are other implementations, and the > signature and the javadoc are the spec. If you find behaviour that differs > and take advantage of that behaviour then you are opening the possibility > of it changing if either: you run with another implementation, or the bug > gets fixed. >>>> While it is easy to contrive an example that would break if this bug > were fixed, and it is possible (on the grounds that I cannot prove it is > impossible) that some real code might break, it is hard to imagine a > scenario where the author/owner of that broken code has any morally > legitimate grounds for complaint in that case. >>>> I guess if you take the "This is one of those unfortunate cases where a > bug can become a feature." approach to its logical conclusion then no bugs > get fixed because there are no bugs, just a nice online list of newly > discovered unexpected features. >>> >>> As noted earlier in this thread, we use a nuanced compatibility policy > in evolving the JDK: >>> > http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html >>> In particular, besides looking after source and binary compatibility, we > also look to manage behavioral compatibility, that is, to be mindful of > changing what a method does at runtime when called, even when the > specification gives us leeway to do so. >>> Let me relate an example of behavioral compatibility from JDK 7. The > method Class.getMethods returns an array of Method objects for the Class > and in part its javadoc has long stated: >>> "The elements in the array returned are not sorted and are not in > any particular order." >>> Therefore, any caller of Class.getMethods relying on or assuming a > particular order has a bug according to the specification. As a > side-effect of permgen removal in JDK 7, the long-standing (and mostly > stable) order of Method objects returned by HotSpot changed. As expected, > some user applications and tests "broke" after this change went in. We > received requests to "fix" the ordering of Class.getMethods, which we > declined to do given the benefits of permgen removal and the clear > specification that no ordering should be relied upon. Even though that > change in getMethods is allowed by specification, it is out-of-bounds of > what we would do an an update release but in-bounds for a platform release > like JDK 7. >>> The reason for this conservatism is because we value keeping the broad > usage of the JDK working :-) >>> Getting back to BigDecimal.stripTrailingZeros, we cannot inspect all > usages of this method today, nor can we inspect all the future usages of > BigDecimal.stripTrailingZeros that will be around before JDK 8 is adopted > for the code in question. We know not everyone migrates to a new JDK > release promptly; within the past two years I fielded a query/complaint > about the behavior change in BigDecimal.toString made between 1.4.2 and JDK > 5 and later. >>> For these sorts of reasons, the default resolution when the > specification and implementation conflict is to make the specification > match the implementation. There are exceptions to this default. Given > sufficient evidence that changing the behavior of > BigDecimal.stripTrailingZeros would not have adverse consequences on > fielded code, we could change its behavior despite being implemented that > way for about 9 years. >>> -Joe >>> >>>> Bruce >>>> >>>> On 7/02/2013 12:16 p.m., Stephen Colebourne wrote: >>>>> On 5 February 2013 09:09, Paul Sandoz wrote: >>>>>> This is one of those unfortunate cases where a bug can become a > feature. >>>>> I *really* don't see how. >>>>> >>>>> The method name is absolutely clear about its purpose. "Strip trailing >>>>> zeros". Anyone relying on it not stripping zeroes for zero needs their >>>>> head examining. >>>>> >>>>> This particular one just happens to be one that I've run across twice >>>>> and in both cases it required a workaround. I'd argue that there are >>>>> more people with undiscovered bugs in their code because the method is >>>>> buggy than people who would break were the method fixed. >>>>> >>>>> What bothers me even more is the desire expressed in this thread to >>>>> simply wish away bugs by redefining the documentation. If the method >>>>> name is clear enough, like in this case, then its a bug, and a >>>>> documentation change simply isn't the right solution. >>>>> Stephen >>>>> From jeremymanson at google.com Fri Feb 15 07:26:05 2013 From: jeremymanson at google.com (Jeremy Manson) Date: Thu, 14 Feb 2013 23:26:05 -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> Message-ID: a) I don't know what's going on behind the scenes, but if this sounds like a good idea to folks, can we open a bug and get the process otherwise rolling? b) Martin, where did the 4.2 restriction come from? Both Apple's site and the gcc wiki say that visibility support arrived in 4.0: http://gcc.gnu.org/wiki/Visibility https://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/CppRuntimeEnv/Articles/SymbolVisibility.html On Thu, Feb 14, 2013 at 3:01 PM, David DeHaven wrote: > > >>>> +#if defined(__GNUC__) && (__GNUC__ > 4) || (__GNUC__ == 4) && > >>>> (__GNUC_MINOR__ > 2) > >>>> + #define JNIEXPORT __attribute__((visibility("default"))) > >>>> + #define JNIIMPORT __attribute__((visibility("default"))) > >>> > >>> The default compiler in Xcode 4.1 is llvm-gcc 4.2, it seems. The > conditional above excludes that. Is this intentional? > >> > >> It's *is* gcc, with a LLVM backend. > > > > Yes, but it identifies itself as GCC 4.2, so the conditional doesn't > fire. > > I assume this was not the intent and the version check is just wrong. It may be that they deliberately stayed with gcc 4.2 to keep parity with clang, which only supports 4.2 (or it may not, because clang supports lots of 4.3+ features). > > > > If Xcode is fine with the #define, I suggest to drop the version check > completely. We already do not support compiling with GCC versions which > are so old that they lack visibility support. > > > If it were Mac only, I'd agree. > > The same header is currently used for all "unix-like" OS's (which may > change, if I have my way), so Solaris and Linux would also be affected. > Most Linux distros have used gcc 4 for quite a while now, I've no idea what > Solaris uses and embedded targets are a wild mishmash of whatever someone > manages to cobble together, so the simpler __GNUC__ check may still be > appropriate. > > -DrD- > > From Alan.Bateman at oracle.com Fri Feb 15 08:14:13 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Feb 2013 08:14:13 +0000 Subject: Review 8007703: Remove com.sun.servicetag API In-Reply-To: <511D73CA.90503@oracle.com> References: <511D73CA.90503@oracle.com> Message-ID: <511DEE55.4090109@oracle.com> On 14/02/2013 23:31, 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. > > 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/ Good to see this going away, the changes looks good to me. -Alan. From scolebourne at joda.org Fri Feb 15 08:15:51 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 15 Feb 2013 08:15:51 +0000 Subject: RFR - 6480539: BigDecimal.stripTrailingZeros() should specify no-op on zero BigDecimals In-Reply-To: <511DCD8A.60206@oracle.com> References: <51100C97.4040504@oracle.com> <51104CE4.10506@oracle.com> <1BA5F227-8369-4AC4-A108-165A094BD763@oracle.com> <511358A2.9090408@paradise.net.nz> <511560C3.9070009@oracle.com> <511DCD8A.60206@oracle.com> Message-ID: Thanks for continuing to look at this with Brian I also had this response on twitter - "my most hated Java bug, top 1" https://twitter.com/temerev/status/300204751931453440 Stephen On 15 February 2013 05:54, Joe Darcy wrote: > On 02/08/2013 02:37 PM, Stephen Colebourne wrote: >> >> We've established that it causes problems (me and Paul) and that likely >> workarounds of the bug would not be broken by a fix. > > > The adaptation you and Paul have for the current behavior would not be > impacted by a change in the behavior of stringTrailingZeros. That just > leaves all the other Java programmers to check with ;-) > > Since any angry emails on changing the behavior would come the way of Brian > and I (probably in a few years time), Brian has agreed to do some additional > research on how stripTrailingZeros is used in existing code to gauge what > impact there could be to altering the long-standing behavior. If the impact > is small, we can make the change in JDK 8. > > -Joe > > > >> >> The getMethods case is very different as the spec clearly allowed the >> behavior. Here the spec and method name are also clear on the expected >> behavior. The proposal would make the behavior out of line with the method >> name and of no earthly use to users. ie, as a user of that method, I would >> never be calling it for any reason other than to remove all the trailing >> zeroes. >> >> Mostly the JDK team gets it right. But not this time. >> >> Stephen >> >>> On 8 Feb 2013 20:32, "Joe Darcy" wrote: >>>> >>>> Hello, >>>> >>>> On 2/6/2013 11:32 PM, Bruce Chapman wrote: >>>>> >>>>> Stephen, In your case(s) would the workaround fail to work if the bug >> >> was fixed? >>>>> >>>>> Working around a bug is quite different to taking advantage of the >> >> buggy behaviour. If fixing the bug would break code that works around it >> that can be seen as a problem, while breaking code that relies on the bug >> is IMHO much less of an issue since anyone that does that is taking a >> known >> risk, or a risk that should reasonably be expected to be known. >>>>> >>>>> I am finding it hard to imagine a genuine attempt at a workaround that >> >> would not still work (though redundantly) if the bug was fixed. >>>>> >>>>> Also bear in mind that there are other implementations, and the >> >> signature and the javadoc are the spec. If you find behaviour that differs >> and take advantage of that behaviour then you are opening the possibility >> of it changing if either: you run with another implementation, or the bug >> gets fixed. >>>>> >>>>> While it is easy to contrive an example that would break if this bug >> >> were fixed, and it is possible (on the grounds that I cannot prove it is >> impossible) that some real code might break, it is hard to imagine a >> scenario where the author/owner of that broken code has any morally >> legitimate grounds for complaint in that case. >>>>> >>>>> I guess if you take the "This is one of those unfortunate cases where a >> >> bug can become a feature." approach to its logical conclusion then no bugs >> get fixed because there are no bugs, just a nice online list of newly >> discovered unexpected features. >>>> >>>> >>>> As noted earlier in this thread, we use a nuanced compatibility policy >> >> in evolving the JDK: >>>> >>>> >> >> http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html >>>> >>>> In particular, besides looking after source and binary compatibility, we >> >> also look to manage behavioral compatibility, that is, to be mindful of >> changing what a method does at runtime when called, even when the >> specification gives us leeway to do so. >>>> >>>> Let me relate an example of behavioral compatibility from JDK 7. The >> >> method Class.getMethods returns an array of Method objects for the Class >> and in part its javadoc has long stated: >>>> >>>> "The elements in the array returned are not sorted and are not in >> >> any particular order." >>>> >>>> Therefore, any caller of Class.getMethods relying on or assuming a >> >> particular order has a bug according to the specification. As a >> side-effect of permgen removal in JDK 7, the long-standing (and mostly >> stable) order of Method objects returned by HotSpot changed. As expected, >> some user applications and tests "broke" after this change went in. We >> received requests to "fix" the ordering of Class.getMethods, which we >> declined to do given the benefits of permgen removal and the clear >> specification that no ordering should be relied upon. Even though that >> change in getMethods is allowed by specification, it is out-of-bounds of >> what we would do an an update release but in-bounds for a platform release >> like JDK 7. >>>> >>>> The reason for this conservatism is because we value keeping the broad >> >> usage of the JDK working :-) >>>> >>>> Getting back to BigDecimal.stripTrailingZeros, we cannot inspect all >> >> usages of this method today, nor can we inspect all the future usages of >> BigDecimal.stripTrailingZeros that will be around before JDK 8 is adopted >> for the code in question. We know not everyone migrates to a new JDK >> release promptly; within the past two years I fielded a query/complaint >> about the behavior change in BigDecimal.toString made between 1.4.2 and >> JDK >> 5 and later. >>>> >>>> For these sorts of reasons, the default resolution when the >> >> specification and implementation conflict is to make the specification >> match the implementation. There are exceptions to this default. Given >> sufficient evidence that changing the behavior of >> BigDecimal.stripTrailingZeros would not have adverse consequences on >> fielded code, we could change its behavior despite being implemented that >> way for about 9 years. >>>> >>>> -Joe >>>> >>>>> Bruce >>>>> >>>>> On 7/02/2013 12:16 p.m., Stephen Colebourne wrote: >>>>>> >>>>>> On 5 February 2013 09:09, Paul Sandoz wrote: >>>>>>> >>>>>>> This is one of those unfortunate cases where a bug can become a >> >> feature. >>>>>> >>>>>> I *really* don't see how. >>>>>> >>>>>> The method name is absolutely clear about its purpose. "Strip trailing >>>>>> zeros". Anyone relying on it not stripping zeroes for zero needs their >>>>>> head examining. >>>>>> >>>>>> This particular one just happens to be one that I've run across twice >>>>>> and in both cases it required a workaround. I'd argue that there are >>>>>> more people with undiscovered bugs in their code because the method is >>>>>> buggy than people who would break were the method fixed. >>>>>> >>>>>> What bothers me even more is the desire expressed in this thread to >>>>>> simply wish away bugs by redefining the documentation. If the method >>>>>> name is clear enough, like in this case, then its a bug, and a >>>>>> documentation change simply isn't the right solution. >>>>>> Stephen >>>>>> > From erik.joelsson at oracle.com Fri Feb 15 09:12:54 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Feb 2013 10:12:54 +0100 Subject: Review 8007703: Remove com.sun.servicetag API In-Reply-To: <511D73CA.90503@oracle.com> References: <511D73CA.90503@oracle.com> Message-ID: <511DFC16.9030704@oracle.com> Looks good to me. /Erik On 2013-02-15 00:31, 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. > > 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 fweimer at redhat.com Fri Feb 15 09:19:14 2013 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 15 Feb 2013 10:19:14 +0100 Subject: Review 8007703: Remove com.sun.servicetag API In-Reply-To: <511D73CA.90503@oracle.com> References: <511D73CA.90503@oracle.com> Message-ID: <511DFD92.1080008@redhat.com> On 02/15/2013 12: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. Looks like langtools/src/share/classes/com/sun/tools/jdeps/resources/jdk.properties needs to be updated as well. -- Florian Weimer / Red Hat Product Security Team From Alan.Bateman at oracle.com Fri Feb 15 09:42:00 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Feb 2013 09:42:00 +0000 Subject: RFR JDK-8002390 problems moving files between zip file systems In-Reply-To: <511D2E3B.4030307@oracle.com> References: <511D2E3B.4030307@oracle.com> Message-ID: <511E02E8.8010500@oracle.com> On 14/02/2013 18:34, Mark Sheppard wrote: > Hi > > Please oblige and review the webrev at > > http://cr.openjdk.java.net/~sherman/8002390/webrev/ > > which addresses the issue raised in JDK-8002390 > > Description: While working with the new ZipFileSystem to modify the > contents of a zip file, encountered some issues. > The issue occurs when a file within a zip file is moved to a different > location within the same zip and a FileVisitor is invoked by > Files.walkFileTree the original (no longer existing file) will > attempted to be visited by ZipFileSystemProvider and throw a > NoSuchFileException. > This looks good to me too, thanks for tracking it down. A really minor nit but I would suggest indent the second line of bug numbers in basic.sh. -Alan. From david.holmes at oracle.com Fri Feb 15 09:53:27 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Feb 2013 19:53:27 +1000 Subject: Review 8007703: Remove com.sun.servicetag API In-Reply-To: <511D73CA.90503@oracle.com> References: <511D73CA.90503@oracle.com> Message-ID: <511E0597.2080902@oracle.com> 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 > 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 Alan.Bateman at oracle.com Fri Feb 15 09:58:43 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Feb 2013 09:58:43 +0000 Subject: Review 8007703: Remove com.sun.servicetag API In-Reply-To: <511DFD92.1080008@redhat.com> References: <511D73CA.90503@oracle.com> <511DFD92.1080008@redhat.com> Message-ID: <511E06D3.1060506@oracle.com> On 15/02/2013 09:19, Florian Weimer wrote: > On 02/15/2013 12: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. > > Looks like > langtools/src/share/classes/com/sun/tools/jdeps/resources/jdk.properties > needs to be updated as well. > Right, but that properties file is just temporary because the profiles work isn't in jdk yet. Once the profiles work gets to jdk8/tl then jdeps will be wired up (8005428 is tracking that). -Alan. From chris.hegarty at oracle.com Fri Feb 15 10:01:52 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 15 Feb 2013 10:01:52 +0000 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: <511E0790.4050305@oracle.com> Looks fine to me Mandy. On 15/02/2013 09:53, 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. Similarly the properties file for jdeps will need a small update. langtools/src/share/classes/com/sun/tools/jdeps/resources/jdk.properties -Chris. > > 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 chris.hegarty at oracle.com Fri Feb 15 10:18:44 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 15 Feb 2013 10:18:44 +0000 Subject: Review 8007703: Remove com.sun.servicetag API In-Reply-To: <511E06D3.1060506@oracle.com> References: <511D73CA.90503@oracle.com> <511DFD92.1080008@redhat.com> <511E06D3.1060506@oracle.com> Message-ID: <511E0B84.2020001@oracle.com> On 15/02/2013 09:58, Alan Bateman wrote: > On 15/02/2013 09:19, Florian Weimer wrote: >> On 02/15/2013 12: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. >> >> Looks like >> langtools/src/share/classes/com/sun/tools/jdeps/resources/jdk.properties >> needs to be updated as well. >> > Right, but that properties file is just temporary because the profiles > work isn't in jdk yet. Once the profiles work gets to jdk8/tl then jdeps > will be wired up (8005428 is tracking that). OK, thanks, -Chris. > > -Alan. > From david.holmes at oracle.com Fri Feb 15 10:20:07 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Feb 2013 20:20:07 +1000 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> Message-ID: <511E0BD7.4040603@oracle.com> On 15/02/2013 5:26 PM, Jeremy Manson wrote: > a) I don't know what's going on behind the scenes, but if this sounds > like a good idea to folks, can we open a bug and get the process > otherwise rolling? > > b) Martin, where did the 4.2 restriction come from? Both Apple's site > and the gcc wiki say that visibility support arrived in 4.0: From the original push for 6588413 in linux gcc.make: +# version 4 and above support fvisibility=hidden (matches jni_x86.h file) +# except 4.1.2 gives pointless warnings that can't be disabled (afaik) So it was limited on x86 to >2 (which I think was a typo: intended to be >=2 or >1 ?) Of course the bsd port copied the linux file. David > http://gcc.gnu.org/wiki/Visibility > https://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/CppRuntimeEnv/Articles/SymbolVisibility.html > > > On Thu, Feb 14, 2013 at 3:01 PM, David DeHaven > wrote: > > > >>>> +#if defined(__GNUC__) && (__GNUC__ > 4) || (__GNUC__ == 4) && > >>>> (__GNUC_MINOR__ > 2) > >>>> + #define JNIEXPORT __attribute__((visibility("default"))) > >>>> + #define JNIIMPORT __attribute__((visibility("default"))) > >>> > >>> The default compiler in Xcode 4.1 is llvm-gcc 4.2, it seems. > The conditional above excludes that. Is this intentional? > >> > >> It's *is* gcc, with a LLVM backend. > > > > Yes, but it identifies itself as GCC 4.2, so the conditional > doesn't fire. > > I assume this was not the intent and the version check is just wrong. > > > It may be that they deliberately stayed with gcc 4.2 to keep parity with > clang, which only supports 4.2 (or it may not, because clang supports > lots of 4.3+ features). > > > > > If Xcode is fine with the #define, I suggest to drop the version > check completely. We already do not support compiling with GCC > versions which are so old that they lack visibility support. > > > If it were Mac only, I'd agree. > > The same header is currently used for all "unix-like" OS's (which > may change, if I have my way), so Solaris and Linux would also be > affected. Most Linux distros have used gcc 4 for quite a while now, > I've no idea what Solaris uses and embedded targets are a wild > mishmash of whatever someone manages to cobble together, so the > simpler __GNUC__ check may still be appropriate. > > -DrD- > > From chris.hegarty at oracle.com Fri Feb 15 11:07:39 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 15 Feb 2013 11:07:39 +0000 Subject: hg: jdk8/tl/jdk: 8008223: java/net/BindException/Test.java fails rarely Message-ID: <20130215110832.15E1847AE4@hg.openjdk.java.net> Changeset: 048637b40787 Author: chegar Date: 2013-02-15 11:06 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/048637b40787 8008223: java/net/BindException/Test.java fails rarely Reviewed-by: khazra, alanb ! test/java/net/BindException/Test.java From kasperni at gmail.com Fri Feb 15 13:53:21 2013 From: kasperni at gmail.com (Kasper Nielsen) Date: Fri, 15 Feb 2013 14:53:21 +0100 Subject: java.lang.reflect.AnnotatedElement changes Message-ID: Hi, I know AnnotatedElement is not a common class to implement outside of the JDK. But the interface introduces some new methods that will break existing code. For example, Guava, which has the Parameter class ( https://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/reflect/Parameter.java ) - Kasper From kasperni at gmail.com Fri Feb 15 13:56:41 2013 From: kasperni at gmail.com (Kasper Nielsen) Date: Fri, 15 Feb 2013 14:56:41 +0100 Subject: java.lang.reflect.AnnotatedElement changes In-Reply-To: References: Message-ID: by introduces, I mean the additional methods going into Java8. On Fri, Feb 15, 2013 at 2:53 PM, Kasper Nielsen wrote: > Hi, > > I know AnnotatedElement is not a common class to implement outside of the > JDK. But the interface introduces some new methods that will break existing > code. > > For example, Guava, which has the Parameter class > ( > https://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/reflect/Parameter.java > ) > > - Kasper > > From david.holmes at oracle.com Fri Feb 15 14:10:22 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 16 Feb 2013 00:10:22 +1000 Subject: java.lang.reflect.AnnotatedElement changes In-Reply-To: References: Message-ID: <511E41CE.7060601@oracle.com> On 15/02/2013 11:53 PM, Kasper Nielsen wrote: > Hi, > > I know AnnotatedElement is not a common class to implement outside of the > JDK. But the interface introduces some new methods that will break existing > code. I must admit I am surprised as I thought that any new methods on interfaces would have to have default implementations to avoid this kind of breakage. Seems to me that defaults should be possible for those new methods. Perhaps this is still a work in progress? David ----- > For example, Guava, which has the Parameter class > ( > https://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/reflect/Parameter.java > ) > > - Kasper > From Alan.Bateman at oracle.com Fri Feb 15 14:15:06 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Feb 2013 14:15:06 +0000 Subject: java.lang.reflect.AnnotatedElement changes In-Reply-To: References: Message-ID: <511E42EA.5000304@oracle.com> On 15/02/2013 13:53, Kasper Nielsen wrote: > Hi, > > I know AnnotatedElement is not a common class to implement outside of the > JDK. But the interface introduces some new methods that will break existing > code. > Yes, this needs to be considered to avoid the source compatibility issue. Here's the bug tracking it: http://bugs.sun.com/view_bug.do?bug_id=8005294 -Alan From mandy.chung at oracle.com Fri Feb 15 15:56:28 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 15 Feb 2013 07:56:28 -0800 Subject: Review 8007703: Remove com.sun.servicetag API In-Reply-To: <511E06D3.1060506@oracle.com> References: <511D73CA.90503@oracle.com> <511DFD92.1080008@redhat.com> <511E06D3.1060506@oracle.com> Message-ID: <511E5AAC.5070601@oracle.com> On 2/15/2013 1:58 AM, Alan Bateman wrote: > On 15/02/2013 09:19, Florian Weimer wrote: >> On 02/15/2013 12: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. >> >> Looks like >> langtools/src/share/classes/com/sun/tools/jdeps/resources/jdk.properties >> needs to be updated as well. >> > Right, but that properties file is just temporary because the profiles > work isn't in jdk yet. Once the profiles work gets to jdk8/tl then > jdeps will be wired up (8005428 is tracking that). Right. jdk.properties should go away when I fix 8005428 and hence I leave that properties file as it is (sorry I should have mentioned that previously). Thanks Mandy From mandy.chung at oracle.com Fri Feb 15 16:07:27 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 15 Feb 2013 08:07:27 -0800 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: <511E5D3F.2090900@oracle.com> On 2/15/2013 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. > Thanks David. That's what I understand from the profiles makefiles and it won't cause any build problem. I'll file a follow-up CR to adjust profile-rtjar-includes.txt. 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 david.dehaven at oracle.com Fri Feb 15 16:18:16 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 15 Feb 2013 08:18:16 -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> Message-ID: > a) I don't know what's going on behind the scenes, but if this sounds like a good idea to folks, can we open a bug and get the process otherwise rolling? > > b) Martin, where did the 4.2 restriction come from? Both Apple's site and the gcc wiki say that visibility support arrived in 4.0: > > http://gcc.gnu.org/wiki/Visibility > https://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/CppRuntimeEnv/Articles/SymbolVisibility.html I've been poking at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181710 in my spare time (I've not a lot of these days). That issue is, IMHO, an even more glaring issue for what should be obvious reasons. The best solution seems to be to create a new set of headers for export in jdk/src/macosx/javavm/export since the implementation is very system dependent. I could roll this change as part of that as well as clean up some of the #if flow control that would no longer have any effect. I have that mostly done, but I need more time for testing the header and doing JPRT runs to be sure I haven't broken other platforms in the process. That leaves the solaris headers and a separate issue would have to be filed to fix hotspot. -DrD- From david.dehaven at oracle.com Fri Feb 15 16:19:09 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 15 Feb 2013 08:19:09 -0800 Subject: Define JNIEXPORT as visibility default with GCC? In-Reply-To: <511E0BD7.4040603@oracle.com> References: <511CAE4C.2000002@redhat.com> <4974FD20-B6DD-40F5-A7E9-B78F09E9C2A1@oracle.com> <511D5A8F.7050403@redhat.com> <511E0BD7.4040603@oracle.com> Message-ID: <40AB45AA-2540-4E55-9F6D-92E2078A663C@oracle.com> >> a) I don't know what's going on behind the scenes, but if this sounds >> like a good idea to folks, can we open a bug and get the process >> otherwise rolling? >> >> b) Martin, where did the 4.2 restriction come from? Both Apple's site >> and the gcc wiki say that visibility support arrived in 4.0: > > From the original push for 6588413 in linux gcc.make: > > +# version 4 and above support fvisibility=hidden (matches jni_x86.h file) > +# except 4.1.2 gives pointless warnings that can't be disabled (afaik) > > So it was limited on x86 to >2 (which I think was a typo: intended to be >=2 or >1 ?) > > Of course the bsd port copied the linux file. That makes sense. Is 4.1.2 in use any more? Was the warning due to -fvisibility=hidden or the __attribute__? The attribute should be benign as it's the default setting unless you explicitly set visibility when running the compiler, it only has effect when you compile with visibility != default so I see no harm in using it. -DrD- From jonathan.gibbons at oracle.com Fri Feb 15 16:29:20 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 15 Feb 2013 16:29:20 +0000 Subject: hg: jdk8/tl/langtools: 8007052: javap should include the descriptor for a method in verbose mode Message-ID: <20130215162925.78AF547AEC@hg.openjdk.java.net> Changeset: 040f02711b73 Author: jjg Date: 2013-02-15 08:28 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/040f02711b73 8007052: javap should include the descriptor for a method in verbose mode Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javap/ClassWriter.java ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/com/sun/tools/javap/Options.java + test/tools/javap/DescriptorTest.java From jeremymanson at google.com Fri Feb 15 16:41:14 2013 From: jeremymanson at google.com (Jeremy Manson) Date: Fri, 15 Feb 2013 08:41:14 -0800 Subject: Define JNIEXPORT as visibility default with GCC? In-Reply-To: <511E0BD7.4040603@oracle.com> References: <511CAE4C.2000002@redhat.com> <4974FD20-B6DD-40F5-A7E9-B78F09E9C2A1@oracle.com> <511D5A8F.7050403@redhat.com> <511E0BD7.4040603@oracle.com> Message-ID: Can we just blacklist 4.1.2 explicitly? Jeremy On Fri, Feb 15, 2013 at 2:20 AM, David Holmes wrote: > On 15/02/2013 5:26 PM, Jeremy Manson wrote: > >> a) I don't know what's going on behind the scenes, but if this sounds >> like a good idea to folks, can we open a bug and get the process >> otherwise rolling? >> >> b) Martin, where did the 4.2 restriction come from? Both Apple's site >> and the gcc wiki say that visibility support arrived in 4.0: >> > > From the original push for 6588413 in linux gcc.make: > > +# version 4 and above support fvisibility=hidden (matches jni_x86.h file) > +# except 4.1.2 gives pointless warnings that can't be disabled (afaik) > > So it was limited on x86 to >2 (which I think was a typo: intended to be > >=2 or >1 ?) > > Of course the bsd port copied the linux file. > > David > > http://gcc.gnu.org/wiki/**Visibility >> https://developer.apple.com/**library/mac/#documentation/** >> DeveloperTools/Conceptual/**CppRuntimeEnv/Articles/** >> SymbolVisibility.html >> >> >> On Thu, Feb 14, 2013 at 3:01 PM, David DeHaven > >> wrote: >> >> >> >>>> +#if defined(__GNUC__) && (__GNUC__ > 4) || (__GNUC__ == 4) && >> >>>> (__GNUC_MINOR__ > 2) >> >>>> + #define JNIEXPORT __attribute__((visibility("** >> default"))) >> >>>> + #define JNIIMPORT __attribute__((visibility("** >> default"))) >> >>> >> >>> The default compiler in Xcode 4.1 is llvm-gcc 4.2, it seems. >> The conditional above excludes that. Is this intentional? >> >> >> >> It's *is* gcc, with a LLVM backend. >> > >> > Yes, but it identifies itself as GCC 4.2, so the conditional >> doesn't fire. >> >> I assume this was not the intent and the version check is just wrong. >> >> >> It may be that they deliberately stayed with gcc 4.2 to keep parity with >> clang, which only supports 4.2 (or it may not, because clang supports >> lots of 4.3+ features). >> >> >> >> > If Xcode is fine with the #define, I suggest to drop the version >> check completely. We already do not support compiling with GCC >> versions which are so old that they lack visibility support. >> >> >> If it were Mac only, I'd agree. >> >> The same header is currently used for all "unix-like" OS's (which >> may change, if I have my way), so Solaris and Linux would also be >> affected. Most Linux distros have used gcc 4 for quite a while now, >> I've no idea what Solaris uses and embedded targets are a wild >> mishmash of whatever someone manages to cobble together, so the >> simpler __GNUC__ check may still be appropriate. >> >> -DrD- >> >> >> From maurizio.cimadamore at oracle.com Fri Feb 15 16:38:04 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 15 Feb 2013 16:38:04 +0000 Subject: hg: jdk8/tl/langtools: 6 new changesets Message-ID: <20130215163819.E60CC47AEE@hg.openjdk.java.net> Changeset: 0baaae675b19 Author: mcimadamore Date: 2013-02-15 16:28 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0baaae675b19 8006749: compiler does not allow Object protected methods to be used in lambda Summary: Check.checkFunctionalInterface should take into account 'fake' override Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/lambda/LambdaConv26.java Changeset: f6e667f52af4 Author: mcimadamore Date: 2013-02-15 16:28 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f6e667f52af4 8007285: AbstractMethodError instead of compile-time error when method reference with super and abstract Summary: Missing abstractness check on super rmethod references Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/lambda/MethodReference62.java + test/tools/javac/lambda/MethodReference62.out Changeset: 4ff468de829d Author: mcimadamore Date: 2013-02-15 16:29 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4ff468de829d 8007462: Fix provisional applicability for method references Summary: Add speculative arity-based check to rule out potential candidates when stuck reference is passed to method Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/IncompatibleArgTypesInMethodRef.java + test/tools/javac/lambda/TargetType60.java + test/tools/javac/lambda/TargetType60.out Changeset: 3cd997b9fd84 Author: mcimadamore Date: 2013-02-15 16:30 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3cd997b9fd84 8007535: Compiler crashes on @FunctionalInterface used on interface with two inherited methods with same signatures Summary: Bad check in Types.interfaceCandidates Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/lambda/FunctionalInterfaceAnno02.java Changeset: 186023614cd3 Author: mcimadamore Date: 2013-02-15 16:31 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/186023614cd3 8007427: Annotation element as '_' gives compiler error instead of a warning 8007401: Write test to check for generation of warnings when '_' is used as an identifier Summary: Extended identifier production not used in annotation values Reviewed-by: jjg Contributed-by: sonali.goel at oracle.com ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/lambda/IdentifierTest.java + test/tools/javac/lambda/IdentifierTest.out Changeset: 258c72fa7fa2 Author: mcimadamore Date: 2013-02-15 16:37 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/258c72fa7fa2 Merge From fweimer at redhat.com Fri Feb 15 16:46:53 2013 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 15 Feb 2013 17:46:53 +0100 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> Message-ID: <511E667D.2000700@redhat.com> On 02/15/2013 05:41 PM, Jeremy Manson wrote: > Can we just blacklist 4.1.2 explicitly? Folks, per README-build.html, the minimum GCC version is 4.2 on MacOS X and 4.3 everywhere else. Do we really have to bother with 4.1.2 at this point? -- Florian Weimer / Red Hat Product Security Team From maurizio.cimadamore at oracle.com Fri Feb 15 18:13:23 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 15 Feb 2013 18:13:23 +0000 Subject: hg: jdk8/tl/langtools: 8008309: TargetType60 fails because of bad golden file Message-ID: <20130215181326.4143947AFE@hg.openjdk.java.net> Changeset: da2f7dd53915 Author: mcimadamore Date: 2013-02-15 18:13 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/da2f7dd53915 8008309: TargetType60 fails because of bad golden file Summary: bad golden file Reviewed-by: jjg ! test/tools/javac/lambda/TargetType60.out From jonathan.gibbons at oracle.com Fri Feb 15 19:26:16 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 15 Feb 2013 19:26:16 +0000 Subject: hg: jdk8/tl/langtools: 8008313: 8007052 breaks test/tools/javap/MethodParameters.java Message-ID: <20130215192621.D6DDB47B01@hg.openjdk.java.net> Changeset: 9fb4f223a90d Author: jjg Date: 2013-02-15 11:26 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9fb4f223a90d 8008313: 8007052 breaks test/tools/javap/MethodParameters.java Reviewed-by: darcy ! test/tools/javap/MethodParameters.java From mike.duigou at oracle.com Fri Feb 15 20:13:57 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 15 Feb 2013 12:13:57 -0800 Subject: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda Libraries Message-ID: <2CB90323-8862-4735-BC75-7A1EB3C8276B@oracle.com> Hello All; This patch introduces a number of new functional interfaces for use by the lambda libraries. Also included are some name changes following JSR-225 EG review. The new interfaces are: BiConsumer BiFunction BiPredicate BooleanSupplier DoublePredicate IntPredicate LongPredicate ObjDoubleConsumer ObjIntConsumer ObjLongConsumer ToDoubleBiFunction ToDoubleFunction ToIntBiFunction ToIntFunction ToLongBiFunction ToLongFunction Renames: Block -> Consumer BiBlock -> BiConsumer IntBlock -> IntConsumer DoubleBlock -> LongConsumer LongBlock -> LongConsumer UnaryOperator.operate -> UnaryOperator.apply LongUnaryOperator.operateAsLong -> LongUnaryOperator.applyAsLong DoubleUnaryOperator.operateAsDouble -> DoubleUnaryOperator.applyAsDouble IntUnaryOperator.operateAsInt -> IntUnaryOperator.applyAsInt LongBinaryOperator.operateAsLong -> LongBinaryOperator.applyAsLong DoubleBinaryOperator.operateAsDouble -> DoubleBinaryOperator.applyAsDouble IntBinaryOperator.operateAsInt -> IntBinaryOperator.applyAsInt All of the changes outside the java.util.function package are made to accommodate these renamings. The webrev is located at: http://cr.openjdk.java.net/~mduigou/JDK-8004561/1/webrev/ and specdiff for the java.util.function package is at: http://cr.openjdk.java.net/~mduigou/JDK-8004561/1/specdiff/ Thanks! Mike From eric.mccorkle at oracle.com Fri Feb 15 20:23:25 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Fri, 15 Feb 2013 15:23:25 -0500 Subject: Review request for JDK-8008312: Re-enable MethodParameter tests in JDK Message-ID: <511E993D.2000404@oracle.com> Hi, Please review this simple patch, which re-enables the JDK end-to-end tests for parameter reflection. It also fixes a small error in toString The webrev is here http://cr.openjdk.java.net/~emc/8008312/ Thanks, Eric From martinrb at google.com Fri Feb 15 20:39:58 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 15 Feb 2013 12:39:58 -0800 Subject: Review: 4396272 - Parsing doubles fails to follow IEEE for largest decimal that should yield 0 In-Reply-To: <4412AB7C-A91F-48A9-ACF2-3816480C28E1@oracle.com> References: <4412AB7C-A91F-48A9-ACF2-3816480C28E1@oracle.com> Message-ID: On Thu, Feb 14, 2013 at 5:23 PM, Brian Burkhalter < brian.burkhalter at oracle.com> wrote: > The patch below is as submitted to OpenJDK bugzilla but with enhanced > comments. Please provide a bug URL. From joe.darcy at oracle.com Fri Feb 15 21:48:53 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 15 Feb 2013 13:48:53 -0800 Subject: Review request for JDK-8008312: Re-enable MethodParameter tests in JDK In-Reply-To: <511E993D.2000404@oracle.com> References: <511E993D.2000404@oracle.com> Message-ID: <511EAD45.9080803@oracle.com> Hi Eric, I'll approve this change as-is, but I'd prefer if the test were written in the style of using annotations to record the expected value. Cheers, -Joe On 2/15/2013 12:23 PM, Eric McCorkle wrote: > Hi, > > Please review this simple patch, which re-enables the JDK end-to-end > tests for parameter reflection. > > It also fixes a small error in toString > > The webrev is here > http://cr.openjdk.java.net/~emc/8008312/ > > Thanks, > Eric From martinrb at google.com Fri Feb 15 23:49:24 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 15 Feb 2013 15:49:24 -0800 Subject: java.lang.reflect.AnnotatedElement changes In-Reply-To: <511E41CE.7060601@oracle.com> References: <511E41CE.7060601@oracle.com> Message-ID: On Fri, Feb 15, 2013 at 6:10 AM, David Holmes wrote: > On 15/02/2013 11:53 PM, Kasper Nielsen wrote: > >> Hi, >> >> I know AnnotatedElement is not a common class to implement outside of the >> JDK. But the interface introduces some new methods that will break >> existing >> code. >> > > I must admit I am surprised as I thought that any new methods on > interfaces would have to have default implementations to avoid this kind of > breakage. Seems to me that defaults should be possible for those new > methods. Perhaps this is still a work in progress? > OpenJDK could invest more in static analysis tools. Here it would be good to use a tool to audit all interfaces to check that new methods without defaults have not been added. From joe.darcy at oracle.com Sat Feb 16 00:25:15 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Fri, 15 Feb 2013 16:25:15 -0800 Subject: java.lang.reflect.AnnotatedElement changes In-Reply-To: References: <511E41CE.7060601@oracle.com> Message-ID: <511ED1EB.1030806@oracle.com> On 2/15/2013 3:49 PM, Martin Buchholz wrote: > On Fri, Feb 15, 2013 at 6:10 AM, David Holmes wrote: > >> On 15/02/2013 11:53 PM, Kasper Nielsen wrote: >> >>> Hi, >>> >>> I know AnnotatedElement is not a common class to implement outside of the >>> JDK. But the interface introduces some new methods that will break >>> existing >>> code. >>> >> I must admit I am surprised as I thought that any new methods on >> interfaces would have to have default implementations to avoid this kind of >> breakage. Seems to me that defaults should be possible for those new >> methods. Perhaps this is still a work in progress? >> > OpenJDK could invest more in static analysis tools. Here it would be good > to use a tool to audit all interfaces to check that new methods without > defaults have not been added. Hi Martin, FWIW, with my ccc hat on, I've previously (internally) asked the JCK team to run such reports. IIRC, the methods on AnnotatedElement where the only potentially problematic ones made so far. (We'll be added methods to interfaces over in javax.lang.model.*, but we can't use default methods over than and we explicitly warn implementers and user of the API of the potential for new methods.) Thanks, -Joe From martinrb at google.com Sat Feb 16 00:34:08 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 15 Feb 2013 16:34:08 -0800 Subject: java.lang.reflect.AnnotatedElement changes In-Reply-To: <511ED1EB.1030806@oracle.com> References: <511E41CE.7060601@oracle.com> <511ED1EB.1030806@oracle.com> Message-ID: Thanks, sounds like you have this potential problem under control. Hi Martin, > > FWIW, with my ccc hat on, I've previously (internally) asked the JCK team > to run such reports. IIRC, the methods on AnnotatedElement where the only > potentially problematic ones made so far. (We'll be added methods to > interfaces over in javax.lang.model.*, but we can't use default methods > over than and we explicitly warn implementers and user of the API of the > potential for new methods.) > From brian.burkhalter at oracle.com Sat Feb 16 00:41:32 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 15 Feb 2013 16:41:32 -0800 Subject: [PATCH] Sunbug 7131192: Optimize BigInteger.doubleValue(), floatValue() In-Reply-To: <511ED22B.8030800@oracle.com> References: <511ED22B.8030800@oracle.com> Message-ID: Hi Louis, After the two issues for which I've posted review requests (6480539 - stripTrailingZeros(), 4396272 - Parsing doubles fails to follow IEEE) are resolved, issue 7131192 is currently very near the head of my queue. Given that I still have a ways to go to get up to speed on this entire topic area and code base, I would hesitate to give a date estimate just yet. Brian > Any update on when this could get reviewed? > > > On Thu, Dec 13, 2012 at 3:36 PM, Louis Wasserman wrote: > Hi, > > I'm working at Google now, but I'd like to revive this patch as a contribution from Google. At the moment, what's mainly needed is review for http://bugs.sun.com/view_bug.do?bug_id=7192954, the fix to Float.parseFloat's rounding behavior, before we can go anywhere with the patch to optimize BigInteger.floatValue() and doubleValue(). > Would anyone be able to review that patch so these can start moving forward? > > Thanks, > Louis Wasserman > Java Core Libraries Team @ Google > guava-libraries.googlecode.com > > ---------- Forwarded message ---------- > From: Louis Wasserman > Date: Sat, Jul 14, 2012 at 5:32 AM > Subject: Re: [PATCH] Sunbug 7131192: Optimize BigInteger.doubleValue(), floatValue() > To: Joseph Darcy > Cc: Andrew Haley , core-libs-dev at openjdk.java.net > > > Understood. FYI, testing for this change revealed a bug in Float.parseFloat, a patch for which has been separately sent to this mailing list under the subject line "[PATCH] Sunbug 6358355: Rounding error in Float.parseFloat". (As a result, the BigInteger patch may fail some of the provided tests at the moment, but that is truly because the reference implementation it's being tested against is faulty.) > > Louis Wasserman > wasserman.louis at gmail.com > http://profiles.google.com/wasserman.louis > > > On Sat, Jul 14, 2012 at 2:20 AM, Joseph Darcy wrote: > Hello, > > Thanks for the patch Louis. > > > On 7/12/2012 3:21 AM, Andrew Haley wrote: > On 07/12/2012 10:32 AM, Louis Wasserman wrote: > It was attached to the previous message? I don't know if this list works > with attachments. Alternately, the patch was attached here: > https://bugs.openjdk.java.net/show_bug.cgi?id=100222 > > I'm not sure what you mean by double-rounding bugs, though. It's > not difficult to actually implement the HALF_EVEN rounding behavior > with bit twiddling. > Sure, as long as you've thought about it and done it carefully. The > bit twiddling is easy to do, and easy to get wrong. > > > From the supplied patch it looks like you've done a good job, but > there was no way to tell without it. I presume the listserv dropped > it on the floor. > > Andrew. > > I've taken a quick look at the patch. The concept for the change is good; the current path of converting to float/double through a string is a simple but very roundabout way to accomplish this task. > > Unfortunately, I'm saturated with the JDK bug migration [1] and will continue to be saturated for at least several more weeks so I won't be able to take a more detailed look at the patch for a while. I suspect some more directly test cases will be needed to test tricky rounding situations. > > Thanks, > > -Joe > > [1] https://blogs.oracle.com/darcy/entry/moving_monarchs_dragons > > > > > > -- > Louis Wasserman > > > > -- > Louis Wasserman > > From robert.field at oracle.com Sat Feb 16 02:42:24 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Sat, 16 Feb 2013 02:42:24 +0000 Subject: hg: jdk8/tl/langtools: 8004969: Generate $deserializeLambda$ method; ... Message-ID: <20130216024229.22EFB47B22@hg.openjdk.java.net> Changeset: f1f605f85850 Author: rfield Date: 2013-02-15 18:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f1f605f85850 8004969: Generate $deserializeLambda$ method 8006763: super in method reference used in anonymous class - ClassFormatError is produced 8005632: Inner classes within lambdas cause build failures 8005653: Lambdas containing inner classes referencing external type variables do not correctly parameterize the inner classes Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/util/Names.java + test/tools/javac/lambda/LambdaInnerTypeVarArgs.java + test/tools/javac/lambda/LambdaInnerTypeVarReflect.java + test/tools/javac/lambda/MethodReference61.java From robert.field at oracle.com Sat Feb 16 20:38:08 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Sat, 16 Feb 2013 20:38:08 +0000 Subject: hg: jdk8/tl/jdk: 8004970: Implement serialization in the lambda metafactory Message-ID: <20130216203829.DCAEC47B2F@hg.openjdk.java.net> Changeset: 7748ffdca16a Author: rfield Date: 2013-02-16 12:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7748ffdca16a 8004970: Implement serialization in the lambda metafactory Reviewed-by: forax ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/share/classes/java/lang/invoke/LambdaMetafactory.java ! src/share/classes/java/lang/invoke/MethodHandleInfo.java + src/share/classes/java/lang/invoke/SerializedLambda.java ! src/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java + test/java/lang/invoke/lambda/LambdaSerialization.java From xueming.shen at oracle.com Sat Feb 16 22:26:28 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Sat, 16 Feb 2013 14:26:28 -0800 Subject: CodeReview Request for 8008348: The leftover jdk/make/tools/javazic causes build problems with hs25-b19 control job, Message-ID: <51200794.2090305@oracle.com> Hi, It appears the leftover jdk/make/tools/javazic causes build problems with hs25-b19 control job. The "javazic" has been removed in jdk/make/tools/Makefile as the target, but with the new build system it compiles everything in jdk/make/tools. This works when the boot JDK is jdk7 but with a boot cycle build then it builds the JDK a second time with the newly built JDK, which will fail due to current update in src/share/classes/sun/util/calendar/ZoneInfoFile.java for the threeten work for #8007572. The change is to complete remove the jdk/make/tools/javazic and the corresponding old javazic source code from the repo. http://cr.openjdk.java.net/~sherman/8008348/ Thanks, -Sherman From Alan.Bateman at oracle.com Sat Feb 16 23:12:06 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 16 Feb 2013 23:12:06 +0000 Subject: CodeReview Request for 8008348: The leftover jdk/make/tools/javazic causes build problems with hs25-b19 control job, In-Reply-To: <51200794.2090305@oracle.com> References: <51200794.2090305@oracle.com> Message-ID: <51201246.1050307@oracle.com> On 16/02/2013 22:26, Xueming Shen wrote: > Hi, > > It appears the leftover jdk/make/tools/javazic causes build problems > with hs25-b19 control job. > > The "javazic" has been removed in jdk/make/tools/Makefile as the > target, but with the new build > system it compiles everything in jdk/make/tools. This works when the > boot JDK is jdk7 but with > a boot cycle build then it builds the JDK a second time with the newly > built JDK, which will fail due > to current update in > src/share/classes/sun/util/calendar/ZoneInfoFile.java for the threeten > work > for #8007572. > > The change is to complete remove the jdk/make/tools/javazic and the > corresponding old javazic > source code from the repo. > > http://cr.openjdk.java.net/~sherman/8008348/ This looks good to me and I can confirm that boot cycle builds (bootcycle-images target) works again once javazic is removed. -Alan From xueming.shen at oracle.com Sun Feb 17 01:03:07 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Sun, 17 Feb 2013 01:03:07 +0000 Subject: hg: jdk8/tl/jdk: 8008348: The leftover jdk/make/tools/javazic causes build problems with hs25-b19 control Message-ID: <20130217010318.E96E247B30@hg.openjdk.java.net> Changeset: 43726ed11fb3 Author: sherman Date: 2013-02-17 01:01 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/43726ed11fb3 8008348: The leftover jdk/make/tools/javazic causes build problems with hs25-b19 control Summary: To remove jdk/make/tools/javazic from the jdk repo Reviewed-by: alanb - 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 From david.holmes at oracle.com Sun Feb 17 22:55:33 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 18 Feb 2013 08:55:33 +1000 Subject: Define JNIEXPORT as visibility default with GCC? In-Reply-To: <511E667D.2000700@redhat.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> Message-ID: <51215FE5.1080405@oracle.com> On 16/02/2013 2:46 AM, Florian Weimer wrote: > On 02/15/2013 05:41 PM, Jeremy Manson wrote: >> Can we just blacklist 4.1.2 explicitly? > > Folks, per README-build.html, the minimum GCC version is 4.2 on MacOS X > and 4.3 everywhere else. Do we really have to bother with 4.1.2 at this > point? There are ports that still use these older gcc versions. David From nicole.haenni at gmail.com Sun Feb 17 23:14:48 2013 From: nicole.haenni at gmail.com (Nicole Haenni) Date: Mon, 18 Feb 2013 00:14:48 +0100 Subject: Survey for framework and library developers: "Information needs in software ecosystems" In-Reply-To: References: Message-ID: 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 From alan.bateman at oracle.com Mon Feb 18 08:16:50 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 18 Feb 2013 08:16:50 +0000 Subject: hg: jdk8/tl/jdk: 6429204: (se) Concurrent Selector.register and SelectionKey.interestOps can ignore interestOps Message-ID: <20130218081708.B0DB147B4D@hg.openjdk.java.net> Changeset: bcde0486261e Author: dingxmin Date: 2013-02-18 08:14 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bcde0486261e 6429204: (se) Concurrent Selector.register and SelectionKey.interestOps can ignore interestOps Reviewed-by: alanb ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java + test/java/nio/channels/Selector/RacyDeregister.java From fweimer at redhat.com Mon Feb 18 09:36:12 2013 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 18 Feb 2013 10:36:12 +0100 Subject: Define JNIEXPORT as visibility default with GCC? In-Reply-To: <51215FE5.1080405@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> Message-ID: <5121F60C.5040004@redhat.com> On 02/17/2013 11:55 PM, David Holmes wrote: > On 16/02/2013 2:46 AM, Florian Weimer wrote: >> On 02/15/2013 05:41 PM, Jeremy Manson wrote: >>> Can we just blacklist 4.1.2 explicitly? >> >> Folks, per README-build.html, the minimum GCC version is 4.2 on MacOS X >> and 4.3 everywhere else. Do we really have to bother with 4.1.2 at this >> point? > > There are ports that still use these older gcc versions. Oh. Perhaps this information can be added to README-builds.html? -- Florian Weimer / Red Hat Product Security Team From vicente.romero at oracle.com Mon Feb 18 14:34:41 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Mon, 18 Feb 2013 14:34:41 +0000 Subject: hg: jdk8/tl/langtools: 6563143: javac should issue a warning for overriding equals without hashCode Message-ID: <20130218143447.2E7C347B5F@hg.openjdk.java.net> Changeset: 2620c953e9fe Author: vromero Date: 2013-02-18 14:33 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2620c953e9fe 6563143: javac should issue a warning for overriding equals without hashCode Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Lint.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/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/sjavac/comp/Dependencies.java + test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.java + test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.out ! test/tools/javac/diags/examples.not-yet.txt From chris.hegarty at oracle.com Mon Feb 18 14:43:58 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 18 Feb 2013 14:43:58 +0000 Subject: RFR 8008378: FJP.commonPool creation within PrivilegedAction, and support parallelism 0 (JEP 155) Message-ID: <51223E2E.3000402@oracle.com> As usual, changes from Doug, with some additional tests from me. 1. Access and parse properties, as well as construct common pool in a PrivilegedAction, explicitly ignoring any unparseable settings. This way any racy static creation by unprivileged clients rather than usual channels won't fail, while at the same time allowing better advice about managed construction (as in EE frameworks) to do anything that causes it to exist before starting other processing, as well as to, if applicable provide a thread-factory that itself uses PrivilegedAction or some such. This way, these frameworks remain in control over how much parallelism their users get. 2. For *only* the particular method FJP.execute(Runnable) (which is not usually used in FJ but must be supported), force an exception thrown by the Runnable to cause the corresponding worker to die (and possibly be replaced). This is among other things a small abuse guard: The normal FJ capture and reporting of an exception in the task object will never be seen, so at least the UncaughtExceptionHandler will trigger, at the cost of throwing away and creating a thread (that we normally otherwise avoid). Specdiff: http://cr.openjdk.java.net/~chegar/8008378/specdiff.00/overview-summary.html Webrev: http://cr.openjdk.java.net/~chegar/8008378/webrev.00/webrev/ -Chris. From alexey.utkin at oracle.com Mon Feb 18 15:16:08 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Mon, 18 Feb 2013 19:16:08 +0400 Subject: Request for review: 8007454 Wrong parameters in Win32 native code. In-Reply-To: <510FC4CD.2060208@oracle.com> References: <50AE2E0A.7020609@oracle.com> <510FA969.303@oracle.com> <510FC4CD.2060208@oracle.com> Message-ID: <512245B8.7060005@oracle.com> On 04.02.2013 18:25, Alan Bateman wrote: > On 04/02/2013 12:28, Alexey Utkin wrote: >> Hi, >> Please review the fix. >> >> Bug description: >> http://bugs.sun.com/view_bug.do?bug_id=8007454 >> https://jbs.oracle.com/bugs/browse/JDK-8007454 >> >> The suggested fix: >> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8007454/webrev.01/ >> >> Summary: >> Old version of code for the [Java_java_lang_ProcessImpl_create] >> function could not work right in some cases. The >> [SetHandleInformation] call worked partially and just because >> HANDLE_FLAG_INHERIT == TRUE == 1 and FALSE == 0. > As the parameter is a DWORD then it shouldn't be using a BOOLEAN so I > agree with that. > > Can you explain why HANDLE_FLAG_PROTECT_FROM_CLOSE is needed? > Hmm... That was my mistake. HANDLE_FLAG_PROTECT_FROM_CLOSE bit has to be removed from mask. I mixed the variable names and did not understand clearly the handles life circle. My tests with redirected, direct and terminated input/output modes prove that the number of opened handles has GC-related saturation value. New version: http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8007454/webrev.02/ Thanks, -uta From Alan.Bateman at oracle.com Mon Feb 18 15:32:17 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 18 Feb 2013 15:32:17 +0000 Subject: Request for review: 8007454 Wrong parameters in Win32 native code. In-Reply-To: <512245B8.7060005@oracle.com> References: <50AE2E0A.7020609@oracle.com> <510FA969.303@oracle.com> <510FC4CD.2060208@oracle.com> <512245B8.7060005@oracle.com> Message-ID: <51224981.80409@oracle.com> On 18/02/2013 15:16, Alexey Utkin wrote: > : > > Hmm... That was my mistake. > HANDLE_FLAG_PROTECT_FROM_CLOSE bit has to be removed from mask. > > I mixed the variable names and did not understand clearly the handles > life circle. > My tests with redirected, direct and terminated input/output modes > prove that the number of opened > handles has GC-related saturation value. > > New version: > http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8007454/webrev.02/ No problem, it looks good now. -Alan. From john.zavgren at oracle.com Mon Feb 18 16:13:44 2013 From: john.zavgren at oracle.com (John Zavgren) Date: Mon, 18 Feb 2013 11:13:44 -0500 Subject: RFR JDK-8007609 In-Reply-To: <51199BDC.2020009@oracle.com> References: <51127084.3080206@oracle.com> <51138587.1010801@oracle.com> <511394C0.6040908@oracle.com> <511395FA.8060108@oracle.com> <5113A402.6050905@oracle.com> <511443B2.6030705@oracle.com> <5114D73D.8080903@oracle.com> <51152FD2.8040706@oracle.com> <51199BDC.2020009@oracle.com> Message-ID: <51225338.6040201@oracle.com> On 02/11/2013 08:33 PM, David Holmes wrote: > John, > > I think the functional fix is okay but you have obscured it in so much > "cleanup" that it is hard to say with 100% certainty. Please leave > extensive cleanups to separate bugs - in this case I'm not seeing > improvements in readability in a number of places (indentation is odd) > and in at least one case you have made a change that violates the > coding guidelines you cite eg: > > 126 } else > 127 len = 0; > > The else should have been left as a block. > > 121 } else { > 122 len = 0; > 123 } > > David > ----- > > On 9/02/2013 3:03 AM, John Zavgren wrote: >> Greetings: >> I posted a new webrev image: >> http://cr.openjdk.java.net/~jzavgren/8007609/webrev.03/ >> >> >> The sole "functional" revision is contained in the following small code >> snippet: >> >> - /* retry with a buffer of the right size */ >> - result = (WCHAR*)realloc(result, (len+1) * >> sizeof(WCHAR)); >> - if (result != NULL) { >> - len = (*GetFinalPathNameByHandle_func)(h, result, >> len, 0); >> - } else { >> + /* retry the procedure with a buffer of the right >> size. */ >> + WCHAR * newResult = (WCHAR*)realloc(result, (len+1) * >> sizeof(WCHAR)); >> + if (newResult != NULL) { >> + result = newResult; >> + len = (*GetFinalPathNameByHandle_func)(h, >> newResult, len, 0); >> + } else >> >> and, the innovation is the use of a local variable to hold the attempted >> memory reallocation. This makes the code simpler and easier to >> understand. >> >> I introduced a huge number of additional changes in the file that are my >> attempt to make the file consistent with our style guidelines. >> >> Changes include: >> 1.) elimination of tab characters. >> 2.) spelling, punctuation, and grammar corrections in the comments. >> 3.) truncation of lines that exceed 80 characters >> 4.) correction of indentation, line wrapping, etc. >> >> I hope I haven't missed anything. >> http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html >> >> >> >> On 02/08/2013 05:45 AM, Chris Hegarty wrote: >>> Apologies, you are correct. I'll book an appointment with the optician! >>> >>> -Chris. >>> >>> On 08/02/2013 00:15, David Holmes wrote: >>>> On 7/02/2013 10:54 PM, Chris Hegarty wrote: >>>>> On 02/07/2013 11:54 AM, David Holmes wrote: >>>>>> .... >>>>>>> AFAICS setting len=0 means len==0 will be true and so we will >>>>>>> free(result). >>>>>> >>>>>> And if len != 0 then we will have already freed result, so >>>>>> avoiding a >>>>>> double-free. >>>>> >>>>> Here's the code as it stands today. >>>> >>>> Yes .... I don't see the problem >>>> >>>>> >>>>> 113 result = (WCHAR*)malloc(MAX_PATH * sizeof(WCHAR)); >>>>> 114 if (result != NULL) { >>>> >>>> we've entered this block so we must free result evetually. >>>> >>>>> 115 DWORD len = (*GetFinalPathNameByHandle_func)(h, result, >>>>> MAX_PATH, 0); >>>>> 116 if (len >= MAX_PATH) { >>>>> 117 /* retry with a buffer of the right size */ >>>>> 118 result = (WCHAR*)realloc(result, (len+1) * sizeof(WCHAR)); >>>>> 119 if (result != NULL) { >>>>> 120 len = (*GetFinalPathNameByHandle_func)(h, result, len, 0); >>>>> 121 } else { >>>>> 122 len = 0; >>>>> 123 } >>>>> 124 } >>>>> 125 if (len > 0) { >>>> >>>> len was good so we've gone this path >>>> >>>>> 126 /** >>>>> 127 * Strip prefix (should be \\?\ or \\?\UNC) >>>>> 128 */ >>>>> 129 if (result[0] == L'\\' && result[1] == L'\\' && >>>>> 130 result[2] == L'?' && result[3] == L'\\') >>>>> 131 { >>>>> 132 int isUnc = (result[4] == L'U' && >>>>> 133 result[5] == L'N' && >>>>> 134 result[6] == L'C'); >>>>> 135 int prefixLen = (isUnc) ? 7 : 4; >>>>> 136 /* actual result length (includes terminator) */ >>>>> 137 int resultLen = len - prefixLen + (isUnc ? 1 : 0) + 1; >>>>> 138 >>>>> 139 /* copy result without prefix into new buffer */ >>>>> 140 WCHAR *tmp = (WCHAR*)malloc(resultLen * sizeof(WCHAR)); >>>>> 141 if (tmp == NULL) { >>>>> 142 len = 0; <<<<<<<<<<<<<<<<<<< HERE >>>> >>>> malloc failed so we need to bail out. We will now skip to line 161 >>>> >>>>> 143 } else { >>>>> 144 WCHAR *p = result; >>>>> 145 p += prefixLen; >>>>> 146 if (isUnc) { >>>>> 147 WCHAR *p2 = tmp; >>>>> 148 p2[0] = L'\\'; >>>>> 149 p2++; >>>>> 150 wcscpy(p2, p); >>>>> 151 } else { >>>>> 152 wcscpy(tmp, p); >>>>> 153 } >>>>> 154 free(result); >>>>> 155 result = tmp; >>>>> 156 } >>>>> 157 } >>>>> 158 } >>>>> 159 >>>>> 160 /* unable to get final path */ >>>>> 161 if (len == 0 && result != NULL) { >>>> >>>> We reach here because len==0 and result != NULL >>>> >>>>> 162 free(result); >>>>> 163 result = NULL; >>>>> 164 } >>>>> 165 } >>>> >>>> Looks fine to me. >>>> David >>>> >>>>> -Chris. >> >> Greetings: I just posted a new webrev image: http://cr.openjdk.java.net/~jzavgren/8007609/webrev.05/ The change is now focused on fixing the memory allocation issue... all the formatting changes have been removed. Thanks! John -- John Zavgren john.zavgren at oracle.com 603-821-0904 US-Burlington-MA From Alan.Bateman at oracle.com Mon Feb 18 17:19:17 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 18 Feb 2013 17:19:17 +0000 Subject: RFR JDK-8007609 In-Reply-To: <51225338.6040201@oracle.com> References: <51127084.3080206@oracle.com> <51138587.1010801@oracle.com> <511394C0.6040908@oracle.com> <511395FA.8060108@oracle.com> <5113A402.6050905@oracle.com> <511443B2.6030705@oracle.com> <5114D73D.8080903@oracle.com> <51152FD2.8040706@oracle.com> <51199BDC.2020009@oracle.com> <51225338.6040201@oracle.com> Message-ID: <51226295.4070009@oracle.com> On 18/02/2013 16:13, John Zavgren wrote: > : > Greetings: > I just posted a new webrev image: > > http://cr.openjdk.java.net/~jzavgren/8007609/webrev.05/ > > > The change is now focused on fixing the memory allocation issue... all > the formatting changes have been removed. This looks good to me. -Alan. From eric.mccorkle at oracle.com Mon Feb 18 18:42:52 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Mon, 18 Feb 2013 13:42:52 -0500 Subject: Review request for JDK-8008312: Re-enable MethodParameter tests in JDK In-Reply-To: <511EAD45.9080803@oracle.com> References: <511E993D.2000404@oracle.com> <511EAD45.9080803@oracle.com> Message-ID: <5122762C.1000003@oracle.com> Any other comments on this one, or is it good to go? On 02/15/13 16:48, Joe Darcy wrote: > Hi Eric, > > I'll approve this change as-is, but I'd prefer if the test were written > in the style of using annotations to record the expected value. > > Cheers, > > -Joe > > On 2/15/2013 12:23 PM, Eric McCorkle wrote: >> Hi, >> >> Please review this simple patch, which re-enables the JDK end-to-end >> tests for parameter reflection. >> >> It also fixes a small error in toString >> >> The webrev is here >> http://cr.openjdk.java.net/~emc/8008312/ >> >> Thanks, >> Eric > From chris.hegarty at oracle.com Mon Feb 18 21:47:31 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 18 Feb 2013 21:47:31 +0000 Subject: RFR JDK-8007609 In-Reply-To: <51226295.4070009@oracle.com> References: <51127084.3080206@oracle.com> <51138587.1010801@oracle.com> <511394C0.6040908@oracle.com> <511395FA.8060108@oracle.com> <5113A402.6050905@oracle.com> <511443B2.6030705@oracle.com> <5114D73D.8080903@oracle.com> <51152FD2.8040706@oracle.com> <51199BDC.2020009@oracle.com> <51225338.6040201@oracle.com> <51226295.4070009@oracle.com> Message-ID: <5122A173.5010609@oracle.com> On 18/02/2013 17:19, Alan Bateman wrote: > On 18/02/2013 16:13, John Zavgren wrote: >> : >> Greetings: >> I just posted a new webrev image: >> >> http://cr.openjdk.java.net/~jzavgren/8007609/webrev.05/ >> >> >> The change is now focused on fixing the memory allocation issue... all >> the formatting changes have been removed. > This looks good to me. +1 I see that there are several JNU_XXX function calls from this file, but since jni_util.h is included from io_util.h, it should be fine. I can sponsor this for you John, if you still need a sponsor. -Chris. > > -Alan. From jonathan.gibbons at oracle.com Mon Feb 18 22:29:55 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 18 Feb 2013 22:29:55 +0000 Subject: hg: jdk8/tl/langtools: 8008339: Test TargetAnnoCombo.java is broken Message-ID: <20130218223002.A31F847B76@hg.openjdk.java.net> Changeset: 87884cd0fea3 Author: jjg Date: 2013-02-18 14:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/87884cd0fea3 8008339: Test TargetAnnoCombo.java is broken Reviewed-by: jjh ! test/tools/javac/annotations/repeatingAnnotations/combo/TargetAnnoCombo.java From david.holmes at oracle.com Tue Feb 19 01:54:21 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Feb 2013 11:54:21 +1000 Subject: JEP 161 SE Compact Profiles has pushed to jdk8/build forest Message-ID: <5122DB4D.4020302@oracle.com> The implementation support for the Reference Implementation of the SE Compact Profiles described by: http://openjdk.java.net/jeps/161 has now been pushed to the jdk8/build forest ready for integration with jdk8/jdk8 in time for b78. This reference implementation is for the Linux platform only. To build the compact profiles JREs specify the "profiles" target to make: make profiles or to build the full JDK/JRE and profile images use: make images profiles Profiles are not built by default ("make all"). The Profile JRE's are created in the images directory along side the j2re-image and j2sdk-image, and are named j2re-compactN-image, for N=1,2,3 One minor issue we just became aware of (bug 8008424), don't have the variable PROFILE set in your environment when building the "images" target. Workaround is to either unset the env variable before calling make, or pass PROFILE="" as a make argument when building. This will be fixed ASAP. David Holmes ------------- From mike.duigou at oracle.com Tue Feb 19 05:27:13 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 18 Feb 2013 21:27:13 -0800 Subject: FYC : JDK-7197183 : Improve copying behaviour of String.subSequence() Message-ID: Hello all; JDK 7u6 included a significant change to java.lang.String. The change was internal to the String implementation and didn't result in any API changes but it does have a significant impact on the performance of some uses cases. (See http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-June/010509.html for an earlier discussion) Prior to 7u6 String maintained two fields "count" and "offset" which described the location within the character array of the String's characters. In 7u6 the count and offset fields were removed and String instances no longer share their character arrays with other String instances. Each substring(), subSequence() or split() now creates entirely new String instances for it's results. Before 7u6 two or more instances of String could share the same backing character array. A number of String operations; clone(), split(), subString(), subSequence() did not copy the backing character array but created new String instances pointing at their character array with appropriate "count" and "offset" values. As with most sharing techniques, there are tradeoffs. The "count/offset" approach works reasonably well for cases where the substrings have a shorter lifetime than the original. Frequently it was found though that the large character arrays "leaked" through small Strings derived from larger String instances. Examples would be tokens parsed with substring() from HTTP headers being used as keys in Maps. This caused the entire header character array from the original header String to not be garbage collected (or worse the entire set of headers for a request). Our benchmarking and application testing prior to changing the String implementation in 7u6 showed that it was a net benefit to not share the character array instances. The benchmarking and performance testing for this change actually began in 2007 and was very extensive. Benchmarking and performance analysis since the release of 7u6 continues to indicate that removal of sharing is the better approach. It is extremely unlikely that we would consider returning to the pre-7u6 implementation (in case you were thinking of suggesting that). There are some cases where the new approach can result in significant performance penalties. This is a "For Your Consideration" review not a pre-push changeset. The review changeset is a weakening of the "never share the String character array" rule and it means that it would suffer from exactly the same weakness. Few applications currently use subSequence() most currently use subString(). Applications which would benefit from this change would have to switch to using subSequence(). Apps can safely switch to subSequence in anticipation of this change because currently subSequence() is identical to substring(). This means that should this changeset not be integrated app code would suffer no penalty and if this change is eventually integrated then app performance will improve. http://cr.openjdk.java.net/~mduigou/JDK-7197183/0/ From our current testing we found that applications currently using subSequence() failed if the equals(), hashCode() and toString() implementations did not exactly match String. Additionally we had to change String.equals() so that it recognizes can return "true" for matching instances of String.SubSequence. You will see some unfortunate potential usage patterns in the presented implementation--most specifically, calling toString() on the result of a String.subSequence() results in a new String instance being created (ouch!). I would like to eliminate the caching of the hashCode() result but it appears that it is frequently used and failing to cache the hash code results in greatly decreased performance for the relevant applications. Currently TreeSet and TreeMap which use natural order fail for data sets of mixed String and String.SubSequence. I believe it is necessary for natural order sorting to work for mixed collections of String and String.SubSequence instances. Would this proposal cause your applications any problems? Is this proposal absolutely necessary for your application to have adequate performance? Have you already made other accommodations for the altered performance behaviour of Strings introduced in 7u6? Other thoughts? Mike From david.holmes at oracle.com Tue Feb 19 05:29:19 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Feb 2013 15:29:19 +1000 Subject: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda Libraries In-Reply-To: <2CB90323-8862-4735-BC75-7A1EB3C8276B@oracle.com> References: <2CB90323-8862-4735-BC75-7A1EB3C8276B@oracle.com> Message-ID: <51230DAF.7030402@oracle.com> Hi Mike, In BinaryOperator.java this sentence doesn't read correctly: + * An operation upon two operands yielding a result. This is a specialization of + * {@code BiFunction} for the operands and the result are all being of the same + * type. suggestions: {@code BiFunction} for the case where the operands and the result are all of the same type. {@code BiFunction} where the operands and the result are all of the same type. --- DoubleUnaryOperator.java - this changed wording seems more awkward than the original: /** - * Returns the {@code double} result of the operation upon the + * Returns a {@code double} value result of the operation upon the * {@code double} operand. --- Function.java + * @param the type of result of the {@code apply} operation. Either "the type of the result of the ...", or "the type of result from the ..." --- General comment regarding specializations of Function. If we have Function where R is the result type, then in the specializations which specialize the input type (T) then we should use R for the remaining type variable eg IntFunction rather than IntFunction --- In LongFunction: + * @param l the input value why use l as the parameter name? I presume for "long" but why? I thought the "i" parameter in IntFunction was so named for "input". I would much rather see a common parameter naming scheme being used (i, t, val, arg - any of these). --- UnaryOperator.java This sentence doesn't read right: + * result are of the same type. This is a specialization of {@code Function} for + * the operand and the result of the same type. suggest: "This is a specialization of {@code Function} for the case where the operand and result are of the same type." --- package-info.java I've flagged this elsewhere but you may not have seen it: + * Predicate<String> If we use < then we should also use >. --- BiFunction: + * is the two-arity specialization of {@link Consummer} typo: Consummer + * @param the type of output objects from {@code apply} operation. from -> from the ---- The *BiXXX types are not consistently documented. For example: BiFunction has: + * @param the type of input objects provided to the {@code apply} operation. + * @param the type of input objects provided to the {@code apply} operation. while BiPredicate has: + * @param the type of the first argument to {@code test}. + * @param the type of the second argument to {@code test}. I prefer the BiPredicate form. --- DoublePredicate.java + * Determines if the {@code long} input value matches some criteria. This is the + * {@code double}-consuming primitive type specialization of {@link Predicate}. The first "long" should be "double". --- ToIntBiFunction.java + * Apply a function to the input argument, argument -> arguments --- Aside: it would be much easier to maintain consistent style if we used a "template" to define the main outline of each family of interfaces and generated the specializations from that (similar to how we generate the various bytebuffer classes). Cheers, David ------ On 16/02/2013 6:13 AM, Mike Duigou wrote: > Hello All; > > This patch introduces a number of new functional interfaces for use by the lambda libraries. Also included are some name changes following JSR-225 EG review. The new interfaces are: > > BiConsumer > BiFunction > BiPredicate > BooleanSupplier > DoublePredicate > IntPredicate > LongPredicate > ObjDoubleConsumer > ObjIntConsumer > ObjLongConsumer > ToDoubleBiFunction > ToDoubleFunction > ToIntBiFunction > ToIntFunction > ToLongBiFunction > ToLongFunction > > Renames: > > Block -> Consumer > BiBlock -> BiConsumer > IntBlock -> IntConsumer > DoubleBlock -> LongConsumer > LongBlock -> LongConsumer > UnaryOperator.operate -> UnaryOperator.apply > LongUnaryOperator.operateAsLong -> LongUnaryOperator.applyAsLong > DoubleUnaryOperator.operateAsDouble -> DoubleUnaryOperator.applyAsDouble > IntUnaryOperator.operateAsInt -> IntUnaryOperator.applyAsInt > LongBinaryOperator.operateAsLong -> LongBinaryOperator.applyAsLong > DoubleBinaryOperator.operateAsDouble -> DoubleBinaryOperator.applyAsDouble > IntBinaryOperator.operateAsInt -> IntBinaryOperator.applyAsInt > > All of the changes outside the java.util.function package are made to accommodate these renamings. > > The webrev is located at: > > http://cr.openjdk.java.net/~mduigou/JDK-8004561/1/webrev/ > > and specdiff for the java.util.function package is at: > > http://cr.openjdk.java.net/~mduigou/JDK-8004561/1/specdiff/ > > Thanks! > > Mike > > From joe.darcy at oracle.com Tue Feb 19 06:58:03 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 18 Feb 2013 22:58:03 -0800 Subject: JDK 8 request for review: two javadoc warning fixes, on in DateTimeFormatterBuilder, another in TimeZone Message-ID: <5123227B.7000403@oracle.com> Hello, Please review these two simple fixes for javadoc warnings I noticed during a build (I'll file a bug after getting a review): diff -r bcde0486261e src/share/classes/java/time/format/DateTimeFormatterBuilder.java --- a/src/share/classes/java/time/format/DateTimeFormatterBuilder.java Mon Feb 18 08:14:18 2013 +0000 +++ b/src/share/classes/java/time/format/DateTimeFormatterBuilder.java Mon Feb 18 22:55:56 2013 -0800 @@ -1007,7 +1007,7 @@ * is used, with {@code IsoChronology} as the fallback. *

* Note that this method provides similar functionality to methods on - * {@code DateFormat} such as {@link DateFormat#getDateTimeInstance(int, int)}. + * {@code DateFormat} such as {@link java.text.DateFormat#getDateTimeInstance(int, int)}. * * @param dateStyle the date style to use, null means no date required * @param timeStyle the time style to use, null means no time required diff -r bcde0486261e src/share/classes/java/util/TimeZone.java --- a/src/share/classes/java/util/TimeZone.java Mon Feb 18 08:14:18 2013 +0000 +++ b/src/share/classes/java/util/TimeZone.java Mon Feb 18 22:55:56 2013 -0800 @@ -534,7 +534,7 @@ /** * Gets the {@code TimeZone} for the given {@code zoneId}. * - * @param zoneid a {@link ZoneId} from which the time zone ID is obtained + * @param zoneId a {@link ZoneId} from which the time zone ID is obtained * @return the specified {@code TimeZone}, or the GMT zone if the given ID * cannot be understood. * @throws NullPointerException if {@code zoneId} is {@code null} Thanks, -Joe From mike.duigou at oracle.com Tue Feb 19 07:06:25 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 18 Feb 2013 23:06:25 -0800 Subject: JDK 8 request for review: two javadoc warning fixes, on in DateTimeFormatterBuilder, another in TimeZone In-Reply-To: <5123227B.7000403@oracle.com> References: <5123227B.7000403@oracle.com> Message-ID: Both look fine to me. No need for a webrev. Mike On Feb 18 2013, at 22:58 , Joe Darcy wrote: > Hello, > > Please review these two simple fixes for javadoc warnings I noticed during a build (I'll file a bug after getting a review): > > diff -r bcde0486261e src/share/classes/java/time/format/DateTimeFormatterBuilder.java > --- a/src/share/classes/java/time/format/DateTimeFormatterBuilder.java Mon Feb 18 08:14:18 2013 +0000 > +++ b/src/share/classes/java/time/format/DateTimeFormatterBuilder.java Mon Feb 18 22:55:56 2013 -0800 > @@ -1007,7 +1007,7 @@ > * is used, with {@code IsoChronology} as the fallback. > *

> * Note that this method provides similar functionality to methods on > - * {@code DateFormat} such as {@link DateFormat#getDateTimeInstance(int, int)}. > + * {@code DateFormat} such as {@link java.text.DateFormat#getDateTimeInstance(int, int)}. > * > * @param dateStyle the date style to use, null means no date required > * @param timeStyle the time style to use, null means no time required > diff -r bcde0486261e src/share/classes/java/util/TimeZone.java > --- a/src/share/classes/java/util/TimeZone.java Mon Feb 18 08:14:18 2013 +0000 > +++ b/src/share/classes/java/util/TimeZone.java Mon Feb 18 22:55:56 2013 -0800 > @@ -534,7 +534,7 @@ > /** > * Gets the {@code TimeZone} for the given {@code zoneId}. > * > - * @param zoneid a {@link ZoneId} from which the time zone ID is obtained > + * @param zoneId a {@link ZoneId} from which the time zone ID is obtained > * @return the specified {@code TimeZone}, or the GMT zone if the given ID > * cannot be understood. > * @throws NullPointerException if {@code zoneId} is {@code null} > > Thanks, > > -Joe From masayoshi.okutsu at oracle.com Tue Feb 19 07:28:15 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Tue, 19 Feb 2013 16:28:15 +0900 Subject: JDK 8 request for review: two javadoc warning fixes, on in DateTimeFormatterBuilder, another in TimeZone In-Reply-To: <5123227B.7000403@oracle.com> References: <5123227B.7000403@oracle.com> Message-ID: <5123298F.8000308@oracle.com> Looks good to me. Masayoshi On 2/19/2013 3:58 PM, Joe Darcy wrote: > Hello, > > Please review these two simple fixes for javadoc warnings I noticed > during a build (I'll file a bug after getting a review): > > diff -r bcde0486261e > src/share/classes/java/time/format/DateTimeFormatterBuilder.java > --- a/src/share/classes/java/time/format/DateTimeFormatterBuilder.java > Mon Feb 18 08:14:18 2013 +0000 > +++ b/src/share/classes/java/time/format/DateTimeFormatterBuilder.java > Mon Feb 18 22:55:56 2013 -0800 > @@ -1007,7 +1007,7 @@ > * is used, with {@code IsoChronology} as the fallback. > *

> * Note that this method provides similar functionality to > methods on > - * {@code DateFormat} such as {@link > DateFormat#getDateTimeInstance(int, int)}. > + * {@code DateFormat} such as {@link > java.text.DateFormat#getDateTimeInstance(int, int)}. > * > * @param dateStyle the date style to use, null means no date > required > * @param timeStyle the time style to use, null means no time > required > diff -r bcde0486261e src/share/classes/java/util/TimeZone.java > --- a/src/share/classes/java/util/TimeZone.java Mon Feb 18 08:14:18 > 2013 +0000 > +++ b/src/share/classes/java/util/TimeZone.java Mon Feb 18 22:55:56 > 2013 -0800 > @@ -534,7 +534,7 @@ > /** > * Gets the {@code TimeZone} for the given {@code zoneId}. > * > - * @param zoneid a {@link ZoneId} from which the time zone ID is > obtained > + * @param zoneId a {@link ZoneId} from which the time zone ID is > obtained > * @return the specified {@code TimeZone}, or the GMT zone if the > given ID > * cannot be understood. > * @throws NullPointerException if {@code zoneId} is {@code null} > > Thanks, > > -Joe From david.holmes at oracle.com Tue Feb 19 07:32:16 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Feb 2013 17:32:16 +1000 Subject: RFR JDK-8007609 In-Reply-To: <51225338.6040201@oracle.com> References: <51127084.3080206@oracle.com> <51138587.1010801@oracle.com> <511394C0.6040908@oracle.com> <511395FA.8060108@oracle.com> <5113A402.6050905@oracle.com> <511443B2.6030705@oracle.com> <5114D73D.8080903@oracle.com> <51152FD2.8040706@oracle.com> <51199BDC.2020009@oracle.com> <51225338.6040201@oracle.com> Message-ID: <51232A80.7090000@oracle.com> Looks fine to me. Thanks, David On 19/02/2013 2:13 AM, John Zavgren wrote: > On 02/11/2013 08:33 PM, David Holmes wrote: >> John, >> >> I think the functional fix is okay but you have obscured it in so much >> "cleanup" that it is hard to say with 100% certainty. Please leave >> extensive cleanups to separate bugs - in this case I'm not seeing >> improvements in readability in a number of places (indentation is odd) >> and in at least one case you have made a change that violates the >> coding guidelines you cite eg: >> >> 126 } else >> 127 len = 0; >> >> The else should have been left as a block. >> >> 121 } else { >> 122 len = 0; >> 123 } >> >> David >> ----- >> >> On 9/02/2013 3:03 AM, John Zavgren wrote: >>> Greetings: >>> I posted a new webrev image: >>> http://cr.openjdk.java.net/~jzavgren/8007609/webrev.03/ >>> >>> >>> The sole "functional" revision is contained in the following small code >>> snippet: >>> >>> - /* retry with a buffer of the right size */ >>> - result = (WCHAR*)realloc(result, (len+1) * >>> sizeof(WCHAR)); >>> - if (result != NULL) { >>> - len = (*GetFinalPathNameByHandle_func)(h, result, >>> len, 0); >>> - } else { >>> + /* retry the procedure with a buffer of the right >>> size. */ >>> + WCHAR * newResult = (WCHAR*)realloc(result, (len+1) * >>> sizeof(WCHAR)); >>> + if (newResult != NULL) { >>> + result = newResult; >>> + len = (*GetFinalPathNameByHandle_func)(h, >>> newResult, len, 0); >>> + } else >>> >>> and, the innovation is the use of a local variable to hold the attempted >>> memory reallocation. This makes the code simpler and easier to >>> understand. >>> >>> I introduced a huge number of additional changes in the file that are my >>> attempt to make the file consistent with our style guidelines. >>> >>> Changes include: >>> 1.) elimination of tab characters. >>> 2.) spelling, punctuation, and grammar corrections in the comments. >>> 3.) truncation of lines that exceed 80 characters >>> 4.) correction of indentation, line wrapping, etc. >>> >>> I hope I haven't missed anything. >>> http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html >>> >>> >>> >>> On 02/08/2013 05:45 AM, Chris Hegarty wrote: >>>> Apologies, you are correct. I'll book an appointment with the optician! >>>> >>>> -Chris. >>>> >>>> On 08/02/2013 00:15, David Holmes wrote: >>>>> On 7/02/2013 10:54 PM, Chris Hegarty wrote: >>>>>> On 02/07/2013 11:54 AM, David Holmes wrote: >>>>>>> .... >>>>>>>> AFAICS setting len=0 means len==0 will be true and so we will >>>>>>>> free(result). >>>>>>> >>>>>>> And if len != 0 then we will have already freed result, so >>>>>>> avoiding a >>>>>>> double-free. >>>>>> >>>>>> Here's the code as it stands today. >>>>> >>>>> Yes .... I don't see the problem >>>>> >>>>>> >>>>>> 113 result = (WCHAR*)malloc(MAX_PATH * sizeof(WCHAR)); >>>>>> 114 if (result != NULL) { >>>>> >>>>> we've entered this block so we must free result evetually. >>>>> >>>>>> 115 DWORD len = (*GetFinalPathNameByHandle_func)(h, result, >>>>>> MAX_PATH, 0); >>>>>> 116 if (len >= MAX_PATH) { >>>>>> 117 /* retry with a buffer of the right size */ >>>>>> 118 result = (WCHAR*)realloc(result, (len+1) * sizeof(WCHAR)); >>>>>> 119 if (result != NULL) { >>>>>> 120 len = (*GetFinalPathNameByHandle_func)(h, result, len, 0); >>>>>> 121 } else { >>>>>> 122 len = 0; >>>>>> 123 } >>>>>> 124 } >>>>>> 125 if (len > 0) { >>>>> >>>>> len was good so we've gone this path >>>>> >>>>>> 126 /** >>>>>> 127 * Strip prefix (should be \\?\ or \\?\UNC) >>>>>> 128 */ >>>>>> 129 if (result[0] == L'\\' && result[1] == L'\\' && >>>>>> 130 result[2] == L'?' && result[3] == L'\\') >>>>>> 131 { >>>>>> 132 int isUnc = (result[4] == L'U' && >>>>>> 133 result[5] == L'N' && >>>>>> 134 result[6] == L'C'); >>>>>> 135 int prefixLen = (isUnc) ? 7 : 4; >>>>>> 136 /* actual result length (includes terminator) */ >>>>>> 137 int resultLen = len - prefixLen + (isUnc ? 1 : 0) + 1; >>>>>> 138 >>>>>> 139 /* copy result without prefix into new buffer */ >>>>>> 140 WCHAR *tmp = (WCHAR*)malloc(resultLen * sizeof(WCHAR)); >>>>>> 141 if (tmp == NULL) { >>>>>> 142 len = 0; <<<<<<<<<<<<<<<<<<< HERE >>>>> >>>>> malloc failed so we need to bail out. We will now skip to line 161 >>>>> >>>>>> 143 } else { >>>>>> 144 WCHAR *p = result; >>>>>> 145 p += prefixLen; >>>>>> 146 if (isUnc) { >>>>>> 147 WCHAR *p2 = tmp; >>>>>> 148 p2[0] = L'\\'; >>>>>> 149 p2++; >>>>>> 150 wcscpy(p2, p); >>>>>> 151 } else { >>>>>> 152 wcscpy(tmp, p); >>>>>> 153 } >>>>>> 154 free(result); >>>>>> 155 result = tmp; >>>>>> 156 } >>>>>> 157 } >>>>>> 158 } >>>>>> 159 >>>>>> 160 /* unable to get final path */ >>>>>> 161 if (len == 0 && result != NULL) { >>>>> >>>>> We reach here because len==0 and result != NULL >>>>> >>>>>> 162 free(result); >>>>>> 163 result = NULL; >>>>>> 164 } >>>>>> 165 } >>>>> >>>>> Looks fine to me. >>>>> David >>>>> >>>>>> -Chris. >>> >>> > Greetings: > I just posted a new webrev image: > > http://cr.openjdk.java.net/~jzavgren/8007609/webrev.05/ > > > The change is now focused on fixing the memory allocation issue... all > the formatting changes have been removed. > > Thanks! > John > From joe.darcy at oracle.com Tue Feb 19 08:19:33 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 19 Feb 2013 08:19:33 +0000 Subject: hg: jdk8/tl/jdk: 8008434: Misc javadoc warning fixes in DateTimeFormatterBuilder and TimeZone Message-ID: <20130219082010.CC88F47B87@hg.openjdk.java.net> Changeset: 49b3d8efd30a Author: darcy Date: 2013-02-19 00:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/49b3d8efd30a 8008434: Misc javadoc warning fixes in DateTimeFormatterBuilder and TimeZone Reviewed-by: mduigou, okutsu ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/util/TimeZone.java From joe.darcy at oracle.com Tue Feb 19 08:25:18 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 19 Feb 2013 08:25:18 +0000 Subject: hg: jdk8/tl: 8008435: Fix new build to include jdk.Supported in ct.sym Message-ID: <20130219082518.AD92747B88@hg.openjdk.java.net> Changeset: ecc8fda8f187 Author: darcy Date: 2013-02-19 00:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ecc8fda8f187 8008435: Fix new build to include jdk.Supported in ct.sym Reviewed-by: erikj ! common/makefiles/javadoc/NON_CORE_PKGS.gmk From joe.darcy at oracle.com Tue Feb 19 08:32:03 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 19 Feb 2013 08:32:03 +0000 Subject: hg: jdk8/tl/langtools: 8008267: Add @Supported annotation to com.sun.source types Message-ID: <20130219083209.2371A47B8B@hg.openjdk.java.net> Changeset: 011cf7e0a148 Author: darcy Date: 2013-02-19 00:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/011cf7e0a148 8008267: Add @Supported annotation to com.sun.source types Reviewed-by: jjg ! src/share/classes/com/sun/source/doctree/AttributeTree.java ! src/share/classes/com/sun/source/doctree/AuthorTree.java ! src/share/classes/com/sun/source/doctree/BlockTagTree.java ! src/share/classes/com/sun/source/doctree/CommentTree.java ! src/share/classes/com/sun/source/doctree/DeprecatedTree.java ! src/share/classes/com/sun/source/doctree/DocCommentTree.java ! src/share/classes/com/sun/source/doctree/DocRootTree.java ! src/share/classes/com/sun/source/doctree/DocTree.java ! src/share/classes/com/sun/source/doctree/DocTreeVisitor.java ! src/share/classes/com/sun/source/doctree/EndElementTree.java ! src/share/classes/com/sun/source/doctree/EntityTree.java ! src/share/classes/com/sun/source/doctree/ErroneousTree.java ! src/share/classes/com/sun/source/doctree/IdentifierTree.java ! src/share/classes/com/sun/source/doctree/InheritDocTree.java ! src/share/classes/com/sun/source/doctree/InlineTagTree.java ! src/share/classes/com/sun/source/doctree/LinkTree.java ! src/share/classes/com/sun/source/doctree/LiteralTree.java ! src/share/classes/com/sun/source/doctree/ParamTree.java ! src/share/classes/com/sun/source/doctree/ReferenceTree.java ! src/share/classes/com/sun/source/doctree/ReturnTree.java ! src/share/classes/com/sun/source/doctree/SeeTree.java ! src/share/classes/com/sun/source/doctree/SerialDataTree.java ! src/share/classes/com/sun/source/doctree/SerialFieldTree.java ! src/share/classes/com/sun/source/doctree/SerialTree.java ! src/share/classes/com/sun/source/doctree/SinceTree.java ! src/share/classes/com/sun/source/doctree/StartElementTree.java ! src/share/classes/com/sun/source/doctree/TextTree.java ! src/share/classes/com/sun/source/doctree/ThrowsTree.java ! src/share/classes/com/sun/source/doctree/UnknownBlockTagTree.java ! src/share/classes/com/sun/source/doctree/UnknownInlineTagTree.java ! src/share/classes/com/sun/source/doctree/ValueTree.java ! src/share/classes/com/sun/source/doctree/VersionTree.java ! src/share/classes/com/sun/source/doctree/package-info.java ! src/share/classes/com/sun/source/tree/AnnotatedTypeTree.java ! src/share/classes/com/sun/source/tree/AnnotationTree.java ! src/share/classes/com/sun/source/tree/ArrayAccessTree.java ! src/share/classes/com/sun/source/tree/ArrayTypeTree.java ! src/share/classes/com/sun/source/tree/AssertTree.java ! src/share/classes/com/sun/source/tree/AssignmentTree.java ! src/share/classes/com/sun/source/tree/BinaryTree.java ! src/share/classes/com/sun/source/tree/BlockTree.java ! src/share/classes/com/sun/source/tree/BreakTree.java ! src/share/classes/com/sun/source/tree/CaseTree.java ! src/share/classes/com/sun/source/tree/CatchTree.java ! src/share/classes/com/sun/source/tree/ClassTree.java ! src/share/classes/com/sun/source/tree/CompilationUnitTree.java ! src/share/classes/com/sun/source/tree/CompoundAssignmentTree.java ! src/share/classes/com/sun/source/tree/ConditionalExpressionTree.java ! src/share/classes/com/sun/source/tree/ContinueTree.java ! src/share/classes/com/sun/source/tree/DoWhileLoopTree.java ! src/share/classes/com/sun/source/tree/EmptyStatementTree.java ! src/share/classes/com/sun/source/tree/EnhancedForLoopTree.java ! src/share/classes/com/sun/source/tree/ErroneousTree.java ! src/share/classes/com/sun/source/tree/ExpressionStatementTree.java ! src/share/classes/com/sun/source/tree/ExpressionTree.java ! src/share/classes/com/sun/source/tree/ForLoopTree.java ! src/share/classes/com/sun/source/tree/IdentifierTree.java ! src/share/classes/com/sun/source/tree/IfTree.java ! src/share/classes/com/sun/source/tree/ImportTree.java ! src/share/classes/com/sun/source/tree/InstanceOfTree.java ! src/share/classes/com/sun/source/tree/IntersectionTypeTree.java ! src/share/classes/com/sun/source/tree/LabeledStatementTree.java ! src/share/classes/com/sun/source/tree/LambdaExpressionTree.java ! src/share/classes/com/sun/source/tree/LineMap.java ! src/share/classes/com/sun/source/tree/LiteralTree.java ! src/share/classes/com/sun/source/tree/MemberReferenceTree.java ! src/share/classes/com/sun/source/tree/MemberSelectTree.java ! src/share/classes/com/sun/source/tree/MethodInvocationTree.java ! src/share/classes/com/sun/source/tree/MethodTree.java ! src/share/classes/com/sun/source/tree/ModifiersTree.java ! src/share/classes/com/sun/source/tree/NewArrayTree.java ! src/share/classes/com/sun/source/tree/NewClassTree.java ! src/share/classes/com/sun/source/tree/ParameterizedTypeTree.java ! src/share/classes/com/sun/source/tree/ParenthesizedTree.java ! src/share/classes/com/sun/source/tree/PrimitiveTypeTree.java ! src/share/classes/com/sun/source/tree/ReturnTree.java ! src/share/classes/com/sun/source/tree/Scope.java ! src/share/classes/com/sun/source/tree/StatementTree.java ! src/share/classes/com/sun/source/tree/SwitchTree.java ! src/share/classes/com/sun/source/tree/SynchronizedTree.java ! src/share/classes/com/sun/source/tree/ThrowTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/tree/TryTree.java ! src/share/classes/com/sun/source/tree/TypeCastTree.java ! src/share/classes/com/sun/source/tree/TypeParameterTree.java ! src/share/classes/com/sun/source/tree/UnaryTree.java ! src/share/classes/com/sun/source/tree/UnionTypeTree.java ! src/share/classes/com/sun/source/tree/VariableTree.java ! src/share/classes/com/sun/source/tree/WhileLoopTree.java ! src/share/classes/com/sun/source/tree/WildcardTree.java ! src/share/classes/com/sun/source/tree/package-info.java ! src/share/classes/com/sun/source/util/DocTreeScanner.java ! src/share/classes/com/sun/source/util/DocTrees.java ! src/share/classes/com/sun/source/util/JavacTask.java ! src/share/classes/com/sun/source/util/Plugin.java ! src/share/classes/com/sun/source/util/SimpleDocTreeVisitor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/SourcePositions.java ! src/share/classes/com/sun/source/util/TaskEvent.java ! src/share/classes/com/sun/source/util/TaskListener.java ! src/share/classes/com/sun/source/util/TreePath.java ! src/share/classes/com/sun/source/util/TreePathScanner.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/source/util/Trees.java ! src/share/classes/com/sun/source/util/package-info.java ! src/share/classes/com/sun/tools/javac/Main.java ! src/share/classes/com/sun/tools/javac/Server.java From peter.levart at gmail.com Tue Feb 19 09:28:24 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 19 Feb 2013 10:28:24 +0100 Subject: FYC : JDK-7197183 : Improve copying behaviour of String.subSequence() In-Reply-To: References: Message-ID: <512345B8.1000205@gmail.com> Hi Mike, Regarding the implementation details: I think it would be better to reference just the String's value[] array in the String.SubSequence instead of the String instance itself. Two reasons come to mind: - eliminate another indirection when accessing the array - when referencing the String instance, code like this would leak implementation details (again): String s = new String("..."); CharSequence cs = s.subSequence(0, s.length()-1); WeakReference wr = new WeakReference<>(s); // ... if we keep a reference to cs, wr will never be cleared... Regarding the strategy: It's very unfortunate that code exists that uses String.subSequence result in a way treating it as an object with value semantics for equals() and hashCode() despite the specification for CharSequence clearly stating: /"This interface does not refine the general contracts of the //|equals| //and //|hashCode| //methods. The result of comparing two objects that implement //CharSequence//is therefore, in general, undefined. Each object may be implemented by a different class, and there is no guarantee that each class will be capable of testing its instances for equality with those of the other. It is therefore inappropriate to use arbitrary //CharSequence//instances as elements in a set or as keys in a map."/ The excuse for such usage is the specification of String.subSequence method: /"Returns a new character sequence that is a subsequence of this sequence. / /An invocation of this method of the form / / str.subSequence(begin, end)/ /behaves in exactly the same way as the invocation / / str.substring(begin, end)/ /This method is defined so that the //String//class can implement the //|CharSequence| //interface. "/ So this proposal actually breaks this specification. It tries to break it in a way that would keep some of the usages still behave like before, but it can't entirely succeed. The following code is valid now, but will throw CCE with this proposal: String s = ...; String s0 = (String) s.subSequence(0, 1); One can imagine other scenarios that would break (like custom comparators casting to String, etc.). So to be entirely compatible, an escape-hatch would have to be available (in the form of a System property for example) to restore the old behaviour if requested. If there is an escape-hatch, the question arises: Why not breaking the String.subSequence entirely? We could brake it so that the method would clearly specify the returned CharSequence behaviour regarding underlying value[] array sharing, hashCode(), equals(), subSequence() and Comparable only in terms of CharSequence instances returned from the method and not cross String <-> String.SubSequence. This would encourage migration of behaviourally incompatible code to forms that are compatible with both pre JDK8 and post JDK8 String.subSequence specification instead of keeping the status quo. There's also a third option - adding new method (back-porting it to JDK7): public String.SubSequence stringSubSequence(int, int); ...and keeping subSequence as is. Regards, Peter On 02/19/2013 06:27 AM, Mike Duigou wrote: > Hello all; > > JDK 7u6 included a significant change to java.lang.String. The change was internal to the String implementation and didn't result in any API changes but it does have a significant impact on the performance of some uses cases. (See http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-June/010509.html for an earlier discussion) > > Prior to 7u6 String maintained two fields "count" and "offset" which described the location within the character array of the String's characters. In 7u6 the count and offset fields were removed and String instances no longer share their character arrays with other String instances. Each substring(), subSequence() or split() now creates entirely new String instances for it's results. Before 7u6 two or more instances of String could share the same backing character array. A number of String operations; clone(), split(), subString(), subSequence() did not copy the backing character array but created new String instances pointing at their character array with appropriate "count" and "offset" values. > > As with most sharing techniques, there are tradeoffs. The "count/offset" approach works reasonably well for cases where the substrings have a shorter lifetime than the original. Frequently it was found though that the large character arrays "leaked" through small Strings derived from larger String instances. Examples would be tokens parsed with substring() from HTTP headers being used as keys in Maps. This caused the entire header character array from the original header String to not be garbage collected (or worse the entire set of headers for a request). > > Our benchmarking and application testing prior to changing the String implementation in 7u6 showed that it was a net benefit to not share the character array instances. The benchmarking and performance testing for this change actually began in 2007 and was very extensive. Benchmarking and performance analysis since the release of 7u6 continues to indicate that removal of sharing is the better approach. It is extremely unlikely that we would consider returning to the pre-7u6 implementation (in case you were thinking of suggesting that). > > There are some cases where the new approach can result in significant performance penalties. This is a "For Your Consideration" review not a pre-push changeset. The review changeset is a weakening of the "never share the String character array" rule and it means that it would suffer from exactly the same weakness. Few applications currently use subSequence() most currently use subString(). Applications which would benefit from this change would have to switch to using subSequence(). Apps can safely switch to subSequence in anticipation of this change because currently subSequence() is identical to substring(). This means that should this changeset not be integrated app code would suffer no penalty and if this change is eventually integrated then app performance will improve. > > http://cr.openjdk.java.net/~mduigou/JDK-7197183/0/ > > From our current testing we found that applications currently using subSequence() failed if the equals(), hashCode() and toString() implementations did not exactly match String. Additionally we had to change String.equals() so that it recognizes can return "true" for matching instances of String.SubSequence. > > You will see some unfortunate potential usage patterns in the presented implementation--most specifically, calling toString() on the result of a String.subSequence() results in a new String instance being created (ouch!). I would like to eliminate the caching of the hashCode() result but it appears that it is frequently used and failing to cache the hash code results in greatly decreased performance for the relevant applications. Currently TreeSet and TreeMap which use natural order fail for data sets of mixed String and String.SubSequence. I believe it is necessary for natural order sorting to work for mixed collections of String and String.SubSequence instances. > > Would this proposal cause your applications any problems? Is this proposal absolutely necessary for your application to have adequate performance? Have you already made other accommodations for the altered performance behaviour of Strings introduced in 7u6? Other thoughts? > > Mike From Alan.Bateman at oracle.com Tue Feb 19 10:08:12 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Feb 2013 10:08:12 +0000 Subject: JDK 8 request for review: two javadoc warning fixes, on in DateTimeFormatterBuilder, another in TimeZone In-Reply-To: <5123227B.7000403@oracle.com> References: <5123227B.7000403@oracle.com> Message-ID: <51234F0C.3090100@oracle.com> On 19/02/2013 06:58, Joe Darcy wrote: > Hello, > > Please review these two simple fixes for javadoc warnings I noticed > during a build (I'll file a bug after getting a review): Looks okay to me too, we seem to have picked up several javadoc warnings recently. -Alan From weijun.wang at oracle.com Tue Feb 19 10:27:33 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 19 Feb 2013 18:27:33 +0800 Subject: Truncate a LinkedList Message-ID: <51235395.5050008@oracle.com> Hi All I'm using LinkedList to maintain a history and the elements are ordered by their timestamps. Every now and then I would "expunge" the list, that is to say, iterating through the list and when an element is old enough all elements after (and including) it will be removed. Currently I'm removing them one by one. Is there a way to truncate the list using a single method? Thanks Max From daniel.fuchs at oracle.com Tue Feb 19 10:38:14 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 19 Feb 2013 11:38:14 +0100 Subject: Truncate a LinkedList In-Reply-To: <51235395.5050008@oracle.com> References: <51235395.5050008@oracle.com> Message-ID: <51235616.7050403@oracle.com> On 2/19/13 11:27 AM, Weijun Wang wrote: > Hi All > > I'm using LinkedList to maintain a history and the elements are ordered > by their timestamps. Every now and then I would "expunge" the list, that > is to say, iterating through the list and when an element is old enough > all elements after (and including) it will be removed. Currently I'm > removing them one by one. > > Is there a way to truncate the list using a single method? > > Thanks > Max Hi Max, You could try to use AbstractList.subList(...) Quoting from the doc: > For example, the following idiom removes a range of elements from a list: > > list.subList(from, to).clear(); > -- daniel From scolebourne at joda.org Tue Feb 19 10:53:21 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 19 Feb 2013 10:53:21 +0000 Subject: JDK 8 request for review: two javadoc warning fixes, on in DateTimeFormatterBuilder, another in TimeZone In-Reply-To: <5123227B.7000403@oracle.com> References: <5123227B.7000403@oracle.com> Message-ID: On 19 February 2013 06:58, Joe Darcy wrote: > diff -r bcde0486261e > src/share/classes/java/time/format/DateTimeFormatterBuilder.java > --- a/src/share/classes/java/time/format/DateTimeFormatterBuilder.java Mon > Feb 18 08:14:18 2013 +0000 > +++ b/src/share/classes/java/time/format/DateTimeFormatterBuilder.java Mon > Feb 18 22:55:56 2013 -0800 > @@ -1007,7 +1007,7 @@ > * is used, with {@code IsoChronology} as the fallback. > *

> * Note that this method provides similar functionality to methods on > - * {@code DateFormat} such as {@link > DateFormat#getDateTimeInstance(int, int)}. > + * {@code DateFormat} such as {@link > java.text.DateFormat#getDateTimeInstance(int, int)}. My preference would have been to add an import statement, but this fix is fine. Stephen From nils.loodin at oracle.com Tue Feb 19 10:57:07 2013 From: nils.loodin at oracle.com (Nils Loodin) Date: Tue, 19 Feb 2013 11:57:07 +0100 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: References: <5115316A.8050109@oracle.com> Message-ID: <51235A83.3010704@oracle.com> Hey Kasper! You're right that there are methods that throw exceptions as a part of the normal program flow. However, this number can be (and has been) used as a very high level telemetry for an application. Depending on exactly how large this number is, and how fast it is growing, something can be seen to be amis in the application. Paired together with data of what type of exceptions are being thrown, and from where, it can be useful for support to have this information. Regards, Nils Loodin On 02/12/2013 06:28 PM, Kasper Nielsen wrote: > Jrockit mission control supports an "exception count" based on exception > type. > > I have found the approach of just counting the total number of exception > completely useless. > Mainly because there are methods that throw exceptions as part of the > normal flow. For example, Class.forName() is commonly used to test > whether or not a certain > class is on the classpath. > > And most developers will cringe whenever they see an exception count>0 > for an application they think is bug free. > > > > > > On Fri, Feb 8, 2013 at 6:10 PM, Nils Loodin > wrote: > > It would be interesting to know the number of thrown throwables in > the JVM, to be able to do some high level application diagnostics / > statistics. A good way to put this number would be a performance > counter, since it is accessible both from Java and from the VM. > > http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=8007806 > > http://cr.openjdk.java.net/~__nloodin/8007806/webrev.00/ > > > Regards, > Nils Loodin > > From peter.levart at gmail.com Tue Feb 19 12:24:09 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 19 Feb 2013 13:24:09 +0100 Subject: Truncate a LinkedList In-Reply-To: <51235616.7050403@oracle.com> References: <51235395.5050008@oracle.com> <51235616.7050403@oracle.com> Message-ID: <51236EE9.5040506@gmail.com> On 02/19/2013 11:38 AM, Daniel Fuchs wrote: > On 2/19/13 11:27 AM, Weijun Wang wrote: >> Hi All >> >> I'm using LinkedList to maintain a history and the elements are ordered >> by their timestamps. Every now and then I would "expunge" the list, that >> is to say, iterating through the list and when an element is old enough >> all elements after (and including) it will be removed. Currently I'm >> removing them one by one. >> >> Is there a way to truncate the list using a single method? >> >> Thanks >> Max > > Hi Max, > > You could try to use AbstractList.subList(...) > > > > > Quoting from the doc: > >> For example, the following idiom removes a range of elements from a >> list: >> >> list.subList(from, to).clear(); >> Hi Daniel, That's not terribly efficient. It does the list.removeRange(from, to) which iterates the list again from the beginning to "from" followed by iterating elements further to "to" while removing elements one-by-one. That's worse than Weijun's original algorithm which iterates the elements from 1st to "from" only once. I would make my own linked structure for that task, but if you want to stick with LinkedList, your expunging algorithm could "copy" the elements, from the 1st to the one that is the last to be kept, into a new LinkedList and then just exchange the old list with the new... Regards, Peter > > -- daniel > > From peter.levart at gmail.com Tue Feb 19 12:36:12 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 19 Feb 2013 13:36:12 +0100 Subject: Truncate a LinkedList In-Reply-To: <51236EE9.5040506@gmail.com> References: <51235395.5050008@oracle.com> <51235616.7050403@oracle.com> <51236EE9.5040506@gmail.com> Message-ID: <512371BC.4000507@gmail.com> On 02/19/2013 01:24 PM, Peter Levart wrote: > On 02/19/2013 11:38 AM, Daniel Fuchs wrote: >> On 2/19/13 11:27 AM, Weijun Wang wrote: >>> Hi All >>> >>> I'm using LinkedList to maintain a history and the elements are ordered >>> by their timestamps. Every now and then I would "expunge" the list, >>> that >>> is to say, iterating through the list and when an element is old enough >>> all elements after (and including) it will be removed. Currently I'm >>> removing them one by one. >>> >>> Is there a way to truncate the list using a single method? >>> >>> Thanks >>> Max >> >> Hi Max, >> >> You could try to use AbstractList.subList(...) >> >> >> >> >> Quoting from the doc: >> >>> For example, the following idiom removes a range of elements from a >>> list: >>> >>> list.subList(from, to).clear(); >>> > Hi Daniel, > > That's not terribly efficient. It does the list.removeRange(from, to) > which iterates the list again from the beginning to "from" followed by > iterating elements further to "to" while removing elements one-by-one. > That's worse than Weijun's original algorithm which iterates the > elements from 1st to "from" only once. > > I would make my own linked structure for that task, but if you want to > stick with LinkedList, your expunging algorithm could "copy" the > elements, from the 1st to the one that is the last to be kept, into a > new LinkedList and then just exchange the old list with the new... Hi Weijun, The above would be efficient if the remaining "head" is small compared to the discarded "tail". If it's the other way around, you could iterate the LinkedList from the end backwards and remove the elements along the way until you reach the one you want to keep... > > Regards, Peter > >> >> -- daniel >> >> > From scolebourne at joda.org Tue Feb 19 12:58:27 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 19 Feb 2013 12:58:27 +0000 Subject: Truncate a LinkedList In-Reply-To: <51235395.5050008@oracle.com> References: <51235395.5050008@oracle.com> Message-ID: On 19 February 2013 10:27, Weijun Wang wrote: > I'm using LinkedList to maintain a history Don't use LinkedList. Multiple benchmarks down the years have shown it is almost always worse than ArrayList. Stephen > and the elements are ordered by > their timestamps. Every now and then I would "expunge" the list, that is to > say, iterating through the list and when an element is old enough all > elements after (and including) it will be removed. Currently I'm removing > them one by one. > > Is there a way to truncate the list using a single method? > > Thanks > Max From Roger.Riggs at Oracle.com Tue Feb 19 13:07:06 2013 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 19 Feb 2013 08:07:06 -0500 Subject: JDK 8 request for review: two javadoc warning fixes, on in DateTimeFormatterBuilder, another in TimeZone In-Reply-To: <5123227B.7000403@oracle.com> References: <5123227B.7000403@oracle.com> Message-ID: <512378FA.40201@Oracle.com> HI Joe, These look fine. I'd have been happy to fix these as ongoing ThreeTen work. We'll need to be more careful merging now that changes will be coming from other than the Threeten project. Thanks, Roger On 2/19/13 1:58 AM, Joe Darcy wrote: > Hello, > > Please review these two simple fixes for javadoc warnings I noticed > during a build (I'll file a bug after getting a review): > > diff -r bcde0486261e > src/share/classes/java/time/format/DateTimeFormatterBuilder.java > --- a/src/share/classes/java/time/format/DateTimeFormatterBuilder.java > Mon Feb 18 08:14:18 2013 +0000 > +++ b/src/share/classes/java/time/format/DateTimeFormatterBuilder.java > Mon Feb 18 22:55:56 2013 -0800 > @@ -1007,7 +1007,7 @@ > * is used, with {@code IsoChronology} as the fallback. > *

> * Note that this method provides similar functionality to > methods on > - * {@code DateFormat} such as {@link > DateFormat#getDateTimeInstance(int, int)}. > + * {@code DateFormat} such as {@link > java.text.DateFormat#getDateTimeInstance(int, int)}. > * > * @param dateStyle the date style to use, null means no date > required > * @param timeStyle the time style to use, null means no time > required > diff -r bcde0486261e src/share/classes/java/util/TimeZone.java > --- a/src/share/classes/java/util/TimeZone.java Mon Feb 18 08:14:18 > 2013 +0000 > +++ b/src/share/classes/java/util/TimeZone.java Mon Feb 18 22:55:56 > 2013 -0800 > @@ -534,7 +534,7 @@ > /** > * Gets the {@code TimeZone} for the given {@code zoneId}. > * > - * @param zoneid a {@link ZoneId} from which the time zone ID is > obtained > + * @param zoneId a {@link ZoneId} from which the time zone ID is > obtained > * @return the specified {@code TimeZone}, or the GMT zone if the > given ID > * cannot be understood. > * @throws NullPointerException if {@code zoneId} is {@code null} > > Thanks, > > -Joe From sean.coffey at oracle.com Tue Feb 19 14:12:02 2013 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Tue, 19 Feb 2013 14:12:02 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130219141238.723BE47B9B@hg.openjdk.java.net> Changeset: 885bb24f6018 Author: coffeys Date: 2013-02-19 14:07 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/885bb24f6018 7197187: Currency.isPastCutoverDate should be made more robust Reviewed-by: alanb ! src/share/classes/java/util/Currency.java Changeset: 01b6b0dd2006 Author: coffeys Date: 2013-02-19 14:12 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01b6b0dd2006 8007315: HttpURLConnection.filterHeaderField method returns null where empty string is expected Reviewed-by: chegar ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! test/sun/net/www/protocol/http/HttpOnly.java From forax at univ-mlv.fr Tue Feb 19 14:11:06 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 19 Feb 2013 15:11:06 +0100 Subject: FYC : JDK-7197183 : Improve copying behaviour of String.subSequence() In-Reply-To: <512345B8.1000205@gmail.com> References: <512345B8.1000205@gmail.com> Message-ID: <512387FA.8000909@univ-mlv.fr> Hi Mike, I agree with Peter, a new method is better than changing subSequence to return a CharSequence implementation that try to fake itself as a String. And as a guys that have written several parsers (for HTTP servers or not), ByteBuffer/CharBuffer was introduced in 1.4 to write effective parsers in Java, no one should try write a Java parser using String buffers anymore. R?mi On 02/19/2013 10:28 AM, Peter Levart wrote: > Hi Mike, > > Regarding the implementation details: I think it would be better to > reference just the String's value[] array in the String.SubSequence > instead of the String instance itself. Two reasons come to mind: > > - eliminate another indirection when accessing the array > - when referencing the String instance, code like this would leak > implementation details (again): > > String s = new String("..."); > CharSequence cs = s.subSequence(0, s.length()-1); > WeakReference wr = new WeakReference<>(s); > // ... if we keep a reference to cs, wr will never be cleared... > > Regarding the strategy: It's very unfortunate that code exists that > uses String.subSequence result in a way treating it as an object with > value semantics for equals() and hashCode() despite the specification > for CharSequence clearly stating: > > /"This interface does not refine the general contracts of the > //|equals| > //and > //|hashCode| > //methods. > The result of comparing two objects that implement //CharSequence//is > therefore, in general, undefined. Each object may be implemented by a > different class, and there is no guarantee that each class will be > capable of testing its instances for equality with those of the other. > It is therefore inappropriate to use arbitrary > //CharSequence//instances as elements in a set or as keys in a map."/ > > The excuse for such usage is the specification of String.subSequence > method: > > /"Returns a new character sequence that is a subsequence of this > sequence. / > > /An invocation of this method of the form / > > / str.subSequence(begin, end)/ > > /behaves in exactly the same way as the invocation / > > / str.substring(begin, end)/ > > /This method is defined so that the //String//class can implement the > //|CharSequence| > //interface. > "/ > > > So this proposal actually breaks this specification. It tries to break > it in a way that would keep some of the usages still behave like > before, but it can't entirely succeed. The following code is valid > now, but will throw CCE with this proposal: > > String s = ...; > String s0 = (String) s.subSequence(0, 1); > > One can imagine other scenarios that would break (like custom > comparators casting to String, etc.). > > So to be entirely compatible, an escape-hatch would have to be > available (in the form of a System property for example) to restore > the old behaviour if requested. > > If there is an escape-hatch, the question arises: Why not breaking the > String.subSequence entirely? We could brake it so that the method > would clearly specify the returned CharSequence behaviour regarding > underlying value[] array sharing, hashCode(), equals(), subSequence() > and Comparable only in terms of CharSequence instances returned from > the method and not cross String <-> String.SubSequence. > > This would encourage migration of behaviourally incompatible code to > forms that are compatible with both pre JDK8 and post JDK8 > String.subSequence specification instead of keeping the status quo. > > There's also a third option - adding new method (back-porting it to > JDK7): > > public String.SubSequence stringSubSequence(int, int); > > ...and keeping subSequence as is. > > Regards, Peter > > On 02/19/2013 06:27 AM, Mike Duigou wrote: >> Hello all; >> >> JDK 7u6 included a significant change to java.lang.String. The change >> was internal to the String implementation and didn't result in any >> API changes but it does have a significant impact on the performance >> of some uses cases. (See >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-June/010509.html >> for an earlier discussion) >> >> Prior to 7u6 String maintained two fields "count" and "offset" which >> described the location within the character array of the String's >> characters. In 7u6 the count and offset fields were removed and >> String instances no longer share their character arrays with other >> String instances. Each substring(), subSequence() or split() now >> creates entirely new String instances for it's results. Before 7u6 >> two or more instances of String could share the same backing >> character array. A number of String operations; clone(), split(), >> subString(), subSequence() did not copy the backing character array >> but created new String instances pointing at their character array >> with appropriate "count" and "offset" values. >> >> As with most sharing techniques, there are tradeoffs. The >> "count/offset" approach works reasonably well for cases where the >> substrings have a shorter lifetime than the original. Frequently it >> was found though that the large character arrays "leaked" through >> small Strings derived from larger String instances. Examples would be >> tokens parsed with substring() from HTTP headers being used as keys >> in Maps. This caused the entire header character array from the >> original header String to not be garbage collected (or worse the >> entire set of headers for a request). >> >> Our benchmarking and application testing prior to changing the String >> implementation in 7u6 showed that it was a net benefit to not share >> the character array instances. The benchmarking and performance >> testing for this change actually began in 2007 and was very >> extensive. Benchmarking and performance analysis since the release of >> 7u6 continues to indicate that removal of sharing is the better >> approach. It is extremely unlikely that we would consider returning >> to the pre-7u6 implementation (in case you were thinking of >> suggesting that). >> >> There are some cases where the new approach can result in significant >> performance penalties. This is a "For Your Consideration" review not >> a pre-push changeset. The review changeset is a weakening of the >> "never share the String character array" rule and it means that it >> would suffer from exactly the same weakness. Few applications >> currently use subSequence() most currently use subString(). >> Applications which would benefit from this change would have to >> switch to using subSequence(). Apps can safely switch to subSequence >> in anticipation of this change because currently subSequence() is >> identical to substring(). This means that should this changeset not >> be integrated app code would suffer no penalty and if this change is >> eventually integrated then app performance will improve. >> >> http://cr.openjdk.java.net/~mduigou/JDK-7197183/0/ >> >> From our current testing we found that applications currently using >> subSequence() failed if the equals(), hashCode() and toString() >> implementations did not exactly match String. Additionally we had to >> change String.equals() so that it recognizes can return "true" for >> matching instances of String.SubSequence. >> >> You will see some unfortunate potential usage patterns in the >> presented implementation--most specifically, calling toString() on >> the result of a String.subSequence() results in a new String instance >> being created (ouch!). I would like to eliminate the caching of the >> hashCode() result but it appears that it is frequently used and >> failing to cache the hash code results in greatly decreased >> performance for the relevant applications. Currently TreeSet and >> TreeMap which use natural order fail for data sets of mixed String >> and String.SubSequence. I believe it is necessary for natural order >> sorting to work for mixed collections of String and >> String.SubSequence instances. >> >> Would this proposal cause your applications any problems? Is this >> proposal absolutely necessary for your application to have adequate >> performance? Have you already made other accommodations for the >> altered performance behaviour of Strings introduced in 7u6? Other >> thoughts? >> >> Mike > From chris.hegarty at oracle.com Tue Feb 19 14:39:29 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 19 Feb 2013 14:39:29 +0000 Subject: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda Libraries In-Reply-To: <51230DAF.7030402@oracle.com> References: <2CB90323-8862-4735-BC75-7A1EB3C8276B@oracle.com> <51230DAF.7030402@oracle.com> Message-ID: <51238EA1.8030207@oracle.com> On 02/19/2013 05:29 AM, David Holmes wrote: > ... > Aside: it would be much easier to maintain consistent style if we used a > "template" to define the main outline of each family of interfaces and > generated the specializations from that (similar to how we generate the > various bytebuffer classes). Oh, please god no! I find the way the buffer classes are generated a real pain. Yes, it is good for maintaining consistency across similar versions, but I don't see that as a good justification to introduce this complexity. I was secretly hoping that nio Buffer generation would go away in jdk8. -Chris. From Ulf.Zibis at CoSoCo.de Tue Feb 19 15:07:15 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Tue, 19 Feb 2013 16:07:15 +0100 Subject: FYC : JDK-7197183 : Improve copying behaviour of String.subSequence() In-Reply-To: References: Message-ID: <51239523.2050606@CoSoCo.de> Am 19.02.2013 06:27, schrieb Mike Duigou: > http://cr.openjdk.java.net/~mduigou/JDK-7197183/0/ I think, you should add || (s instanceof AbstractStringBuilder) as third in else if ((s instanceof StringBuilder) || (s instanceof StringBuffer)) { , as someone could use his own subclass of AbstractStringBuilder. -Ulf From Alan.Bateman at oracle.com Tue Feb 19 15:08:16 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Feb 2013 15:08:16 +0000 Subject: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda Libraries In-Reply-To: <51238EA1.8030207@oracle.com> References: <2CB90323-8862-4735-BC75-7A1EB3C8276B@oracle.com> <51230DAF.7030402@oracle.com> <51238EA1.8030207@oracle.com> Message-ID: <51239560.1060505@oracle.com> On 19/02/2013 14:39, Chris Hegarty wrote: > : > > Oh, please god no! I find the way the buffer classes are generated a > real pain. Yes, it is good for maintaining consistency across similar > versions, but I don't see that as a good justification to introduce > this complexity. I was secretly hoping that nio Buffer generation > would go away in jdk8. I assume the "pain" with the generated buffer classes is in the IDE so you need to remember to include the gensrc tree in the project. -Alan. From chris.hegarty at oracle.com Tue Feb 19 15:14:41 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 19 Feb 2013 15:14:41 +0000 Subject: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda Libraries In-Reply-To: <51239560.1060505@oracle.com> References: <2CB90323-8862-4735-BC75-7A1EB3C8276B@oracle.com> <51230DAF.7030402@oracle.com> <51238EA1.8030207@oracle.com> <51239560.1060505@oracle.com> Message-ID: <512396E1.4010506@oracle.com> On 02/19/2013 03:08 PM, Alan Bateman wrote: > On 19/02/2013 14:39, Chris Hegarty wrote: >> : >> >> Oh, please god no! I find the way the buffer classes are generated a >> real pain. Yes, it is good for maintaining consistency across similar >> versions, but I don't see that as a good justification to introduce >> this complexity. I was secretly hoping that nio Buffer generation >> would go away in jdk8. > I assume the "pain" with the generated buffer classes is in the IDE so > you need to remember to include the gensrc tree in the project. Right, but this assumes you to have a build. They also don't play well with tools that index the source, like opengrok. -Chris. > > -Alan. From chris.hegarty at oracle.com Tue Feb 19 15:44:21 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 19 Feb 2013 15:44:21 +0000 Subject: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda Libraries In-Reply-To: <51230DAF.7030402@oracle.com> References: <2CB90323-8862-4735-BC75-7A1EB3C8276B@oracle.com> <51230DAF.7030402@oracle.com> Message-ID: <51239DD5.2060106@oracle.com> Mike, Thanks for updating the j.u.c classes. David seems to have covered most of the issues, otherwise looks fine to me. On 02/19/2013 05:29 AM, David Holmes wrote: > ... > package-info.java > > I've flagged this elsewhere but you may not have seen it: > > + * Predicate<String> > > If we use < then we should also use >. Additionally, typo 58 * and {@link java.util.function.Supplier} (@{code () -> T}). -Chris. From Alan.Bateman at oracle.com Tue Feb 19 15:46:42 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Feb 2013 15:46:42 +0000 Subject: JEP 161 SE Compact Profiles has pushed to jdk8/build forest In-Reply-To: <5122DB4D.4020302@oracle.com> References: <5122DB4D.4020302@oracle.com> Message-ID: <51239E62.8040603@oracle.com> On 19/02/2013 01:54, David Holmes wrote: > The implementation support for the Reference Implementation of the SE > Compact Profiles described by: > > http://openjdk.java.net/jeps/161 > > has now been pushed to the jdk8/build forest ready for integration > with jdk8/jdk8 in time for b78. > > This reference implementation is for the Linux platform only. > > To build the compact profiles JREs specify the "profiles" target to make: > > make profiles > > or to build the full JDK/JRE and profile images use: > > make images profiles One thing to add to David's mail. We have included a simple dependency analyzer that runs in the "profiles" build to catch changes that introduce new or undesirable dependencies, say someone mistakenly adds a dependency on AWT to one of the core classes. That should help catch issues quickly and also help keep the profile definitions up to date as jdk8 evolves. -Alan From kumar.x.srinivasan at oracle.com Tue Feb 19 15:49:28 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 19 Feb 2013 07:49:28 -0800 Subject: RFR: 8008262: pack200/MethodParameters change Message-ID: <51239F08.1090507@oracle.com> Hi, fyi. Let me know if you have any comments, the change is simple, the flag is being changed from a u4 to a u2. This has already been reviewed by jrose. http://cr.openjdk.java.net/~ksrini/8008262/webrev.jdk.0/ Thanks Kumar From Alan.Bateman at oracle.com Tue Feb 19 16:01:46 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Feb 2013 16:01:46 +0000 Subject: RFR (XS) 8008089: Delete OS dependent check in JdkFinder.getExecutable() In-Reply-To: <511B6134.3010005@oracle.com> References: <511B6134.3010005@oracle.com> Message-ID: <5123A1EA.6010404@oracle.com> On 13/02/2013 09:47, Yekaterina Kantserova wrote: > Hi everyone, > > This small fixconcerns jdk.testlibrary.JdkFinder utility class. The > check below is too OS dependent and should be deleted. > ... > binPath += File.separatorChar + "bin" + File.separatorChar + > executable; > File toolFile = new File(binPath); > ==> if (!toolFile.exists()) { > throw new RuntimeException(binPath + " does not exist"); > } > ... > > On windows if executable is specified as e.g. 'java', without '.exe', > the File exists() will fail. But it's still possible to run executable. This looks okay to me, do you have someone to push this for you? -Alan. From chris.hegarty at oracle.com Tue Feb 19 16:20:19 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 19 Feb 2013 16:20:19 +0000 Subject: hg: jdk8/tl/jdk: 8007609: WinNTFileSystem_md.c should correctly check value returned from realloc Message-ID: <20130219162050.551CD47BA0@hg.openjdk.java.net> Changeset: 824187de1591 Author: jzavgren Date: 2013-02-19 16:19 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/824187de1591 8007609: WinNTFileSystem_md.c should correctly check value returned from realloc Reviewed-by: alanb, chegar, dholmes ! src/windows/native/java/io/WinNTFileSystem_md.c From alan.bateman at oracle.com Tue Feb 19 17:11:32 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 19 Feb 2013 17:11:32 +0000 Subject: hg: jdk8/tl/jdk: 8008312: Re-enable MethodParameter tests in JDK Message-ID: <20130219171143.ABF3C47BA1@hg.openjdk.java.net> Changeset: e20c1c9197bf Author: emc Date: 2013-02-19 17:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e20c1c9197bf 8008312: Re-enable MethodParameter tests in JDK Reviewed-by: darcy ! src/share/classes/java/lang/reflect/Parameter.java ! test/java/lang/reflect/Parameter/WithParameters.java From martinrb at google.com Tue Feb 19 17:48:28 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 19 Feb 2013 09:48:28 -0800 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F6C0E4.2090401@oracle.com> References: <50EF4143.4090008@oracle.com> <50F408CF.6060207@oracle.com> <50F40D95.9050402@oracle.com> <50F44C72.60707@oracle.com> <50F483E7.6080504@oracle.com> <50F487CE.6010101@oracle.com> <50F48C5A.4040500@oracle.com> <8E0C1F8A-DF46-457C-81DB-0BC41FC5F2D5@oracle.com> <50F49B06.9070202@cs.oswego.edu> <50F50E1E.5040604@javaspecialists.eu> <50F558D7.5040509@cs.oswego.edu> <50F55B8F.40502@oracle.com> <50F55E7C.8040809@oracle.com> <50F56062.5070404@oracle.com> <50F584DD.6080108@oracle.com> <50F66BE4.3050305@gmail.com> <50F693A2.8030000@cs.oswego.edu> <50F6C0E4.2090401@oracle.com> Message-ID: On Wed, Jan 16, 2013 at 7:01 AM, Chris Hegarty wrote: > Thanks to all for the reviews and suggestions here. As you probably seen, > I pushed these changes to jdk8/tl earlier today (sorry, I missed Alan as an > official reviewer on the changeset.). Consider it an initial version, > pending any outcome from this, or other, discussions. > > Also, 8006409: "ThreadLocalRandom should dropping padding fields from its > serialized form", has been filed to follow up on the changes required to > update the serial form. > > For those watching, I was preferable to push on with these changes ( and I > apologize if it appeared pushy ), as the Double/Long Adder/Accumulator > implementation, Striped64, now has a dependency on this change. It has > become unbearable to keep in sync with different version of across > different repositories. Taking a look at this, I don't see any reason why we can't simply do (while maintaining serialization compatibility): diff --git a/src/share/classes/java/util/concurrent/ThreadLocalRandom.java b/src/share/classes/java/util/concurrent/ThreadLocalRandom.java --- a/src/share/classes/java/util/concurrent/ThreadLocalRandom.java +++ b/src/share/classes/java/util/concurrent/ThreadLocalRandom.java @@ -368,50 +368,6 @@ private static final long serialVersionUID = -5851777807851030925L; /** - * @serialField rnd long - * @serialField initialized boolean - * @serialField pad0 long - * @serialField pad1 long - * @serialField pad2 long - * @serialField pad3 long - * @serialField pad4 long - * @serialField pad5 long - * @serialField pad6 long - * @serialField pad7 long - */ - private static final ObjectStreamField[] serialPersistentFields = { - new ObjectStreamField("rnd", long.class), - new ObjectStreamField("initialized", boolean.class), - new ObjectStreamField("pad0", long.class), - new ObjectStreamField("pad1", long.class), - new ObjectStreamField("pad2", long.class), - new ObjectStreamField("pad3", long.class), - new ObjectStreamField("pad4", long.class), - new ObjectStreamField("pad5", long.class), - new ObjectStreamField("pad6", long.class), - new ObjectStreamField("pad7", long.class) }; - - /** - * Saves the {@code ThreadLocalRandom} to a stream (that is, serializes it). - */ - private void writeObject(java.io.ObjectOutputStream out) - throws java.io.IOException { - - java.io.ObjectOutputStream.PutField fields = out.putFields(); - fields.put("rnd", 0L); - fields.put("initialized", true); - fields.put("pad0", 0L); - fields.put("pad1", 0L); - fields.put("pad2", 0L); - fields.put("pad3", 0L); - fields.put("pad4", 0L); - fields.put("pad5", 0L); - fields.put("pad6", 0L); - fields.put("pad7", 0L); - out.writeFields(); - } - - /** * Returns the {@link #current() current} thread's {@code ThreadLocalRandom}. */ private Object readResolve() { From vicente.romero at oracle.com Tue Feb 19 17:54:38 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 19 Feb 2013 17:54:38 +0000 Subject: hg: jdk8/tl/langtools: 8006212: javac, convert jtreg tests from shell script to java Message-ID: <20130219175447.0916147BA5@hg.openjdk.java.net> Changeset: dc8b7aa7cef3 Author: vromero Date: 2013-02-19 17:53 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/dc8b7aa7cef3 8006212: javac, convert jtreg tests from shell script to java Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/util/ArrayUtils.java + test/tools/apt/Basics/CheckAptIsRemovedTest.java - test/tools/apt/Basics/NullAPF.java - test/tools/apt/Basics/apt.sh - test/tools/apt/verifyVariables.sh + test/tools/javac/4846262/CheckEBCDICLocaleTest.java - test/tools/javac/4846262/Test.java - test/tools/javac/4846262/Test.out - test/tools/javac/4846262/Test.sh + test/tools/javac/6302184/HiddenOptionsShouldUseGivenEncodingTest.java - test/tools/javac/6302184/T6302184.sh + test/tools/javac/ClassPathTest/ClassPathTest.java - 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.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/MissingInclude.java - test/tools/javac/MissingInclude.sh + test/tools/javac/MissingInclude/MissingIncludeTest.java - test/tools/javac/ProtectedInnerClass/ProtectedInnerClass.sh - test/tools/javac/ProtectedInnerClass/ProtectedInnerClass_2.java + test/tools/javac/ProtectedInnerClass/ProtectedInnerClassesTest.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/AssertionFailureTest.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/constDebug/ConstDebugTest.java - test/tools/javac/fatalErrors/NoJavaLang.java - test/tools/javac/fatalErrors/NoJavaLang.out - test/tools/javac/fatalErrors/NoJavaLang.sh + test/tools/javac/fatalErrors/NoJavaLangTest.java - test/tools/javac/innerClassFile/Driver.sh + test/tools/javac/innerClassFile/InnerClassFileTest.java - 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/JavaZipTest.java - test/tools/javac/javazip/Test.sh - test/tools/javac/javazip/bad/B.java - test/tools/javac/javazip/good/B.java + test/tools/javac/lib/ToolBox.java + test/tools/javac/links/LinksTest.java - test/tools/javac/links/T.java - test/tools/javac/links/b/B.java - test/tools/javac/links/links.sh + test/tools/javac/newlines/NewLineTest.java - test/tools/javac/newlines/Newlines.sh + test/tools/javac/stackmap/StackMapTest.java - test/tools/javac/stackmap/T4955930.java - test/tools/javac/stackmap/T4955930.sh ! test/tools/javac/unicode/SupplementaryJavaID6.java - test/tools/javac/unicode/SupplementaryJavaID6.sh + test/tools/javah/6257087/T6257087.java - 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/javah/T4942232/MissingParamClassTest.java + test/tools/javah/constMacroTest/ConstMacroTest.java + test/tools/javap/4798312/JavapShouldLoadClassesFromRTJarTest.java + test/tools/javap/4866831/PublicInterfaceTest.java - test/tools/javap/NotPackagePrivateInterface.java - test/tools/javap/PublicInterfaceTest.sh - test/tools/javap/pathsep.sh + test/tools/javap/stackmap/StackmapTest.java - test/tools/javap/stackmap/T6271292.java - test/tools/javap/stackmap/T6271292.out - test/tools/javap/stackmap/T6271292.sh From Alan.Bateman at oracle.com Tue Feb 19 18:35:31 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Feb 2013 18:35:31 +0000 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: References: <50EF4143.4090008@oracle.com> <50F408CF.6060207@oracle.com> <50F40D95.9050402@oracle.com> <50F44C72.60707@oracle.com> <50F483E7.6080504@oracle.com> <50F487CE.6010101@oracle.com> <50F48C5A.4040500@oracle.com> <8E0C1F8A-DF46-457C-81DB-0BC41FC5F2D5@oracle.com> <50F49B06.9070202@cs.oswego.edu> <50F50E1E.5040604@javaspecialists.eu> <50F558D7.5040509@cs.oswego.edu> <50F55B8F.40502@oracle.com> <50F55E7C.8040809@oracle.com> <50F56062.5070404@oracle.com> <50F584DD.6080108@oracle.com> <50F66BE4.3050305@gmail.com> <50F693A2.8030000@cs.oswego.edu> <50F6C0E4.2090401@oracle.com> Message-ID: <5123C5F3.7000106@oracle.com> On 19/02/2013 17:48, Martin Buchholz wrote: > : > > Taking a look at this, I don't see any reason why we can't simply do > (while maintaining serialization compatibility): Right, it's not needed and I think we had Chris persuaded on this a few weeks ago. It does change the serialized form but that it's not an issue issue and it doesn't matter that they have the default value when deserialized on an older release. -Alan. From naoto.sato at oracle.com Tue Feb 19 18:35:14 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 19 Feb 2013 18:35:14 +0000 Subject: hg: jdk8/tl/jdk: 7092447: Clarify the default locale used in each locale sensitive operation Message-ID: <20130219183537.5621847BA7@hg.openjdk.java.net> Changeset: af396ec087f4 Author: naoto Date: 2013-02-19 10:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/af396ec087f4 7092447: Clarify the default locale used in each locale sensitive operation Reviewed-by: okutsu ! src/share/classes/java/text/DateFormat.java ! src/share/classes/java/text/DateFormatSymbols.java ! src/share/classes/java/text/DecimalFormat.java ! src/share/classes/java/text/DecimalFormatSymbols.java ! src/share/classes/java/text/MessageFormat.java ! src/share/classes/java/text/NumberFormat.java ! src/share/classes/java/text/SimpleDateFormat.java ! src/share/classes/java/time/format/DateTimeFormatSymbols.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/Currency.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/GregorianCalendar.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/Scanner.java From joe.darcy at oracle.com Tue Feb 19 18:40:42 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 19 Feb 2013 10:40:42 -0800 Subject: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda Libraries In-Reply-To: <512396E1.4010506@oracle.com> References: <2CB90323-8862-4735-BC75-7A1EB3C8276B@oracle.com> <51230DAF.7030402@oracle.com> <51238EA1.8030207@oracle.com> <51239560.1060505@oracle.com> <512396E1.4010506@oracle.com> Message-ID: <5123C72A.30103@oracle.com> On 02/19/2013 07:14 AM, Chris Hegarty wrote: > On 02/19/2013 03:08 PM, Alan Bateman wrote: >> On 19/02/2013 14:39, Chris Hegarty wrote: >>> : >>> >>> Oh, please god no! I find the way the buffer classes are generated a >>> real pain. Yes, it is good for maintaining consistency across similar >>> versions, but I don't see that as a good justification to introduce >>> this complexity. I was secretly hoping that nio Buffer generation >>> would go away in jdk8. >> I assume the "pain" with the generated buffer classes is in the IDE so >> you need to remember to include the gensrc tree in the project. > Right, but this assumes you to have a build. They also don't play well > with tools that index the source, like opengrok. > > As an aside, a code generation technique that should play better with tooling would to be use an annotation processor to generate the code from within the context of the compiler/IDE. As a general-purpose meta-programming system, annotation processing doesn't have to be tied to annotations. -Joe From jonathan.gibbons at oracle.com Tue Feb 19 18:50:02 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 19 Feb 2013 10:50:02 -0800 Subject: hg: jdk8/tl/langtools: 8006212: javac, convert jtreg tests from shell script to java In-Reply-To: <20130219175447.0916147BA5@hg.openjdk.java.net> References: <20130219175447.0916147BA5@hg.openjdk.java.net> Message-ID: <5123C95A.3060703@oracle.com> Woohoo -- 23 shell tests replaced with equivalent Java code: that's over 2/3 of the shell tests in langtools/test. -- Jon On 02/19/2013 09:54 AM, vicente.romero at oracle.com wrote: > Changeset: dc8b7aa7cef3 > Author: vromero > Date: 2013-02-19 17:53 +0000 > URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/dc8b7aa7cef3 > > 8006212: javac, convert jtreg tests from shell script to java > Reviewed-by: jjg > > ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java > ! src/share/classes/com/sun/tools/javac/util/ArrayUtils.java > + test/tools/apt/Basics/CheckAptIsRemovedTest.java > - test/tools/apt/Basics/NullAPF.java > - test/tools/apt/Basics/apt.sh > - test/tools/apt/verifyVariables.sh > + test/tools/javac/4846262/CheckEBCDICLocaleTest.java > - test/tools/javac/4846262/Test.java > - test/tools/javac/4846262/Test.out > - test/tools/javac/4846262/Test.sh > + test/tools/javac/6302184/HiddenOptionsShouldUseGivenEncodingTest.java > - test/tools/javac/6302184/T6302184.sh > + test/tools/javac/ClassPathTest/ClassPathTest.java > - 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.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/MissingInclude.java > - test/tools/javac/MissingInclude.sh > + test/tools/javac/MissingInclude/MissingIncludeTest.java > - test/tools/javac/ProtectedInnerClass/ProtectedInnerClass.sh > - test/tools/javac/ProtectedInnerClass/ProtectedInnerClass_2.java > + test/tools/javac/ProtectedInnerClass/ProtectedInnerClassesTest.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/AssertionFailureTest.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/constDebug/ConstDebugTest.java > - test/tools/javac/fatalErrors/NoJavaLang.java > - test/tools/javac/fatalErrors/NoJavaLang.out > - test/tools/javac/fatalErrors/NoJavaLang.sh > + test/tools/javac/fatalErrors/NoJavaLangTest.java > - test/tools/javac/innerClassFile/Driver.sh > + test/tools/javac/innerClassFile/InnerClassFileTest.java > - 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/JavaZipTest.java > - test/tools/javac/javazip/Test.sh > - test/tools/javac/javazip/bad/B.java > - test/tools/javac/javazip/good/B.java > + test/tools/javac/lib/ToolBox.java > + test/tools/javac/links/LinksTest.java > - test/tools/javac/links/T.java > - test/tools/javac/links/b/B.java > - test/tools/javac/links/links.sh > + test/tools/javac/newlines/NewLineTest.java > - test/tools/javac/newlines/Newlines.sh > + test/tools/javac/stackmap/StackMapTest.java > - test/tools/javac/stackmap/T4955930.java > - test/tools/javac/stackmap/T4955930.sh > ! test/tools/javac/unicode/SupplementaryJavaID6.java > - test/tools/javac/unicode/SupplementaryJavaID6.sh > + test/tools/javah/6257087/T6257087.java > - 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/javah/T4942232/MissingParamClassTest.java > + test/tools/javah/constMacroTest/ConstMacroTest.java > + test/tools/javap/4798312/JavapShouldLoadClassesFromRTJarTest.java > + test/tools/javap/4866831/PublicInterfaceTest.java > - test/tools/javap/NotPackagePrivateInterface.java > - test/tools/javap/PublicInterfaceTest.sh > - test/tools/javap/pathsep.sh > + test/tools/javap/stackmap/StackmapTest.java > - test/tools/javap/stackmap/T6271292.java > - test/tools/javap/stackmap/T6271292.out > - test/tools/javap/stackmap/T6271292.sh > From Alan.Bateman at oracle.com Tue Feb 19 18:50:09 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Feb 2013 18:50:09 +0000 Subject: FYC : JDK-7197183 : Improve copying behaviour of String.subSequence() In-Reply-To: References: Message-ID: <5123C961.2070903@oracle.com> On 19/02/2013 05:27, Mike Duigou wrote: > : > > http://cr.openjdk.java.net/~mduigou/JDK-7197183/0/ > > From our current testing we found that applications currently using subSequence() failed if the equals(), hashCode() and toString() implementations did not exactly match String. Additionally we had to change String.equals() so that it recognizes can return "true" for matching instances of String.SubSequence. > I'm not sure about this either, especially with String.equals clearly specifying that the argument must be a String. The updates to AbstractStringBuilder append and insert seems unrelated, I assume you did measurements. Just wondering about separating them out as a separate patch? -Alan From mike.duigou at oracle.com Tue Feb 19 19:00:48 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 19 Feb 2013 11:00:48 -0800 Subject: FYC : JDK-7197183 : Improve copying behaviour of String.subSequence() In-Reply-To: <5123C961.2070903@oracle.com> References: <5123C961.2070903@oracle.com> Message-ID: On Feb 19 2013, at 10:50 , Alan Bateman wrote: > On 19/02/2013 05:27, Mike Duigou wrote: >> : >> >> http://cr.openjdk.java.net/~mduigou/JDK-7197183/0/ >> >> From our current testing we found that applications currently using subSequence() failed if the equals(), hashCode() and toString() implementations did not exactly match String. Additionally we had to change String.equals() so that it recognizes can return "true" for matching instances of String.SubSequence. >> > I'm not sure about this either, especially with String.equals clearly specifying that the argument must be a String. Yes, this patch is rather skanky in that it provides special "not normally something anyone should ever do" handling for String.SubSequence in String.equals(). This patch is an exploration of how far we could go to improve the performance of String.subSequence but it would certainly come at a definite cost. Creating this implementation has revealed usage patterns that are surprising and problematic (even with this patch). > The updates to AbstractStringBuilder append and insert seems unrelated, I assume you did measurements. Just wondering about separating them out as a separate patch? They certainly could be separated out. The changes in AbstractStringBuilder bring performance of: StringBuilder.append(string, lower, upper); in line with or improve upon: StringBuilder.append(string.substring(lower, upper)); This change was generated in response to this comment from Martin Desruisseaux which seems entirely reasonable optimization: http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-June/010667.html If I update this patch I will add Ulf suggestion of adding AbstractStringBuilder as a third instanceof case. Mike From Ulf.Zibis at CoSoCo.de Tue Feb 19 19:55:45 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Tue, 19 Feb 2013 20:55:45 +0100 Subject: FYC : JDK-7197183 : Improve copying behaviour of String.subSequence() In-Reply-To: References: <5123C961.2070903@oracle.com> Message-ID: <5123D8C1.9000308@CoSoCo.de> Am 19.02.2013 20:00, schrieb Mike Duigou: > If I update this patch I will add Ulf suggestion of adding AbstractStringBuilder as a third > instanceof case. Mike Thanks! I'm stil wondering, why HotSpot doesn't optimize for (int i = start, j = count; i < end; i++, j++) { value[j] = s.charAt(i); } to something equivalent of System.arrayCopy(...) Maybe we could introduce a new intrinsic for something like CharSequence.rangeCopy(int start, int end, CharSequence dst, int start) -Ulf From mike.duigou at oracle.com Tue Feb 19 19:58:06 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 19 Feb 2013 19:58:06 +0000 Subject: hg: jdk8/tl/jdk: 8004561: Additional functional interfaces, extension methods and name changes Message-ID: <20130219195818.338C147BAD@hg.openjdk.java.net> Changeset: 16efb7ba188f Author: mduigou Date: 2013-02-19 11:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/16efb7ba188f 8004561: Additional functional interfaces, extension methods and name changes Summary: Adds additional functional interfaces for primitives and "Bi" (two operand). Adds utility extension methods. Includes some name changes for existing functional interfaces per EG decisions. Reviewed-by: briangoetz, darcy, chegar, dholmes ! src/share/classes/java/time/chrono/HijrahDeviationReader.java ! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLong.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/DoubleAccumulator.java ! src/share/classes/java/util/concurrent/atomic/LongAccumulator.java ! src/share/classes/java/util/concurrent/atomic/Striped64.java + src/share/classes/java/util/function/BiConsumer.java + src/share/classes/java/util/function/BiFunction.java + src/share/classes/java/util/function/BiPredicate.java ! src/share/classes/java/util/function/BinaryOperator.java - src/share/classes/java/util/function/Block.java + src/share/classes/java/util/function/BooleanSupplier.java + src/share/classes/java/util/function/Consumer.java ! src/share/classes/java/util/function/DoubleBinaryOperator.java - src/share/classes/java/util/function/DoubleBlock.java + src/share/classes/java/util/function/DoubleConsumer.java ! src/share/classes/java/util/function/DoubleFunction.java + src/share/classes/java/util/function/DoublePredicate.java ! src/share/classes/java/util/function/DoubleSupplier.java ! src/share/classes/java/util/function/DoubleUnaryOperator.java ! src/share/classes/java/util/function/Function.java ! src/share/classes/java/util/function/IntBinaryOperator.java - src/share/classes/java/util/function/IntBlock.java + src/share/classes/java/util/function/IntConsumer.java ! src/share/classes/java/util/function/IntFunction.java + src/share/classes/java/util/function/IntPredicate.java ! src/share/classes/java/util/function/IntSupplier.java ! src/share/classes/java/util/function/IntUnaryOperator.java ! src/share/classes/java/util/function/LongBinaryOperator.java - src/share/classes/java/util/function/LongBlock.java + src/share/classes/java/util/function/LongConsumer.java ! src/share/classes/java/util/function/LongFunction.java + src/share/classes/java/util/function/LongPredicate.java ! src/share/classes/java/util/function/LongSupplier.java ! src/share/classes/java/util/function/LongUnaryOperator.java + src/share/classes/java/util/function/ObjDoubleConsumer.java + src/share/classes/java/util/function/ObjIntConsumer.java + src/share/classes/java/util/function/ObjLongConsumer.java ! src/share/classes/java/util/function/Predicate.java + src/share/classes/java/util/function/ToDoubleBiFunction.java + src/share/classes/java/util/function/ToDoubleFunction.java + src/share/classes/java/util/function/ToIntBiFunction.java + src/share/classes/java/util/function/ToIntFunction.java + src/share/classes/java/util/function/ToLongBiFunction.java + src/share/classes/java/util/function/ToLongFunction.java ! src/share/classes/java/util/function/UnaryOperator.java ! src/share/classes/java/util/function/package-info.java ! test/java/lang/PrimitiveSumMinMaxTest.java From jeremymanson at google.com Tue Feb 19 20:20:11 2013 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 19 Feb 2013 12:20:11 -0800 Subject: Define JNIEXPORT as visibility default with GCC? In-Reply-To: <5121F60C.5040004@redhat.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> Message-ID: Since the proposed change is user-visible (i.e., not just for building the JDK, but also for building pretty much every JNI blob in existence), wouldn't you want the correct check anyway? Does the JDK have rules about which version of gcc you are allowed to use to build JNI? Jeremy On Mon, Feb 18, 2013 at 1:36 AM, Florian Weimer wrote: > On 02/17/2013 11:55 PM, David Holmes wrote: > >> On 16/02/2013 2:46 AM, Florian Weimer wrote: >> >>> On 02/15/2013 05:41 PM, Jeremy Manson wrote: >>> >>>> Can we just blacklist 4.1.2 explicitly? >>>> >>> >>> Folks, per README-build.html, the minimum GCC version is 4.2 on MacOS X >>> and 4.3 everywhere else. Do we really have to bother with 4.1.2 at this >>> point? >>> >> >> There are ports that still use these older gcc versions. >> > > Oh. Perhaps this information can be added to README-builds.html? > > > -- > Florian Weimer / Red Hat Product Security Team > From mike.duigou at oracle.com Tue Feb 19 20:22:07 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 19 Feb 2013 12:22:07 -0800 Subject: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda Libraries In-Reply-To: <51230DAF.7030402@oracle.com> References: <2CB90323-8862-4735-BC75-7A1EB3C8276B@oracle.com> <51230DAF.7030402@oracle.com> Message-ID: Thank you for the feedback David. On Feb 18 2013, at 21:29 , David Holmes wrote: > package-info.java > > I've flagged this elsewhere but you may not have seen it: > > + * Predicate<String> > > If we use < then we should also use >. It's not required to use > in HTML 4.01 transitional or HTML 5.0. Doclint was complaining about this but it has (or soon will be) amended. It could still be a style requirement to use > I will push this changeset with ">" but assume that if the decision is to require ">" then doclint will remind us thoroughly and repeatedly to correct this before Java 8 is released. > Aside: it would be much easier to maintain consistent style if we used a "template" to define the main outline of each family of interfaces and generated the specializations from that (similar to how we generate the various bytebuffer classes). Like Chris I have mixed feelings about templating for similar reasons. Our current generated sources work very poorly with IDEs. If we can improve the user experience with generated sources I would be very much willing to consider it. Thanks again! Mike From sean.mullan at oracle.com Tue Feb 19 20:32:12 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Tue, 19 Feb 2013 20:32:12 +0000 Subject: hg: jdk8/tl/jdk: 8008107: [parfait] Use after free of pointer in jdk/src/share/native/sun/security/pkcs11/wrapper/p11_convert.c Message-ID: <20130219203225.2BB1847BB2@hg.openjdk.java.net> Changeset: 267bca6af07e Author: jzavgren Date: 2013-02-19 15:31 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/267bca6af07e 8008107: [parfait] Use after free of pointer in jdk/src/share/native/sun/security/pkcs11/wrapper/p11_convert.c Reviewed-by: mullan, chegar ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c From david.holmes at oracle.com Tue Feb 19 20:37:33 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Feb 2013 06:37:33 +1000 Subject: RFR: 8008481 Dependency analyzer needs exclusion for profile builds with JFR disabled Message-ID: <5123E28D.3020302@oracle.com> The new jar dependency analyzer detects unsatisfied dependencies in a profile build with JFR disabled: Analyzing /export/users/dh198349/jdk8-build/build/b77c/linux-i586-ea/images/j2re-compact3-image/lib/management-agent.jar Analyzing /export/users/dh198349/jdk8-build/build/b77c/linux-i586-ea/images/j2re-compact3-image/lib/jce.jar Analyzing /export/users/dh198349/jdk8-build/build/b77c/linux-i586-ea/images/j2re-compact3-image/lib/resources.jar Analyzing /export/users/dh198349/jdk8-build/build/b77c/linux-i586-ea/images/j2re-compact3-image/lib/jsse.jar Analyzing /export/users/dh198349/jdk8-build/build/b77c/linux-i586-ea/images/j2re-compact3-image/lib/rt.jar Analyzing /export/users/dh198349/jdk8-build/build/b77c/linux-i586-ea/images/j2re-compact3-image/lib/tzdb.jar com.sun.management.MissionControl -> com.oracle.jrockit.jfr.management.FlightRecorderMBean (unknown type) com.sun.management.MissionControl -> com.oracle.jrockit.jfr.FlightRecorder (unknown type) One or more unexpected references encountered Check /export/users/dh198349/jdk8-build/build/b77c/linux-i586-ea/jdk/btclasses/build/tools/deps/refs.allowed is up to date Fix is to add these two entries to ref.allowed http://cr.openjdk.java.net/~dholmes/8008481/webrev/ --- old/make/tools/src/build/tools/deps/refs.allowed 2013-02-19 15:36:37.863380282 -0500 +++ new/make/tools/src/build/tools/deps/refs.allowed 2013-02-19 15:36:36.551306476 -0500 @@ -33,3 +33,8 @@ # java.beans.PropertyChangeListener=java.util.logging.LogManager,sun.org.mozilla.javascript.internal.Context,compact1,compact2,compact3 java.beans.PropertyChangeEvent=sun.org.mozilla.javascript.internal.Context,compact3 + +# JFR traces even in builds with JFR disabled +com.oracle.jrockit.jfr.FlightRecorder: com.sun.management.MissionControl, compact3 +com.oracle.jrockit.jfr.management.FlightRecorderMBean: com.sun.management.MissionControl, compact3 + Thanks, David From Alan.Bateman at oracle.com Tue Feb 19 21:04:34 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Feb 2013 21:04:34 +0000 Subject: RFR: 8008481 Dependency analyzer needs exclusion for profile builds with JFR disabled In-Reply-To: <5123E28D.3020302@oracle.com> References: <5123E28D.3020302@oracle.com> Message-ID: <5123E8E2.3030409@oracle.com> On 19/02/2013 20:37, David Holmes wrote: > : > + > +# JFR traces even in builds with JFR disabled > +com.oracle.jrockit.jfr.FlightRecorder: > com.sun.management.MissionControl, compact3 > +com.oracle.jrockit.jfr.management.FlightRecorderMBean: > com.sun.management.MissionControl, compact3 > + This looks fine to okay and I know you need to get this resolved today.It is of course a workaround to a somewhat messy issue that needs separate follow-up. -Alan From chris.hegarty at oracle.com Tue Feb 19 21:09:53 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 19 Feb 2013 21:09:53 +0000 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <5123C5F3.7000106@oracle.com> References: <50EF4143.4090008@oracle.com> <50F408CF.6060207@oracle.com> <50F40D95.9050402@oracle.com> <50F44C72.60707@oracle.com> <50F483E7.6080504@oracle.com> <50F487CE.6010101@oracle.com> <50F48C5A.4040500@oracle.com> <8E0C1F8A-DF46-457C-81DB-0BC41FC5F2D5@oracle.com> <50F49B06.9070202@cs.oswego.edu> <50F50E1E.5040604@javaspecialists.eu> <50F558D7.5040509@cs.oswego.edu> <50F55B8F.40502@oracle.com> <50F55E7C.8040809@oracle.com> <50F56062.5070404@oracle.com> <50F584DD.6080108@oracle.com> <50F66BE4.3050305@gmail.com> <50F693A2.8030000@cs.oswego.edu> <50F6C0E4.2090401@oracle.com> <5123C5F3.7000106@oracle.com> Message-ID: <786DD039-A1BF-4202-A345-CCE22F0266F6@oracle.com> On 19 Feb 2013, at 18:35, Alan Bateman wrote: > On 19/02/2013 17:48, Martin Buchholz wrote: >> : >> >> Taking a look at this, I don't see any reason why we can't simply do >> (while maintaining serialization compatibility): > Right, it's not needed and I think we had Chris persuaded on this a few weeks ago. It does change the serialized form but that it's not an issue issue and it doesn't matter that they have the default value when deserialized on an older release. Agreed, but we do need to have this approved by the CCC. I'll follow up on this. -Chris > > -Alan. From zhong.j.yu at gmail.com Tue Feb 19 21:35:51 2013 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Tue, 19 Feb 2013 15:35:51 -0600 Subject: FYC : JDK-7197183 : Improve copying behaviour of String.subSequence() In-Reply-To: References: Message-ID: I think it's really easy for users to write a SubSequence by themselves if they need to solve the problem; there is no need for String to do it, and definitely not at the expense of breaching previous explicit contracts. We should solve this problem externally, explicitly; not internally with some surprising plumbings. The patch may not be very helpful anyway. It is unlikely that an application can simply switch from using sub-String to using sub-CharSequence, since CharSequence is not nearly as convenient as String - CharSequence has no contract on hashCode/equals, and no operations like indexOf() etc. CharSequence is still not widely used, not even in the standard lib - among java.** classes, besides subclasses of CharSequence/Appendable, there are only 4 classes with public methods accepting CharSequence args: Normalizer, Matcher, Pattern, CharsetEncoder. A new top level public class that mimics String is probably going to be helpful; this class may not be worthy of being included in java.lang; it could be provided by 3rd parties. The class should 1. be able to wrap any CharSequence and char[] source 2. reference the source without copying, till explicitly asked to 3. though not immutable, remain constant if source remains constant 4. have well defined hashCode/equals 5. have convenience operations like indexOf() 6. include popular methods from various StringUtils 7. have well defined space/time cost on all methods Let me call it "Strand". If anyone got a problem with the change of String impl, we can refer him to wrap the string in a Strand, and operate on the strand instead. Zhong Yu On Mon, Feb 18, 2013 at 11:27 PM, Mike Duigou wrote: > Hello all; > > JDK 7u6 included a significant change to java.lang.String. The change was internal to the String implementation and didn't result in any API changes but it does have a significant impact on the performance of some uses cases. (See http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-June/010509.html for an earlier discussion) > > Prior to 7u6 String maintained two fields "count" and "offset" which described the location within the character array of the String's characters. In 7u6 the count and offset fields were removed and String instances no longer share their character arrays with other String instances. Each substring(), subSequence() or split() now creates entirely new String instances for it's results. Before 7u6 two or more instances of String could share the same backing character array. A number of String operations; clone(), split(), subString(), subSequence() did not copy the backing character array but created new String instances pointing at their character array with appropriate "count" and "offset" values. > > As with most sharing techniques, there are tradeoffs. The "count/offset" approach works reasonably well for cases where the substrings have a shorter lifetime than the original. Frequently it was found though that the large character arrays "leaked" through small Strings derived from larger String instances. Examples would be tokens parsed with substring() from HTTP headers being used as keys in Maps. This caused the entire header character array from the original header String to not be garbage collected (or worse the entire set of headers for a request). > > Our benchmarking and application testing prior to changing the String implementation in 7u6 showed that it was a net benefit to not share the character array instances. The benchmarking and performance testing for this change actually began in 2007 and was very extensive. Benchmarking and performance analysis since the release of 7u6 continues to indicate that removal of sharing is the better approach. It is extremely unlikely that we would consider returning to the pre-7u6 implementation (in case you were thinking of suggesting that). > > There are some cases where the new approach can result in significant performance penalties. This is a "For Your Consideration" review not a pre-push changeset. The review changeset is a weakening of the "never share the String character array" rule and it means that it would suffer from exactly the same weakness. Few applications currently use subSequence() most currently use subString(). Applications which would benefit from this change would have to switch to using subSequence(). Apps can safely switch to subSequence in anticipation of this change because currently subSequence() is identical to substring(). This means that should this changeset not be integrated app code would suffer no penalty and if this change is eventually integrated then app performance will improve. > > http://cr.openjdk.java.net/~mduigou/JDK-7197183/0/ > > From our current testing we found that applications currently using subSequence() failed if the equals(), hashCode() and toString() implementations did not exactly match String. Additionally we had to change String.equals() so that it recognizes can return "true" for matching instances of String.SubSequence. > > You will see some unfortunate potential usage patterns in the presented implementation--most specifically, calling toString() on the result of a String.subSequence() results in a new String instance being created (ouch!). I would like to eliminate the caching of the hashCode() result but it appears that it is frequently used and failing to cache the hash code results in greatly decreased performance for the relevant applications. Currently TreeSet and TreeMap which use natural order fail for data sets of mixed String and String.SubSequence. I believe it is necessary for natural order sorting to work for mixed collections of String and String.SubSequence instances. > > Would this proposal cause your applications any problems? Is this proposal absolutely necessary for your application to have adequate performance? Have you already made other accommodations for the altered performance behaviour of Strings introduced in 7u6? Other thoughts? > > Mike From zhong.j.yu at gmail.com Tue Feb 19 21:49:14 2013 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Tue, 19 Feb 2013 15:49:14 -0600 Subject: API question for point lambdafication In-Reply-To: References: Message-ID: On Tue, Feb 19, 2013 at 2:45 PM, Ben Evans wrote: > Hi, > > I've got my regex point lambdafication patch going against the current > state of lambda, but now I have an API question I'd like some feedback > on. > > (Btw, if this is more appropriate for core-libs just let me know, and > I'll take my carcass over there & bug those guys instead.) > > I currently have this new method on java.util.regex.Pattern: > > public Stream splitAsStream(final CharSequence input); `input.subSequence()` can be expensive anyway; in String, StringBuilder and StringBuffer, the method will copy the chars in range. Therefore you may as well do the copy yourself to make Strings. Currently String does not have a constructor like public String(CharSequence source, int offset, int count) maybe it should be added? Zhong Yu > This provides a stream of values from the input CharSequence, split > around occurrences of this pattern. > > However, as the return type of splitAsStream() is > Stream, then we need to map stream values back to String > to be most useful, like this: > > List out = p.splitAsStream(s) > .map(cs -> cs.toString()) > .collect(Collectors.toList()); > > So, my question is this - should I continue to use the above > signature, or should it be: > > public Stream splitAsStream(final CharSequence input); > > This avoids the need for the intermediate map(), which seems like a > bit of a wart to me. > > Pattern has a vanilla split() method, which returns String[] - so for > those 2 reasons I'm minded towards the second form. > > Anyone else have any thoughts about this? > > Ben > From forax at univ-mlv.fr Tue Feb 19 21:53:10 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 19 Feb 2013 22:53:10 +0100 Subject: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda Libraries In-Reply-To: <5123C72A.30103@oracle.com> References: <2CB90323-8862-4735-BC75-7A1EB3C8276B@oracle.com> <51230DAF.7030402@oracle.com> <51238EA1.8030207@oracle.com> <51239560.1060505@oracle.com> <512396E1.4010506@oracle.com> <5123C72A.30103@oracle.com> Message-ID: <5123F446.1010600@univ-mlv.fr> On 02/19/2013 07:40 PM, Joe Darcy wrote: > On 02/19/2013 07:14 AM, Chris Hegarty wrote: >> On 02/19/2013 03:08 PM, Alan Bateman wrote: >>> On 19/02/2013 14:39, Chris Hegarty wrote: >>>> : >>>> >>>> Oh, please god no! I find the way the buffer classes are generated a >>>> real pain. Yes, it is good for maintaining consistency across similar >>>> versions, but I don't see that as a good justification to introduce >>>> this complexity. I was secretly hoping that nio Buffer generation >>>> would go away in jdk8. >>> I assume the "pain" with the generated buffer classes is in the IDE so >>> you need to remember to include the gensrc tree in the project. >> Right, but this assumes you to have a build. They also don't play well >> with tools that index the source, like opengrok. >> >> > > As an aside, a code generation technique that should play better with > tooling would to be use an annotation processor to generate the code > from within the context of the compiler/IDE. As a general-purpose > meta-programming system, annotation processing doesn't have to be tied > to annotations. hence the name :) > > -Joe R?mi From david.holmes at oracle.com Tue Feb 19 22:31:44 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Feb 2013 08:31:44 +1000 Subject: RFR: 8008481 Dependency analyzer needs exclusion for profile builds with JFR disabled In-Reply-To: <5123E8E2.3030409@oracle.com> References: <5123E28D.3020302@oracle.com> <5123E8E2.3030409@oracle.com> Message-ID: <5123FD50.9010501@oracle.com> Thanks Alan. cc'ing build-dev as this is technically build related and going into jdk8/build. David On 20/02/2013 7:04 AM, Alan Bateman wrote: > On 19/02/2013 20:37, David Holmes wrote: >> : >> + >> +# JFR traces even in builds with JFR disabled >> +com.oracle.jrockit.jfr.FlightRecorder: >> com.sun.management.MissionControl, compact3 >> +com.oracle.jrockit.jfr.management.FlightRecorderMBean: >> com.sun.management.MissionControl, compact3 >> + > This looks fine to okay and I know you need to get this resolved > today.It is of course a workaround to a somewhat messy issue that needs > separate follow-up. > > -Alan From peter.levart at gmail.com Tue Feb 19 22:58:51 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 19 Feb 2013 23:58:51 +0100 Subject: FYC : JDK-7197183 : Improve copying behaviour of String.subSequence() In-Reply-To: References: Message-ID: <512403AB.1080709@gmail.com> On 02/19/2013 10:35 PM, Zhong Yu wrote: > I think it's really easy for users to write a SubSequence by > themselves if they need to solve the problem; there is no need for > String to do it, and definitely not at the expense of breaching > previous explicit contracts. We should solve this problem externally, > explicitly; not internally with some surprising plumbings. > > The patch may not be very helpful anyway. It is unlikely that an > application can simply switch from using sub-String to using > sub-CharSequence, since CharSequence is not nearly as convenient as > String - CharSequence has no contract on hashCode/equals, and no > operations like indexOf() etc. CharSequence is still not widely used, > not even in the standard lib - among java.** classes, besides > subclasses of CharSequence/Appendable, there are only 4 classes with > public methods accepting CharSequence args: Normalizer, Matcher, > Pattern, CharsetEncoder. > > A new top level public class that mimics String is probably going to > be helpful; this class may not be worthy of being included in > java.lang; it could be provided by 3rd parties. The class should > > 1. be able to wrap any CharSequence and char[] source > 2. reference the source without copying, till explicitly asked to > 3. though not immutable, remain constant if source remains constant > 4. have well defined hashCode/equals > 5. have convenience operations like indexOf() > 6. include popular methods from various StringUtils > 7. have well defined space/time cost on all methods > > Let me call it "Strand". A Rope? http://en.wikipedia.org/wiki/Rope_%28data_structure%29 Peter > If anyone got a problem with the change of > String impl, we can refer him to wrap the string in a Strand, and > operate on the strand instead. > > Zhong Yu > > On Mon, Feb 18, 2013 at 11:27 PM, Mike Duigou wrote: >> Hello all; >> >> JDK 7u6 included a significant change to java.lang.String. The change was internal to the String implementation and didn't result in any API changes but it does have a significant impact on the performance of some uses cases. (See http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-June/010509.html for an earlier discussion) >> >> Prior to 7u6 String maintained two fields "count" and "offset" which described the location within the character array of the String's characters. In 7u6 the count and offset fields were removed and String instances no longer share their character arrays with other String instances. Each substring(), subSequence() or split() now creates entirely new String instances for it's results. Before 7u6 two or more instances of String could share the same backing character array. A number of String operations; clone(), split(), subString(), subSequence() did not copy the backing character array but created new String instances pointing at their character array with appropriate "count" and "offset" values. >> >> As with most sharing techniques, there are tradeoffs. The "count/offset" approach works reasonably well for cases where the substrings have a shorter lifetime than the original. Frequently it was found though that the large character arrays "leaked" through small Strings derived from larger String instances. Examples would be tokens parsed with substring() from HTTP headers being used as keys in Maps. This caused the entire header character array from the original header String to not be garbage collected (or worse the entire set of headers for a request). >> >> Our benchmarking and application testing prior to changing the String implementation in 7u6 showed that it was a net benefit to not share the character array instances. The benchmarking and performance testing for this change actually began in 2007 and was very extensive. Benchmarking and performance analysis since the release of 7u6 continues to indicate that removal of sharing is the better approach. It is extremely unlikely that we would consider returning to the pre-7u6 implementation (in case you were thinking of suggesting that). >> >> There are some cases where the new approach can result in significant performance penalties. This is a "For Your Consideration" review not a pre-push changeset. The review changeset is a weakening of the "never share the String character array" rule and it means that it would suffer from exactly the same weakness. Few applications currently use subSequence() most currently use subString(). Applications which would benefit from this change would have to switch to using subSequence(). Apps can safely switch to subSequence in anticipation of this change because currently subSequence() is identical to substring(). This means that should this changeset not be integrated app code would suffer no penalty and if this change is eventually integrated then app performance will improve. >> >> http://cr.openjdk.java.net/~mduigou/JDK-7197183/0/ >> >> From our current testing we found that applications currently using subSequence() failed if the equals(), hashCode() and toString() implementations did not exactly match String. Additionally we had to change String.equals() so that it recognizes can return "true" for matching instances of String.SubSequence. >> >> You will see some unfortunate potential usage patterns in the presented implementation--most specifically, calling toString() on the result of a String.subSequence() results in a new String instance being created (ouch!). I would like to eliminate the caching of the hashCode() result but it appears that it is frequently used and failing to cache the hash code results in greatly decreased performance for the relevant applications. Currently TreeSet and TreeMap which use natural order fail for data sets of mixed String and String.SubSequence. I believe it is necessary for natural order sorting to work for mixed collections of String and String.SubSequence instances. >> >> Would this proposal cause your applications any problems? Is this proposal absolutely necessary for your application to have adequate performance? Have you already made other accommodations for the altered performance behaviour of Strings introduced in 7u6? Other thoughts? >> >> Mike From daniel.daugherty at oracle.com Wed Feb 20 00:21:58 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 19 Feb 2013 17:21:58 -0700 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> Message-ID: <51241726.2040102@oracle.com> 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 On 2/19/13 1:20 PM, Jeremy Manson wrote: > Since the proposed change is user-visible (i.e., not just for building > the JDK, but also for building pretty much every JNI blob in > existence), wouldn't you want the correct check anyway? Does the JDK > have rules about which version of gcc you are allowed to use to build > JNI? > > Jeremy > > > On Mon, Feb 18, 2013 at 1:36 AM, Florian Weimer > wrote: > > On 02/17/2013 11:55 PM, David Holmes wrote: > > On 16/02/2013 2:46 AM, Florian Weimer wrote: > > On 02/15/2013 05:41 PM, Jeremy Manson wrote: > > Can we just blacklist 4.1.2 explicitly? > > > Folks, per README-build.html, the minimum GCC version is > 4.2 on MacOS X > and 4.3 everywhere else. Do we really have to bother with > 4.1.2 at this > point? > > > There are ports that still use these older gcc versions. > > > Oh. Perhaps this information can be added to README-builds.html? > > > -- > Florian Weimer / Red Hat Product Security Team > > From kumar.x.srinivasan at oracle.com Wed Feb 20 01:41:00 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Wed, 20 Feb 2013 01:41:00 +0000 Subject: hg: jdk8/tl/jdk: 8008262: pack200 should support MethodParameters - part 2 Message-ID: <20130220014112.58B8347BBD@hg.openjdk.java.net> Changeset: ec1a79c3a99c Author: ksrini Date: 2013-02-19 16:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ec1a79c3a99c 8008262: pack200 should support MethodParameters - part 2 Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.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 ! test/tools/pack200/AttributeTests.java ! test/tools/pack200/Utils.java From kumar.x.srinivasan at oracle.com Wed Feb 20 01:42:18 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Wed, 20 Feb 2013 01:42:18 +0000 Subject: hg: jdk8/tl/langtools: 8006948: Update javac for MethodParameters format change Message-ID: <20130220014220.9FB7447BBE@hg.openjdk.java.net> Changeset: 9345394ac8fe Author: ksrini Date: 2013-02-19 17:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9345394ac8fe 8006948: Update javac for MethodParameters format change Reviewed-by: ksrini, forax Contributed-by: eric.mccorkle at oracle.com ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/classfile/MethodParameters_attribute.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java From weijun.wang at oracle.com Wed Feb 20 03:10:00 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 20 Feb 2013 11:10:00 +0800 Subject: Truncate a LinkedList In-Reply-To: <512371BC.4000507@gmail.com> References: <51235395.5050008@oracle.com> <51235616.7050403@oracle.com> <51236EE9.5040506@gmail.com> <512371BC.4000507@gmail.com> Message-ID: <51243E88.7010203@oracle.com> In my case, I am planning to do an expunge when there are more old entries than new entries (or plus a constant), so the "head" and "tail" are likely of the same size. I'll think about creating my own LinkedList. It will be nice to just "break" at one link. Thanks Max On 2/19/13 8:36 PM, Peter Levart wrote: > On 02/19/2013 01:24 PM, Peter Levart wrote: >> On 02/19/2013 11:38 AM, Daniel Fuchs wrote: >>> On 2/19/13 11:27 AM, Weijun Wang wrote: >>>> Hi All >>>> >>>> I'm using LinkedList to maintain a history and the elements are ordered >>>> by their timestamps. Every now and then I would "expunge" the list, >>>> that >>>> is to say, iterating through the list and when an element is old enough >>>> all elements after (and including) it will be removed. Currently I'm >>>> removing them one by one. >>>> >>>> Is there a way to truncate the list using a single method? >>>> >>>> Thanks >>>> Max >>> >>> Hi Max, >>> >>> You could try to use AbstractList.subList(...) >>> >>> >>> >>> >>> Quoting from the doc: >>> >>>> For example, the following idiom removes a range of elements from a >>>> list: >>>> >>>> list.subList(from, to).clear(); >>>> >> Hi Daniel, >> >> That's not terribly efficient. It does the list.removeRange(from, to) >> which iterates the list again from the beginning to "from" followed by >> iterating elements further to "to" while removing elements one-by-one. >> That's worse than Weijun's original algorithm which iterates the >> elements from 1st to "from" only once. >> >> I would make my own linked structure for that task, but if you want to >> stick with LinkedList, your expunging algorithm could "copy" the >> elements, from the 1st to the one that is the last to be kept, into a >> new LinkedList and then just exchange the old list with the new... > Hi Weijun, > > The above would be efficient if the remaining "head" is small compared > to the discarded "tail". If it's the other way around, you could iterate > the LinkedList from the end backwards and remove the elements along the > way until you reach the one you want to keep... > >> >> Regards, Peter >> >>> >>> -- daniel >>> >>> >> > From david.holmes at oracle.com Wed Feb 20 03:26:39 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Feb 2013 13:26:39 +1000 Subject: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda Libraries In-Reply-To: <51238EA1.8030207@oracle.com> References: <2CB90323-8862-4735-BC75-7A1EB3C8276B@oracle.com> <51230DAF.7030402@oracle.com> <51238EA1.8030207@oracle.com> Message-ID: <5124426F.4020404@oracle.com> On 20/02/2013 12:39 AM, Chris Hegarty wrote: > > On 02/19/2013 05:29 AM, David Holmes wrote: >> ... >> Aside: it would be much easier to maintain consistent style if we used a >> "template" to define the main outline of each family of interfaces and >> generated the specializations from that (similar to how we generate the >> various bytebuffer classes). > > Oh, please god no! I find the way the buffer classes are generated a > real pain. Yes, it is good for maintaining consistency across similar > versions, but I don't see that as a good justification to introduce this > complexity. I was secretly hoping that nio Buffer generation would go > away in jdk8. :) I only meant as a tool during development of the classes, not to actually generate them as part of the build. Sorry for alarming you like that. :) David > -Chris. From david.holmes at oracle.com Wed Feb 20 03:37:21 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Feb 2013 13:37:21 +1000 Subject: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda Libraries In-Reply-To: References: <2CB90323-8862-4735-BC75-7A1EB3C8276B@oracle.com> <51230DAF.7030402@oracle.com> Message-ID: <512444F1.2010600@oracle.com> On 20/02/2013 6:22 AM, Mike Duigou wrote: > Thank you for the feedback David. So what got updated, if anything, before the push? The biggest gripe I have with reviewing all this stuff is being able to keep track of what comments have been made, what comments have been acted upon and what is still outstanding. I'd love to see a nightly doc build with change bars; or a doc build with "annotations" highlighting known issues. Don't know if we have any tools capable of that though. > On Feb 18 2013, at 21:29 , David Holmes wrote: > >> package-info.java >> >> I've flagged this elsewhere but you may not have seen it: >> >> + * Predicate<String> >> >> If we use < then we should also use >. > > It's not required to use > in HTML 4.01 transitional or HTML 5.0. Doclint was complaining about this but it has (or soon will be) amended. It could still be a style requirement to use > Nothing like being inconsistent :( (that's directed at HTML standard) > I will push this changeset with ">" but assume that if the decision is to require ">" then doclint will remind us thoroughly and repeatedly to correct this before Java 8 is released. > >> Aside: it would be much easier to maintain consistent style if we used a "template" to define the main outline of each family of interfaces and generated the specializations from that (similar to how we generate the various bytebuffer classes). > > Like Chris I have mixed feelings about templating for similar reasons. Our current generated sources work very poorly with IDEs. If we can improve the user experience with generated sources I would be very much willing to consider it. As I replied to Chris I didn't mean that as a permanent feature or even something committed at this stage - simply a tool to help with these repetitive definitions of class/method docs to ensure that they are consistent in the way they name and express things. Maybe there isn't enough commonality to make this worthwhile (you may still have multiple templates to keep consistent), but I know from past experience that this level of consistency is one of the hardest things to get right - it is tedious and error prone. Cheers, David > Thanks again! > > Mike > From mike.duigou at oracle.com Wed Feb 20 03:52:33 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 19 Feb 2013 19:52:33 -0800 Subject: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda Libraries In-Reply-To: <512444F1.2010600@oracle.com> References: <2CB90323-8862-4735-BC75-7A1EB3C8276B@oracle.com> <51230DAF.7030402@oracle.com> <512444F1.2010600@oracle.com> Message-ID: On Feb 19 2013, at 19:37 , David Holmes wrote: > On 20/02/2013 6:22 AM, Mike Duigou wrote: >> Thank you for the feedback David. > > So what got updated, if anything, before the push? Everything. With the exception of the > which I mentioned in my response I accepted all of your feedback suggestions as well as Chris's. It was good feedback! > The biggest gripe I have with reviewing all this stuff is being able to keep track of what comments have been made, what comments have been acted upon and what is still outstanding. Yes, from experience it's been too easy for review feedback and comments to get lost. I do try to either address as many of the comments as possible and proceed to produce an updated webrev or if nothing seems blocking, push the changeset. > I'd love to see a nightly doc build with change bars; or a doc build with "annotations" highlighting known issues. Don't know if we have any tools capable of that though. We don't unfortunately. And ultimately you'd want to be able to diff any two arbitrary versions from the repository. Tools like specdiff do exist for this but aren't hooked up in such a way to make generating the necessary reports simple. It's an infrastructure and tooling shortcoming. :-( >> On Feb 18 2013, at 21:29 , David Holmes wrote: >> >>> package-info.java >>> >>> I've flagged this elsewhere but you may not have seen it: >>> >>> + * Predicate<String> >>> >>> If we use < then we should also use >. >> >> It's not required to use > in HTML 4.01 transitional or HTML 5.0. Doclint was complaining about this but it has (or soon will be) amended. It could still be a style requirement to use > > > Nothing like being inconsistent :( (that's directed at HTML standard) > > >> I will push this changeset with ">" but assume that if the decision is to require ">" then doclint will remind us thoroughly and repeatedly to correct this before Java 8 is released. >> >>> Aside: it would be much easier to maintain consistent style if we used a "template" to define the main outline of each family of interfaces and generated the specializations from that (similar to how we generate the various bytebuffer classes). >> >> Like Chris I have mixed feelings about templating for similar reasons. Our current generated sources work very poorly with IDEs. If we can improve the user experience with generated sources I would be very much willing to consider it. > > As I replied to Chris I didn't mean that as a permanent feature or even something committed at this stage - simply a tool to help with these repetitive definitions of class/method docs to ensure that they are consistent in the way they name and express things. Maybe there isn't enough commonality to make this worthwhile (you may still have multiple templates to keep consistent), but I know from past experience that this level of consistency is one of the hardest things to get right - it is tedious and error prone. I have been using a merge tool, meld, to try to make fewer transcription errors between the primitive specializations. I agree that some form of template would be the best solution in the long run. We could add an explicit gensrc target to our make process which caused all of the generated/templated sources to be build for consumption by IDEs (and later build phases). This is the workflow used by maven projects and it seems to be OK. When you clone or update a maven project you re-run the equivalent of configure+gensrc to get the project ready for use by IDE tools. > > Cheers, > David > >> Thanks again! >> >> Mike >> From lana.steuck at oracle.com Wed Feb 20 05:40:31 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 20 Feb 2013 05:40:31 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20130220054033.9558647BCE@hg.openjdk.java.net> Changeset: 27d6368ae8ba Author: katleman Date: 2013-02-14 11:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/27d6368ae8ba Added tag jdk8-b77 for changeset 35684a40c584 ! .hgtags Changeset: c528d8ce83f1 Author: lana Date: 2013-02-19 20:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/c528d8ce83f1 Merge From lana.steuck at oracle.com Wed Feb 20 05:40:31 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 20 Feb 2013 05:40:31 +0000 Subject: hg: jdk8/tl: 3 new changesets Message-ID: <20130220054031.A3D9A47BCD@hg.openjdk.java.net> Changeset: 45dcccc6d221 Author: katleman Date: 2013-02-14 11:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/45dcccc6d221 Added tag jdk8-b77 for changeset 3933eebc659d ! .hgtags Changeset: bbb7548d45c7 Author: lana Date: 2013-02-14 22:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/bbb7548d45c7 Merge Changeset: eca3bce3d151 Author: lana Date: 2013-02-19 20:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/eca3bce3d151 Merge From lana.steuck at oracle.com Wed Feb 20 05:40:36 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 20 Feb 2013 05:40:36 +0000 Subject: hg: jdk8/tl/jaxp: Added tag jdk8-b77 for changeset 573e789c187a Message-ID: <20130220054042.817EB47BCF@hg.openjdk.java.net> Changeset: 00958c5a7070 Author: katleman Date: 2013-02-14 11:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/00958c5a7070 Added tag jdk8-b77 for changeset 573e789c187a ! .hgtags From lana.steuck at oracle.com Wed Feb 20 05:40:40 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 20 Feb 2013 05:40:40 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20130220054051.84E8F47BD1@hg.openjdk.java.net> Changeset: bc24411bcc37 Author: katleman Date: 2013-02-14 11:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bc24411bcc37 Added tag jdk8-b77 for changeset 89c664151689 ! .hgtags Changeset: a3aa32fe4536 Author: lana Date: 2013-02-14 22:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a3aa32fe4536 Merge Changeset: 4cf6e84f844f Author: lana Date: 2013-02-19 20:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4cf6e84f844f Merge From lana.steuck at oracle.com Wed Feb 20 05:40:40 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 20 Feb 2013 05:40:40 +0000 Subject: hg: jdk8/tl/jaxws: Added tag jdk8-b77 for changeset 64dfba1bad16 Message-ID: <20130220054044.CFFBD47BD0@hg.openjdk.java.net> Changeset: 391de4c992d1 Author: katleman Date: 2013-02-14 11:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/391de4c992d1 Added tag jdk8-b77 for changeset 64dfba1bad16 ! .hgtags From lana.steuck at oracle.com Wed Feb 20 05:40:54 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 20 Feb 2013 05:40:54 +0000 Subject: hg: jdk8/tl/hotspot: 36 new changesets Message-ID: <20130220054204.A4CF347BD2@hg.openjdk.java.net> Changeset: 1f84c84f8e1a Author: katleman Date: 2013-02-14 11:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1f84c84f8e1a Added tag jdk8-b77 for changeset cdb46031e718 ! .hgtags Changeset: 1a0174612b49 Author: amurillo Date: 2013-02-08 08:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1a0174612b49 8007801: new hotspot build - hs25-b19 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 8d9fc28831cc Author: dcubed Date: 2013-02-06 14:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8d9fc28831cc 7182152: Instrumentation hot swap test incorrect monitor count Summary: Add/refine new tracing support using -XX:TraceRedefineClasses=16384. Reviewed-by: coleenp, acorn, sspitsyn ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/cpCache.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp ! src/share/vm/prims/jvmtiRedefineClassesTrace.hpp ! src/share/vm/utilities/accessFlags.cpp ! src/share/vm/utilities/accessFlags.hpp Changeset: 3a88007634b0 Author: ctornqvi Date: 2013-02-08 10:42 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3a88007634b0 8007434: Write tests for 8006298 Summary: Four tests written for 8006298 Reviewed-by: mgerdin, coleenp + test/runtime/CommandLine/BooleanFlagWithInvalidValue.java + test/runtime/CommandLine/FlagWithInvalidValue.java + test/runtime/CommandLine/NonBooleanFlagWithInvalidBooleanPrefix.java + test/runtime/CommandLine/UnrecognizedVMOption.java Changeset: 758935f7c23f Author: sla Date: 2013-02-08 12:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/758935f7c23f 8006423: SA: NullPointerException in sun.jvm.hotspot.debugger.bsd.BsdThread.getContext(BsdThread.java:67) Summary: Do not rely on mach thread port names to identify threads from SA Reviewed-by: dholmes, minqi, rbackman ! agent/src/os/bsd/MacosxDebuggerLocal.m ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/bsd_amd64/BsdAMD64JavaThreadPDAccess.java ! src/os/bsd/vm/osThread_bsd.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os_cpu/bsd_x86/vm/vmStructs_bsd_x86.hpp Changeset: 7194f764221c Author: sla Date: 2013-02-08 14:05 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7194f764221c Merge Changeset: 461a3adac4d1 Author: sspitsyn Date: 2013-02-08 09:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/461a3adac4d1 Merge ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp Changeset: 8bf62bd86a4e Author: zgu Date: 2013-02-08 14:49 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8bf62bd86a4e 8007791: More Restricted hs_err file permission Summary: Enforce more restricted hs_file permission Reviewed-by: acorn, dcubed, dsamersoff ! src/share/vm/utilities/vmError.cpp Changeset: 1ba5b18088a8 Author: zgu Date: 2013-02-08 14:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1ba5b18088a8 Merge Changeset: 41d73c9b30a8 Author: zgu Date: 2013-02-08 16:31 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/41d73c9b30a8 8006691: Remove jvm_version_info.is_kernel_jvm field Summary: Removed is_kernel_jvm from jvm_version_info as Kernel VM has been deprecated Reviewed-by: mchung, coleenp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: 3f11b37f047c Author: zgu Date: 2013-02-08 13:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3f11b37f047c Merge Changeset: f989aff6946f Author: zgu Date: 2013-02-08 16:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f989aff6946f Merge Changeset: 927a311d00f9 Author: coleenp Date: 2013-02-11 14:06 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/927a311d00f9 8007320: NPG: move method annotations Summary: allocate method annotations and attach to ConstMethod if present Reviewed-by: dcubed, jiangli, sspitsyn, iklam ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/oops/annotations.cpp ! src/share/vm/oops/annotations.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 ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/vmStructs.cpp + test/runtime/8007320/ConstMethodTest.java Changeset: 5ee2b330eacd Author: zgu Date: 2013-02-12 12:19 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5ee2b330eacd 8007950: Undo hs_file permission change Summary: Reverse hs_err file permission back to 0666, as early push was premature Reviewed-by: dsamersoff, dcubed, acorn ! src/share/vm/utilities/vmError.cpp Changeset: deb43b8a436e Author: sspitsyn Date: 2013-02-13 08:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/deb43b8a436e Merge Changeset: bce1ac447f6b Author: johnc Date: 2013-02-06 14:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bce1ac447f6b 7052429: G1: Avoid unnecessary scanning of humongous regions during concurrent marking Summary: Skip unnecessary scanning of bitmap for unmarked humongous objects/regions. Reviewed-by: jwilhelm, johnc Contributed-by: Tao Mao ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/runtime/globals.hpp Changeset: f64ffbf81af5 Author: jwilhelm Date: 2013-02-07 15:51 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f64ffbf81af5 8006432: Ratio flags should be unsigned Summary: Flags changed to be of uintx type Reviewed-by: johnc, tamao ! src/cpu/zero/vm/shark_globals_zero.hpp ! src/os_cpu/bsd_x86/vm/globals_bsd_x86.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 5d8325eb8240 Author: brutisso Date: 2013-02-07 22:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5d8325eb8240 Merge ! src/share/vm/runtime/thread.cpp Changeset: 9425ba04792d Author: brutisso Date: 2013-02-07 18:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9425ba04792d Merge - agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java - make/solaris/makefiles/kernel.make ! src/share/vm/runtime/arguments.cpp - test/runtime/7158988/TestFieldMonitor.sh Changeset: ad747ee9d0b1 Author: brutisso Date: 2013-02-10 21:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ad747ee9d0b1 8002144: G1: large number of evacuation failures may lead to large c heap memory usage Summary: Use Stack<> instead of GrowableArray to keep track of preserved marks. Also reviewed by vitalyd at gmail.com. Reviewed-by: johnc, jcoomes ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 5e401ef52ec0 Author: johnc Date: 2013-02-11 15:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5e401ef52ec0 8007772: G1: assert(!hr->isHumongous() || mr.start() == hr->bottom()) failed: the start of HeapRegion and MemRegion should be consistent for humongous regions Summary: In do_marking_step(), we should always give up current region after scanning the object, if the region is humongous. Reviewed-by: brutisso, jwilhelm, tamao ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: a83cd101fd62 Author: jmasa Date: 2013-01-23 19:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a83cd101fd62 8005452: NPG: Create new flags for Metaspace resizing policy Reviewed-by: johnc, jwilhelm, coleenp, stefank ! src/share/vm/memory/metaspace.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: b8d5d7a6c94c Author: brutisso Date: 2013-02-14 11:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b8d5d7a6c94c Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/thread.cpp Changeset: 91a23b11d8dc Author: kvn Date: 2013-02-08 15:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/91a23b11d8dc 8007708: compiler/6855215 assert(VM_Version::supports_sse4_2()) Summary: Added missing UseSSE42 check. Also added missing avx2 assert for vpermq instruction. Reviewed-by: roland, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp Changeset: 309460dcedf7 Author: morris Date: 2013-02-08 15:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/309460dcedf7 8006851: When TieredCompilation is set, max code cache should be bumped to 256mb Summary: Set ReservedCodeCacheSize to (default value)*5 when TieredCompilation is on. Reviewed-by: kvn, twisti ! src/share/vm/runtime/arguments.cpp Changeset: 2c673161698a Author: drchase Date: 2013-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2c673161698a 8007402: Code cleanup to remove Parfait false positive Summary: add array access range check Reviewed-by: kvn ! src/share/vm/opto/regmask.cpp ! src/share/vm/opto/regmask.hpp Changeset: 64d2a0a39954 Author: kmo Date: 2013-02-10 22:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/64d2a0a39954 8006430: TraceTypeProfile is a product flag while it should be a diagnostic flag Summary: make sure all diagnostic and experimental flag kinds are checked in Flag::is_unlocked() Reviewed-by: kvn ! src/share/vm/runtime/globals.cpp Changeset: a9c29dfc7d73 Author: morris Date: 2013-02-11 10:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a9c29dfc7d73 8003251: ARM: move MacroAssembler into separate file Summary: moved MacroAssembler into separate file Reviewed-by: twisti, kvn, dlong ! src/share/vm/asm/macroAssembler.hpp ! src/share/vm/asm/macroAssembler.inline.hpp Changeset: 1e5e28bac299 Author: morris Date: 2013-02-11 14:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1e5e28bac299 8003252: PPC: move MacroAssembler into separate file Summary: moved MacroAssembler into separate file Reviewed-by: twisti, kvn, dlong ! src/share/vm/asm/macroAssembler.hpp ! src/share/vm/asm/macroAssembler.inline.hpp Changeset: 8b3da8d14c93 Author: roland Date: 2013-02-12 12:56 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8b3da8d14c93 7197327: 40% regression on 8 b41 comp 8 b40 on specjvm2008.mpegaudio on oob Summary: Add support for expensive nodes. Reviewed-by: kvn ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/subnode.hpp Changeset: c703f9c4b025 Author: kmo Date: 2013-02-12 07:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c703f9c4b025 8002169: TEST_BUG: compiler/7009359/Test7009359.java sometimes times out Summary: make the test less prone to timeout by reducing the amount of iteration and allowing main to be compiled Reviewed-by: jrose ! test/compiler/7009359/Test7009359.java Changeset: aaad39923cdb Author: kmo Date: 2013-02-12 14:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aaad39923cdb Merge Changeset: 12e01444ca2d Author: iignatyev Date: 2013-02-13 08:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/12e01444ca2d 8006683: Add WhiteBox API to testing of compiler Reviewed-by: kvn, vlivanov ! src/share/tools/whitebox/sun/hotspot/WhiteBox.java ! src/share/vm/prims/wbtestmethods/parserTests.hpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/prims/whitebox.hpp + test/compiler/whitebox/CompilerWhiteBoxTest.java + 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 Changeset: 1cdf241a4b26 Author: vlivanov Date: 2013-02-14 05:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1cdf241a4b26 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 9f19f4a7d48a Author: amurillo Date: 2013-02-15 13:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9f19f4a7d48a Merge Changeset: d5e12e7d2f71 Author: amurillo Date: 2013-02-15 13:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d5e12e7d2f71 Added tag hs25-b19 for changeset 9f19f4a7d48a ! .hgtags From lana.steuck at oracle.com Wed Feb 20 05:41:41 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 20 Feb 2013 05:41:41 +0000 Subject: hg: jdk8/tl/jdk: 19 new changesets Message-ID: <20130220054532.A7D0947BD3@hg.openjdk.java.net> Changeset: c1304eb051f6 Author: katleman Date: 2013-02-14 11:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1304eb051f6 Added tag jdk8-b77 for changeset b2fc8e31cecc ! .hgtags Changeset: 37719b174e87 Author: jgodinez Date: 2013-02-06 14:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/37719b174e87 8005194: [parfait] #353 sun/awt/image/jpeg/imageioJPEG.c Memory leak of pointer 'scale' allocated with calloc() Reviewed-by: prr, vadim Contributed-by: jia-hong.chen at oracle.com ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c Changeset: ad49012d10a1 Author: jgodinez Date: 2013-02-08 11:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ad49012d10a1 8005129: [parfait] #1122 - #1130 native/sun/awt/medialib/mlib_Image*.c Memory leak of pointer 'k' allocated with mlib_malloc Reviewed-by: prr, vadim Contributed-by: jia-hong.chen at oracle.com ! src/share/native/sun/awt/medialib/mlib_ImageConv.h ! src/share/native/sun/awt/medialib/mlib_ImageConvMxN_ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_16ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_16nw.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_32nw.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_8ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_8nw.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_u16ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_u16nw.c ! src/share/native/sun/awt/medialib/mlib_ImageCreate.c ! src/share/native/sun/awt/medialib/mlib_c_ImageConv.h Changeset: 1ea9feb6d8c5 Author: jgodinez Date: 2013-02-08 11:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1ea9feb6d8c5 8005261: [parfait] #415 sun/java2d/opengl/GLXSurfaceData.c Memory leak of pointer 'glxsdo' allocated with malloc Reviewed-by: prr, vadim Contributed-by: jia-hong.chen at oracle.com ! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c Changeset: 5f0217537435 Author: prr Date: 2013-02-12 09:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5f0217537435 8007748: MacOSX build error : cast of type 'SEL' to 'uintptr_t' (aka 'unsigned long') is deprecated; use sel_getName instead Reviewed-by: anthony ! src/macosx/native/jobjc/src/core/native/SEL.m Changeset: 1b47e2dfa89a Author: lana Date: 2013-02-13 13:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1b47e2dfa89a Merge - src/share/classes/java/lang/annotation/ContainedBy.java - src/share/classes/java/lang/annotation/ContainerFor.java - test/java/net/URL/abnormal_http_urls - test/java/net/URL/ftp_urls - test/java/net/URL/jar_urls - test/java/net/URL/normal_http_urls - test/java/net/URL/runconstructor.sh - test/java/net/URL/share_file_urls - test/java/net/URL/win32_file_urls - test/sun/net/www/EncDec.doc - test/sun/net/www/MarkResetTest.java - test/sun/net/www/MarkResetTest.sh - test/sun/security/util/Oid/S11N.sh - test/sun/security/util/Oid/SerialTest.java Changeset: 6df3acd02449 Author: prr Date: 2013-02-13 15:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6df3acd02449 8008017: The fix for 8005129 does not build on Windows Reviewed-by: prr, jgodinez Contributed-by: jia-hong.chen at oracle.com ! src/share/native/sun/awt/medialib/mlib_ImageConv_16ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_16nw.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_8ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_8nw.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_u16ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_u16nw.c Changeset: ac89a5d71466 Author: alexsch Date: 2013-02-06 18:25 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac89a5d71466 8000326: Focus unable to traverse in the menubar Reviewed-by: alexsch, malenkov ! src/share/classes/javax/swing/JMenuBar.java Changeset: 6e17465f4a1a Author: mcherkas Date: 2013-02-08 22:08 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6e17465f4a1a 8005932: Java 7 on mac os x only provides text clipboard formats Reviewed-by: alexp, denis ! src/macosx/lib/flavormap.properties + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/AbsoluteComponentCenterCalculator.java + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/DataFlavorSearcher.java + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/InterprocessMessages.java + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.html + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.java + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MyTransferable.java + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/NextFramePositionCalculator.java + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/SourcePanel.java + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/TargetPanel.java Changeset: 5406c4e381e2 Author: kshefov Date: 2013-02-13 18:01 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5406c4e381e2 7161759: TEST_BUG: java/awt/Frame/WindowDragTest/WindowDragTest.java fails to compile, should be modified Summary: Added @build Util jtreg tag Reviewed-by: serb, alexsch Contributed-by: Vera Akulova ! test/java/awt/Frame/WindowDragTest/WindowDragTest.java Changeset: dd6cf41a6953 Author: kshefov Date: 2013-02-13 19:06 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd6cf41a6953 7132383: [macosx] bug6596966.java should be adapted for Mac Reviewed-by: serb, alexsch Contributed-by: Vera Akulova ! test/javax/swing/JLabel/6596966/bug6596966.java ! test/javax/swing/regtesthelpers/Util.java Changeset: caec64340f42 Author: vkarnauk Date: 2013-02-13 19:23 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/caec64340f42 4199622: RFE: JComboBox shouldn't sending ActionEvents for keyboard navigation Reviewed-by: alexp, alexsch ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java ! src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java + test/javax/swing/JComboBox/4199622/bug4199622.java Changeset: 4d9691e95e05 Author: pchelko Date: 2013-02-13 15:27 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4d9691e95e05 7079260: InputContext leaks memory Summary: Replaced strong refs with weak refs Reviewed-by: art, serb ! src/share/classes/sun/awt/im/CompositionAreaHandler.java ! src/solaris/classes/sun/awt/X11InputMethod.java + test/java/awt/im/memoryleak/InputContextMemoryLeakTest.java ! test/java/awt/regtesthelpers/Util.java Changeset: c552cde0e3f9 Author: pchelko Date: 2013-02-13 15:32 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c552cde0e3f9 8005629: javac warnings compiling java.awt.EventDispatchThread and sun.awt.X11.XIconWindow Summary: Removed macosx specific workaround from shared code and made macosx use public API Reviewed-by: art, serb ! src/macosx/classes/sun/lwawt/macosx/CPrinterJob.java - src/macosx/classes/sun/lwawt/macosx/EventDispatchAccess.java ! src/macosx/native/sun/awt/CPrinterJob.m ! src/share/classes/java/awt/EventDispatchThread.java ! src/solaris/classes/sun/awt/X11/XIconWindow.java Changeset: c95dc15ac183 Author: lana Date: 2013-02-13 12:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c95dc15ac183 Merge - src/share/classes/java/lang/annotation/ContainedBy.java - src/share/classes/java/lang/annotation/ContainerFor.java - test/java/net/URL/abnormal_http_urls - test/java/net/URL/ftp_urls - test/java/net/URL/jar_urls - test/java/net/URL/normal_http_urls - test/java/net/URL/runconstructor.sh - test/java/net/URL/share_file_urls - test/java/net/URL/win32_file_urls - test/sun/net/www/EncDec.doc - test/sun/net/www/MarkResetTest.java - test/sun/net/www/MarkResetTest.sh - test/sun/security/util/Oid/S11N.sh - test/sun/security/util/Oid/SerialTest.java Changeset: c9efb349b391 Author: lana Date: 2013-02-13 17:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c9efb349b391 Merge - src/macosx/classes/sun/lwawt/macosx/EventDispatchAccess.java Changeset: dc3019a336c0 Author: lana Date: 2013-02-13 17:57 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dc3019a336c0 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: 5ea0024ba765 Author: lana Date: 2013-02-14 22:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5ea0024ba765 Merge Changeset: 85a44860f5bb Author: lana Date: 2013-02-19 20:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/85a44860f5bb Merge - src/macosx/classes/sun/lwawt/macosx/EventDispatchAccess.java From yekaterina.kantserova at oracle.com Wed Feb 20 09:26:06 2013 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 20 Feb 2013 10:26:06 +0100 Subject: RFR (XS) 8008089: Delete OS dependent check in JdkFinder.getExecutable() In-Reply-To: <5123A1EA.6010404@oracle.com> References: <511B6134.3010005@oracle.com> <5123A1EA.6010404@oracle.com> Message-ID: <512496AE.5070506@oracle.com> On 02/19/2013 05:01 PM, Alan Bateman wrote: > On 13/02/2013 09:47, Yekaterina Kantserova wrote: >> Hi everyone, >> >> This small fixconcerns jdk.testlibrary.JdkFinder utility class. The >> check below is too OS dependent and should be deleted. >> ... >> binPath += File.separatorChar + "bin" + File.separatorChar + >> executable; >> File toolFile = new File(binPath); >> ==> if (!toolFile.exists()) { >> throw new RuntimeException(binPath + " does not exist"); >> } >> ... >> >> On windows if executable is specified as e.g. 'java', without '.exe', >> the File exists() will fail. But it's still possible to run executable. Thanks for reviewing this! Yes, Staffan Larsen helped me last time, I hope he can do it again. // Katja > This looks okay to me, do you have someone to push this for you? > > -Alan. From vicente.romero at oracle.com Wed Feb 20 10:52:08 2013 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Wed, 20 Feb 2013 10:52:08 +0000 Subject: hg: jdk8/tl/langtools: 8006212: javac, convert jtreg tests from shell script to java In-Reply-To: <5123C95A.3060703@oracle.com> References: <20130219175447.0916147BA5@hg.openjdk.java.net> <5123C95A.3060703@oracle.com> Message-ID: <5124AAD8.1060307@oracle.com> On 19/02/13 18:50, Jonathan Gibbons wrote: > Woohoo -- 23 shell tests replaced with equivalent Java code: that's > over 2/3 of the shell tests in langtools/test. And lots of files removed, "less is more" :) Vicente > > -- Jon > > On 02/19/2013 09:54 AM, vicente.romero at oracle.com wrote: >> Changeset: dc8b7aa7cef3 >> Author: vromero >> Date: 2013-02-19 17:53 +0000 >> URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/dc8b7aa7cef3 >> >> 8006212: javac, convert jtreg tests from shell script to java >> Reviewed-by: jjg >> >> ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java >> ! src/share/classes/com/sun/tools/javac/util/ArrayUtils.java >> + test/tools/apt/Basics/CheckAptIsRemovedTest.java >> - test/tools/apt/Basics/NullAPF.java >> - test/tools/apt/Basics/apt.sh >> - test/tools/apt/verifyVariables.sh >> + test/tools/javac/4846262/CheckEBCDICLocaleTest.java >> - test/tools/javac/4846262/Test.java >> - test/tools/javac/4846262/Test.out >> - test/tools/javac/4846262/Test.sh >> + test/tools/javac/6302184/HiddenOptionsShouldUseGivenEncodingTest.java >> - test/tools/javac/6302184/T6302184.sh >> + test/tools/javac/ClassPathTest/ClassPathTest.java >> - 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.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/MissingInclude.java >> - test/tools/javac/MissingInclude.sh >> + test/tools/javac/MissingInclude/MissingIncludeTest.java >> - test/tools/javac/ProtectedInnerClass/ProtectedInnerClass.sh >> - test/tools/javac/ProtectedInnerClass/ProtectedInnerClass_2.java >> + test/tools/javac/ProtectedInnerClass/ProtectedInnerClassesTest.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/AssertionFailureTest.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/constDebug/ConstDebugTest.java >> - test/tools/javac/fatalErrors/NoJavaLang.java >> - test/tools/javac/fatalErrors/NoJavaLang.out >> - test/tools/javac/fatalErrors/NoJavaLang.sh >> + test/tools/javac/fatalErrors/NoJavaLangTest.java >> - test/tools/javac/innerClassFile/Driver.sh >> + test/tools/javac/innerClassFile/InnerClassFileTest.java >> - 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/JavaZipTest.java >> - test/tools/javac/javazip/Test.sh >> - test/tools/javac/javazip/bad/B.java >> - test/tools/javac/javazip/good/B.java >> + test/tools/javac/lib/ToolBox.java >> + test/tools/javac/links/LinksTest.java >> - test/tools/javac/links/T.java >> - test/tools/javac/links/b/B.java >> - test/tools/javac/links/links.sh >> + test/tools/javac/newlines/NewLineTest.java >> - test/tools/javac/newlines/Newlines.sh >> + test/tools/javac/stackmap/StackMapTest.java >> - test/tools/javac/stackmap/T4955930.java >> - test/tools/javac/stackmap/T4955930.sh >> ! test/tools/javac/unicode/SupplementaryJavaID6.java >> - test/tools/javac/unicode/SupplementaryJavaID6.sh >> + test/tools/javah/6257087/T6257087.java >> - 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/javah/T4942232/MissingParamClassTest.java >> + test/tools/javah/constMacroTest/ConstMacroTest.java >> + test/tools/javap/4798312/JavapShouldLoadClassesFromRTJarTest.java >> + test/tools/javap/4866831/PublicInterfaceTest.java >> - test/tools/javap/NotPackagePrivateInterface.java >> - test/tools/javap/PublicInterfaceTest.sh >> - test/tools/javap/pathsep.sh >> + test/tools/javap/stackmap/StackmapTest.java >> - test/tools/javap/stackmap/T6271292.java >> - test/tools/javap/stackmap/T6271292.out >> - test/tools/javap/stackmap/T6271292.sh >> > From chris.hegarty at oracle.com Wed Feb 20 11:16:22 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 20 Feb 2013 11:16:22 +0000 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: References: <50EF4143.4090008@oracle.com> <50F408CF.6060207@oracle.com> <50F40D95.9050402@oracle.com> <50F44C72.60707@oracle.com> <50F483E7.6080504@oracle.com> <50F487CE.6010101@oracle.com> <50F48C5A.4040500@oracle.com> <8E0C1F8A-DF46-457C-81DB-0BC41FC5F2D5@oracle.com> <50F49B06.9070202@cs.oswego.edu> <50F50E1E.5040604@javaspecialists.eu> <50F558D7.5040509@cs.oswego.edu> <50F55B8F.40502@oracle.com> <50F55E7C.8040809@oracle.com> <50F56062.5070404@oracle.com> <50F584DD.6080108@oracle.com> <50F66BE4.3050305@gmail.com> <50F693A2.8030000@cs.oswego.edu> <50F6C0E4.2090401@oracle.com> Message-ID: <5124B086.60006@oracle.com> Martin, Alan, OK, I finally got back to this. I agree that Martins changes should be fine for jdk8, but removing all these fields may cause an issue with jdk7. Removing pads, fine. The rnd and initialized fields are still applicable in jdk7 ( or 7 will need changes to remove their dependency ). For example, a serialized TLR from jdk8 with Martins changes, deserialized with jdk7 would contain no field values, therefore the defaults would apply. Calling setSeed on this object would not throw the expected UOE. I think minimally TLR in jdk8 needs to keep initialized, and possibly write some reasonable value for rnd. -Chris. On 19/02/2013 17:48, Martin Buchholz wrote: > > > On Wed, Jan 16, 2013 at 7:01 AM, Chris Hegarty > wrote: > > Thanks to all for the reviews and suggestions here. As you probably > seen, I pushed these changes to jdk8/tl earlier today (sorry, I > missed Alan as an official reviewer on the changeset.). Consider it > an initial version, pending any outcome from this, or other, > discussions. > > Also, 8006409: "ThreadLocalRandom should dropping padding fields > from its serialized form", has been filed to follow up on the > changes required to update the serial form. > > For those watching, I was preferable to push on with these changes ( > and I apologize if it appeared pushy ), as the Double/Long > Adder/Accumulator implementation, Striped64, now has a dependency on > this change. It has become unbearable to keep in sync with different > version of across different repositories. > > > Taking a look at this, I don't see any reason why we can't simply do > (while maintaining serialization compatibility): > > diff --git > a/src/share/classes/java/util/concurrent/ThreadLocalRandom.java > b/src/share/classes/java/util/concurrent/ThreadLocalRandom.java > --- a/src/share/classes/java/util/concurrent/ThreadLocalRandom.java > +++ b/src/share/classes/java/util/concurrent/ThreadLocalRandom.java > @@ -368,50 +368,6 @@ > private static final long serialVersionUID = -5851777807851030925L; > /** > - * @serialField rnd long > - * @serialField initialized boolean > - * @serialField pad0 long > - * @serialField pad1 long > - * @serialField pad2 long > - * @serialField pad3 long > - * @serialField pad4 long > - * @serialField pad5 long > - * @serialField pad6 long > - * @serialField pad7 long > - */ > - private static final ObjectStreamField[] serialPersistentFields = { > - new ObjectStreamField("rnd", long.class), > - new ObjectStreamField("initialized", boolean.class), > - new ObjectStreamField("pad0", long.class), > - new ObjectStreamField("pad1", long.class), > - new ObjectStreamField("pad2", long.class), > - new ObjectStreamField("pad3", long.class), > - new ObjectStreamField("pad4", long.class), > - new ObjectStreamField("pad5", long.class), > - new ObjectStreamField("pad6", long.class), > - new ObjectStreamField("pad7", long.class) }; > - > - /** > - * Saves the {@code ThreadLocalRandom} to a stream (that is, > serializes it). > - */ > - private void writeObject(java.io.ObjectOutputStream out) > - throws java.io.IOException { > - > - java.io.ObjectOutputStream.PutField fields = out.putFields(); > - fields.put("rnd", 0L); > - fields.put("initialized", true); > - fields.put("pad0", 0L); > - fields.put("pad1", 0L); > - fields.put("pad2", 0L); > - fields.put("pad3", 0L); > - fields.put("pad4", 0L); > - fields.put("pad5", 0L); > - fields.put("pad6", 0L); > - fields.put("pad7", 0L); > - out.writeFields(); > - } > - > - /** > * Returns the {@link #current() current} thread's {@code > ThreadLocalRandom}. > */ > private Object readResolve() { > From staffan.larsen at oracle.com Wed Feb 20 11:40:31 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Wed, 20 Feb 2013 11:40:31 +0000 Subject: hg: jdk8/tl/jdk: 8008089: Delete OS dependent check in JdkFinder.getExecutable() Message-ID: <20130220114053.28EE647BEE@hg.openjdk.java.net> Changeset: ca43e2761a1d Author: ykantser Date: 2013-02-13 10:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ca43e2761a1d 8008089: Delete OS dependent check in JdkFinder.getExecutable() Reviewed-by: egahlin, alanb ! test/lib/testlibrary/jdk/testlibrary/JdkFinder.java From martinrb at google.com Wed Feb 20 12:16:21 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 20 Feb 2013 04:16:21 -0800 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <5124B086.60006@oracle.com> References: <50EF4143.4090008@oracle.com> <50F408CF.6060207@oracle.com> <50F40D95.9050402@oracle.com> <50F44C72.60707@oracle.com> <50F483E7.6080504@oracle.com> <50F487CE.6010101@oracle.com> <50F48C5A.4040500@oracle.com> <8E0C1F8A-DF46-457C-81DB-0BC41FC5F2D5@oracle.com> <50F49B06.9070202@cs.oswego.edu> <50F50E1E.5040604@javaspecialists.eu> <50F558D7.5040509@cs.oswego.edu> <50F55B8F.40502@oracle.com> <50F55E7C.8040809@oracle.com> <50F56062.5070404@oracle.com> <50F584DD.6080108@oracle.com> <50F66BE4.3050305@gmail.com> <50F693A2.8030000@cs.oswego.edu> <50F6C0E4.2090401@oracle.com> <5124B086.60006@oracle.com> Message-ID: On Wed, Feb 20, 2013 at 3:16 AM, Chris Hegarty wrote: > Martin, Alan, > > OK, I finally got back to this. > > I agree that Martins changes should be fine for jdk8, but removing all > these fields may cause an issue with jdk7. Removing pads, fine. The rnd and > initialized fields are still applicable in jdk7 ( or 7 will need changes to > remove their dependency ). > > For example, a serialized TLR from jdk8 with Martins changes, deserialized > with jdk7 would contain no field values, therefore the defaults would > apply. Calling setSeed on this object would not throw the expected UOE. > My expectation was that with my changes, the default serialization would apply, and the serialized form would contain initiatialized=1. rnd would not be in the serialized form, but would deserialize to 0, which is the same as currently done. Completely untested. BTW, we still don't have a good story on cross-JDK serialization testing. > > I think minimally TLR in jdk8 needs to keep initialized, and possibly > write some reasonable value for rnd. Whether rnd needs a reasonable value is a reasonable question. From alexey.utkin at oracle.com Wed Feb 20 12:38:08 2013 From: alexey.utkin at oracle.com (alexey.utkin at oracle.com) Date: Wed, 20 Feb 2013 12:38:08 +0000 Subject: hg: jdk8/tl/jdk: 8007454: (process) SetHandleInformation parameters DWORD (not BOOLEAN) Message-ID: <20130220123839.4C46047BF5@hg.openjdk.java.net> Changeset: 0a2b308cc82d Author: uta Date: 2013-02-20 16:39 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a2b308cc82d 8007454: (process) SetHandleInformation parameters DWORD (not BOOLEAN) Summary: the SetHandleInformation arguments list was fixed. Reviewed-by: alanb ! src/windows/native/java/lang/ProcessImpl_md.c From chris.hegarty at oracle.com Wed Feb 20 14:13:34 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 20 Feb 2013 14:13:34 +0000 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: References: <50EF4143.4090008@oracle.com> <50F408CF.6060207@oracle.com> <50F40D95.9050402@oracle.com> <50F44C72.60707@oracle.com> <50F483E7.6080504@oracle.com> <50F487CE.6010101@oracle.com> <50F48C5A.4040500@oracle.com> <8E0C1F8A-DF46-457C-81DB-0BC41FC5F2D5@oracle.com> <50F49B06.9070202@cs.oswego.edu> <50F50E1E.5040604@javaspecialists.eu> <50F558D7.5040509@cs.oswego.edu> <50F55B8F.40502@oracle.com> <50F55E7C.8040809@oracle.com> <50F56062.5070404@oracle.com> <50F584DD.6080108@oracle.com> <50F66BE4.3050305@gmail.com> <50F693A2.8030000@cs.oswego.edu> <50F6C0E4.2090401@oracle.com> <5124B086.60006@oracle.com> Message-ID: <5124DA0E.60507@oracle.com> On 20/02/2013 12:16, Martin Buchholz wrote: > > > On Wed, Feb 20, 2013 at 3:16 AM, Chris Hegarty > wrote: > > Martin, Alan, > > OK, I finally got back to this. > > I agree that Martins changes should be fine for jdk8, but removing > all these fields may cause an issue with jdk7. Removing pads, fine. > The rnd and initialized fields are still applicable in jdk7 ( or 7 > will need changes to remove their dependency ). > > For example, a serialized TLR from jdk8 with Martins changes, > deserialized with jdk7 would contain no field values, therefore the > defaults would apply. Calling setSeed on this object would not throw > the expected UOE. > > > My expectation was that with my changes, the default serialization would > apply, and the serialized form would contain initiatialized=1. rnd > would not be in the serialized form, but would deserialize to 0, which > is the same as currently done. Yes, you are right. For some reason I was thinking that 'initialized' field was also removed from this version. So this is fine. > Completely untested. > > BTW, we still don't have a good story on cross-JDK serialization testing. > > > I think minimally TLR in jdk8 needs to keep initialized, and > possibly write some reasonable value for rnd. > > > Whether rnd needs a reasonable value is a reasonable question. Unfortunately, if we agree that rnd needs a reasonable value then we are stuck with serialPersistentFields, etc ( less the padding ). How about (and additionally remove the pads): --- a/src/share/classes/java/util/concurrent/ThreadLocalRandom.java Tue Feb 19 20:52:39 2013 -0800 +++ b/src/share/classes/java/util/concurrent/ThreadLocalRandom.java Wed Feb 20 14:08:28 2013 +0000 @@ -398,7 +398,7 @@ public class ThreadLocalRandom extends R throws java.io.IOException { java.io.ObjectOutputStream.PutField fields = out.putFields(); - fields.put("rnd", 0L); + fields.put("rnd", UNSAFE.getLong(Thread.currentThread(), SEED)); fields.put("initialized", true); fields.put("pad0", 0L); fields.put("pad1", 0L); -Chris. From daniel.daugherty at oracle.com Wed Feb 20 21:24:47 2013 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Wed, 20 Feb 2013 21:24:47 +0000 Subject: hg: jdk8/tl/jdk: 8008352: java/lang/instrument/RedefineSubclassWithTwoInterfaces.sh fails on MKS Message-ID: <20130220212510.9704C47C19@hg.openjdk.java.net> Changeset: 5772e9edbc4c Author: dcubed Date: 2013-02-20 13:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5772e9edbc4c 8008352: java/lang/instrument/RedefineSubclassWithTwoInterfaces.sh fails on MKS Summary: Use more portable pattern counting constructs in test driver. Reviewed-by: sspitsyn, sla, coleenp ! test/java/lang/instrument/RedefineSubclassWithTwoInterfaces.sh From jonathan.gibbons at oracle.com Wed Feb 20 23:47:33 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 20 Feb 2013 23:47:33 +0000 Subject: hg: jdk8/tl/langtools: 8006582: Test for parameter names feature Message-ID: <20130220234736.9287C47C1F@hg.openjdk.java.net> Changeset: 267225edc1fe Author: strarup Date: 2013-02-20 15:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/267225edc1fe 8006582: Test for parameter names feature Reviewed-by: jjg, darcy, emc - test/tools/javac/MethodParameters.java + test/tools/javac/MethodParameters/AnnotationTest.java + test/tools/javac/MethodParameters/AnonymousClass.java + test/tools/javac/MethodParameters/AttributeVisitor.java + test/tools/javac/MethodParameters/ClassFileVisitor.java + test/tools/javac/MethodParameters/Constructors.java + test/tools/javac/MethodParameters/EnumTest.java + test/tools/javac/MethodParameters/InstanceMethods.java + test/tools/javac/MethodParameters/LambdaTest.java + test/tools/javac/MethodParameters/LocalClassTest.java + test/tools/javac/MethodParameters/MemberClassTest.java + test/tools/javac/MethodParameters/ReflectionVisitor.java + test/tools/javac/MethodParameters/StaticMethods.java + test/tools/javac/MethodParameters/Tester.java + test/tools/javac/MethodParameters/UncommonParamNames.java + test/tools/javac/MethodParametersTest.java From mike.duigou at oracle.com Thu Feb 21 01:56:54 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 21 Feb 2013 01:56:54 +0000 Subject: hg: jdk8/tl: 8008629: webrev.ksh needs to quote bug title it gets back from scraping bugs.sun.com Message-ID: <20130221015654.9AA3A47C26@hg.openjdk.java.net> Changeset: c641268c4532 Author: mduigou Date: 2013-02-20 17:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c641268c4532 8008629: webrev.ksh needs to quote bug title it gets back from scraping bugs.sun.com Reviewed-by: darcy ! make/scripts/webrev.ksh From Alan.Bateman at oracle.com Thu Feb 21 14:33:09 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Feb 2013 14:33:09 +0000 Subject: 8008290: (profiles) Startup regression due to additional checking of JAR file manifests Message-ID: <51263025.70509@oracle.com> This one is a startup-time regression caused by the compact profiles work. As background, there was a lot of work done in the distant past on startup performance. Amongst the startup improvements was to the code that checks for the Class-Path attribute when opening JAR files so that it skips checking of known JAR files (in the JDK) and in addition do a quick search of the manifest to avoid parsing it when not present. These optimizations were disrupted by the profiles work so the change here is to fix this regression to get startup performance back to where it was previously. The changes are very simple, it just extends the implementation to check for the Profile attribute in the same way that we've always checked the Class-Path attribute. I've also refreshed the list of "known" JAR files as that has been stale for some time. The changes do mean the manifest bytes are searched twice and it might benefit from using a multi-pattern search and that it something for another day. So far, at least in the startup tests that I've run, it doesn't make any observable difference and startup performance is back to where it was. The webrev with the changes is here. I should point out that this is against jdk8/build as the changes aren't in jdk8/tl at this time. http://cr.openjdk.java.net/~alanb/8008290/webrev/ Finally, I should explain that the goal here is simply to get startup back to where it was. There is clearly other clean-up that should be done on this code at some point. Thanks, Alan. From maurizio.cimadamore at oracle.com Thu Feb 21 16:00:57 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 21 Feb 2013 16:00:57 +0000 Subject: hg: jdk8/tl/langtools: 6 new changesets Message-ID: <20130221160118.3B1AE47C3C@hg.openjdk.java.net> Changeset: d686d8a7eb78 Author: mcimadamore Date: 2013-02-21 15:19 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d686d8a7eb78 8008227: Mixing lambdas with anonymous classes leads to NPE thrown by compiler Summary: Disentangle cyclic dependency between static-ness of synthetic lambda method and static-ness of classes nested within lambdas Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/LambdaConv27.java Changeset: 3a39d123d33a Author: mcimadamore Date: 2013-02-21 15:21 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3a39d123d33a 8008276: assertion error in com.sun.tools.javac.comp.TransTypes.visitApply Summary: DiagnosticFilter used during speculative attribution is too broad Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java + test/tools/javac/lambda/speculative/MissingError.java + test/tools/javac/lambda/speculative/MissingError.out Changeset: f4fdd53f8b3e Author: mcimadamore Date: 2013-02-21 15:23 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f4fdd53f8b3e 8005183: Missing accessor for constructor reference pointing to private inner class ctor Summary: Compiler should add bridges when translating private constructor reference Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/MethodReference63.java Changeset: 7ac9242d2ca6 Author: mcimadamore Date: 2013-02-21 15:25 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7ac9242d2ca6 8008293: Declared bounds not considered when functional interface containing unbound wildcards is instantiated Summary: Wildcards inference should re-use some of the bounds info generated during capture conversion Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/lambda/TargetType64.java Changeset: 9f0ec00514b6 Author: mcimadamore Date: 2013-02-21 15:26 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9f0ec00514b6 8007461: Regression: bad overload resolution when inner class and outer class have method with same name Summary: Fix regression in varargs method resolution introduced by bad refactoring Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/resolve/Pos.java + test/tools/javac/resolve/tests/InnerOverOuter.java Changeset: 3fef0cae83b3 Author: mcimadamore Date: 2013-02-21 15:27 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3fef0cae83b3 8008444: Inherited generic functional descriptors are merged incorrectly Summary: Missing call to Types.createMethodWithThrownTypes Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/lambda/LambdaConv25.java + test/tools/javac/lambda/LambdaConv25.out From Lance.Andersen at oracle.com Thu Feb 21 16:11:17 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 21 Feb 2013 11:11:17 -0500 Subject: 8008290: (profiles) Startup regression due to additional checking of JAR file manifests In-Reply-To: <51263025.70509@oracle.com> References: <51263025.70509@oracle.com> Message-ID: <5E58E4C5-C02D-4DD5-AB91-5F7C7CB4B2CC@oracle.com> Alan, the changes look good and glad you added the extra comments for clarity. Best Lance On Feb 21, 2013, at 9:33 AM, Alan Bateman wrote: > > This one is a startup-time regression caused by the compact profiles work. > > As background, there was a lot of work done in the distant past on startup performance. Amongst the startup improvements was to the code that checks for the Class-Path attribute when opening JAR files so that it skips checking of known JAR files (in the JDK) and in addition do a quick search of the manifest to avoid parsing it when not present. These optimizations were disrupted by the profiles work so the change here is to fix this regression to get startup performance back to where it was previously. > > The changes are very simple, it just extends the implementation to check for the Profile attribute in the same way that we've always checked the Class-Path attribute. I've also refreshed the list of "known" JAR files as that has been stale for some time. The changes do mean the manifest bytes are searched twice and it might benefit from using a multi-pattern search and that it something for another day. So far, at least in the startup tests that I've run, it doesn't make any observable difference and startup performance is back to where it was. > > The webrev with the changes is here. I should point out that this is against jdk8/build as the changes aren't in jdk8/tl at this time. > > http://cr.openjdk.java.net/~alanb/8008290/webrev/ > > Finally, I should explain that the goal here is simply to get startup back to where it was. There is clearly other clean-up that should be done on this code at some point. > > Thanks, > Alan. -------------- 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 chris.hegarty at oracle.com Thu Feb 21 16:33:17 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 21 Feb 2013 16:33:17 +0000 Subject: 8008290: (profiles) Startup regression due to additional checking of JAR file manifests In-Reply-To: <5E58E4C5-C02D-4DD5-AB91-5F7C7CB4B2CC@oracle.com> References: <51263025.70509@oracle.com> <5E58E4C5-C02D-4DD5-AB91-5F7C7CB4B2CC@oracle.com> Message-ID: <51264C4D.1030008@oracle.com> On 21/02/2013 16:11, Lance Andersen - Oracle wrote: > Alan, > > the changes look good and glad you added the extra comments for clarity. +1 Trivially, I think you can remove the comment: * ## Add a fast path like Class-Path to avoid reading the manifest when the attribute * is not present. -Chris. > > Best > Lance > On Feb 21, 2013, at 9:33 AM, Alan Bateman wrote: > >> >> This one is a startup-time regression caused by the compact profiles work. >> >> As background, there was a lot of work done in the distant past on startup performance. Amongst the startup improvements was to the code that checks for the Class-Path attribute when opening JAR files so that it skips checking of known JAR files (in the JDK) and in addition do a quick search of the manifest to avoid parsing it when not present. These optimizations were disrupted by the profiles work so the change here is to fix this regression to get startup performance back to where it was previously. >> >> The changes are very simple, it just extends the implementation to check for the Profile attribute in the same way that we've always checked the Class-Path attribute. I've also refreshed the list of "known" JAR files as that has been stale for some time. The changes do mean the manifest bytes are searched twice and it might benefit from using a multi-pattern search and that it something for another day. So far, at least in the startup tests that I've run, it doesn't make any observable difference and startup performance is back to where it was. >> >> The webrev with the changes is here. I should point out that this is against jdk8/build as the changes aren't in jdk8/tl at this time. >> >> http://cr.openjdk.java.net/~alanb/8008290/webrev/ >> >> Finally, I should explain that the goal here is simply to get startup back to where it was. There is clearly other clean-up that should be done on this code at some point. >> >> Thanks, >> Alan. > > > > > 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 iris.clark at oracle.com Thu Feb 21 16:42:08 2013 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 21 Feb 2013 08:42:08 -0800 (PST) Subject: 8008290: (profiles) Startup regression due to additional checking of JAR file manifests In-Reply-To: <51263025.70509@oracle.com> References: <51263025.70509@oracle.com> Message-ID: <3a9484b0-0719-4c36-a4f6-c7d192060ed1@default> Hi, Alan. Very nice. Just curious. How are you testing startup? Custom micro benchmark or are you using something else? iris -----Original Message----- From: Alan Bateman Sent: Thursday, February 21, 2013 6:33 AM To: core-libs-dev Subject: 8008290: (profiles) Startup regression due to additional checking of JAR file manifests This one is a startup-time regression caused by the compact profiles work. As background, there was a lot of work done in the distant past on startup performance. Amongst the startup improvements was to the code that checks for the Class-Path attribute when opening JAR files so that it skips checking of known JAR files (in the JDK) and in addition do a quick search of the manifest to avoid parsing it when not present. These optimizations were disrupted by the profiles work so the change here is to fix this regression to get startup performance back to where it was previously. The changes are very simple, it just extends the implementation to check for the Profile attribute in the same way that we've always checked the Class-Path attribute. I've also refreshed the list of "known" JAR files as that has been stale for some time. The changes do mean the manifest bytes are searched twice and it might benefit from using a multi-pattern search and that it something for another day. So far, at least in the startup tests that I've run, it doesn't make any observable difference and startup performance is back to where it was. The webrev with the changes is here. I should point out that this is against jdk8/build as the changes aren't in jdk8/tl at this time. http://cr.openjdk.java.net/~alanb/8008290/webrev/ Finally, I should explain that the goal here is simply to get startup back to where it was. There is clearly other clean-up that should be done on this code at some point. Thanks, Alan. From Alan.Bateman at oracle.com Thu Feb 21 18:02:20 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Feb 2013 18:02:20 +0000 Subject: 8008290: (profiles) Startup regression due to additional checking of JAR file manifests In-Reply-To: <3a9484b0-0719-4c36-a4f6-c7d192060ed1@default> References: <51263025.70509@oracle.com> <3a9484b0-0719-4c36-a4f6-c7d192060ed1@default> Message-ID: <5126612C.2070403@oracle.com> On 21/02/2013 16:42, Iris Clark wrote: > Hi, Alan. > > Very nice. > > Just curious. How are you testing startup? Custom micro benchmark or are you using something else? A calendar :-) I'm using a performance test suite from the Oracle performance team. It's called refworkload and includes startup and footprint tests. Sorry, it's not in OpenJDK, we don't have anything in OpenJDK. -Alan From Alan.Bateman at oracle.com Thu Feb 21 18:46:20 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Feb 2013 18:46:20 +0000 Subject: 8008662: Add @jdk.Supported to JDK-specific/supported API Message-ID: <51266B7C.3040804@oracle.com> Joe Darcy recently added @jdk.Supported [1] to make it possible to identify JDK-specific APIs. I'd like to add this to a number of APIs in the com.sun namespace to make it obvious these are "supported". Specifically I'm proposing to add it to: - Java Debug Interface (com.sun.jdi) - Attach API (com.sun.tools.attach) - SCTP API (com.sun.nio.sctp) - HTTP server API (com.sun.net.httpserver) - Management extensions (com.sun.management) - JDK-specific API to JAAS (com.sun.security.auth) - JDK-specific JGSS API (com.sun.security.jgss) The javadoc for all of these is generated as part of the regular JDK "docs" build and so shouldn't be controversial. There are a number of other candidates in com.sun with murkier status that I've stayed clear of for now. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/8008662/webrev/ In a couple of cases the package description is legacy package.html so I've had to move/convert them to package-info.java. In all but one case I've added the annotation to the package-info, the one exception is com.sun.management where there is at least one type that is documented as "not supported". Joe Darcy might have suggestions on that. Otherwise this is mostly mechanical and the patch file is easier to review that the webrev. -Alan [1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/55cca2f38ee6 From brian.goetz at oracle.com Thu Feb 21 19:16:35 2013 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 21 Feb 2013 14:16:35 -0500 Subject: Code review request: JDK-8008670 (partial java.util.stream implementation) Message-ID: <51267293.4060203@oracle.com> 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 Lance.Andersen at oracle.com Thu Feb 21 19:35:26 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 21 Feb 2013 14:35:26 -0500 Subject: 8008662: Add @jdk.Supported to JDK-specific/supported API In-Reply-To: <51266B7C.3040804@oracle.com> References: <51266B7C.3040804@oracle.com> Message-ID: Well, that was quite a few files to have to go through :-) Looks fine On Feb 21, 2013, at 1:46 PM, Alan Bateman wrote: > > Joe Darcy recently added @jdk.Supported [1] to make it possible to identify JDK-specific APIs. > > I'd like to add this to a number of APIs in the com.sun namespace to make it obvious these are "supported". Specifically I'm proposing to add it to: > > - Java Debug Interface (com.sun.jdi) > - Attach API (com.sun.tools.attach) > - SCTP API (com.sun.nio.sctp) > - HTTP server API (com.sun.net.httpserver) > - Management extensions (com.sun.management) > - JDK-specific API to JAAS (com.sun.security.auth) > - JDK-specific JGSS API (com.sun.security.jgss) > > The javadoc for all of these is generated as part of the regular JDK "docs" build and so shouldn't be controversial. There are a number of other candidates in com.sun with murkier status that I've stayed clear of for now. > > The webrev with the changes is here: > > http://cr.openjdk.java.net/~alanb/8008662/webrev/ > > In a couple of cases the package description is legacy package.html so I've had to move/convert them to package-info.java. > > In all but one case I've added the annotation to the package-info, the one exception is com.sun.management where there is at least one type that is documented as "not supported". Joe Darcy might have suggestions on that. > > Otherwise this is mostly mechanical and the patch file is easier to review that the webrev. > > -Alan > > [1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/55cca2f38ee6 -------------- 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 mandy.chung at oracle.com Thu Feb 21 19:45:04 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 21 Feb 2013 11:45:04 -0800 Subject: 8008290: (profiles) Startup regression due to additional checking of JAR file manifests In-Reply-To: <51263025.70509@oracle.com> References: <51263025.70509@oracle.com> Message-ID: <51267940.2000002@oracle.com> Alan, This fix looks good and the "## fast path ..." comment can be taken out as Chris pointed out. A minor note - the list of known jar files seems to be incomplete (e.g. tzdb.jar and some windows-specific ones). I think it may be better to file a bug to follow up this and maybe even better to replace the hardcoded list with other mechanism (if appropriate). Mandy On 2/21/2013 6:33 AM, Alan Bateman wrote: > > This one is a startup-time regression caused by the compact profiles > work. > > As background, there was a lot of work done in the distant past on > startup performance. Amongst the startup improvements was to the code > that checks for the Class-Path attribute when opening JAR files so > that it skips checking of known JAR files (in the JDK) and in addition > do a quick search of the manifest to avoid parsing it when not > present. These optimizations were disrupted by the profiles work so > the change here is to fix this regression to get startup performance > back to where it was previously. > > The changes are very simple, it just extends the implementation to > check for the Profile attribute in the same way that we've always > checked the Class-Path attribute. I've also refreshed the list of > "known" JAR files as that has been stale for some time. The changes do > mean the manifest bytes are searched twice and it might benefit from > using a multi-pattern search and that it something for another day. So > far, at least in the startup tests that I've run, it doesn't make any > observable difference and startup performance is back to where it was. > > The webrev with the changes is here. I should point out that this is > against jdk8/build as the changes aren't in jdk8/tl at this time. > > http://cr.openjdk.java.net/~alanb/8008290/webrev/ > > Finally, I should explain that the goal here is simply to get startup > back to where it was. There is clearly other clean-up that should be > done on this code at some point. > > Thanks, > Alan. From Alan.Bateman at oracle.com Thu Feb 21 20:01:04 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Feb 2013 20:01:04 +0000 Subject: 8008290: (profiles) Startup regression due to additional checking of JAR file manifests In-Reply-To: <51267940.2000002@oracle.com> References: <51263025.70509@oracle.com> <51267940.2000002@oracle.com> Message-ID: <51267D00.2090406@oracle.com> On 21/02/2013 19:45, Mandy Chung wrote: > Alan, > > This fix looks good and the "## fast path ..." comment can be taken > out as Chris pointed out. Yes, I put that comment in there as a reminder and should have removed it - thanks (and Chris). > > A minor note - the list of known jar files seems to be incomplete > (e.g. tzdb.jar and some windows-specific ones). I think it may be > better to file a bug to follow up this and maybe even better to > replace the hardcoded list with other mechanism (if appropriate). The list doesn't have to be complete, this is just the JAR files that will be skipped. I completed list that hardcoded list needs clean-up (even the construction of) and that's the clean-up I hinted at in the first mail. I decided not to change in this round as I just wanted to restore the startup. Also it takes time to verify startup across a number of platforms so changing code in this area takes a bit longer to verify. -Alan From mandy.chung at oracle.com Thu Feb 21 20:19:21 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 21 Feb 2013 12:19:21 -0800 Subject: 8008290: (profiles) Startup regression due to additional checking of JAR file manifests In-Reply-To: <51267D00.2090406@oracle.com> References: <51263025.70509@oracle.com> <51267940.2000002@oracle.com> <51267D00.2090406@oracle.com> Message-ID: <51268149.70300@oracle.com> On 2/21/2013 12:01 PM, Alan Bateman wrote: > >> >> A minor note - the list of known jar files seems to be incomplete >> (e.g. tzdb.jar and some windows-specific ones). I think it may be >> better to file a bug to follow up this and maybe even better to >> replace the hardcoded list with other mechanism (if appropriate). > The list doesn't have to be complete, this is just the JAR files that > will be skipped. I completed list that hardcoded list needs clean-up > (even the construction of) and that's the clean-up I hinted at in the > first mail. I decided not to change in this round as I just wanted to > restore the startup. Also it takes time to verify startup across a > number of platforms so changing code in this area takes a bit longer > to verify. > Right - this list doesn't have to be complete. I agree that it's better not to do the cleanup in your fix. I think very few people is aware of this hardcoded list and such startup improvement and it may worth filing a bug so that this is tracked and referenced if there is any startup regression related to this (that's what I meant with "follow up" - sorry I confused you). Mandy From brian.burkhalter at oracle.com Thu Feb 21 21:27:47 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 21 Feb 2013 13:27:47 -0800 Subject: [PATCH] Sunbug 7131192: Optimize BigInteger.doubleValue(), floatValue() In-Reply-To: References: <511ED22B.8030800@oracle.com> Message-ID: <2867C9E8-F8FB-405A-8D00-7D4F90CA9628@oracle.com> My initial testing with another micro-benchmarking framework (other than Caliper) shows a performance increase of >900X for doubleValue() and >1500X for floatValue() on a MacBookPro5,3. There is some more evaluation yet to be done but we should be able to move this patch along pretty soon. Brian On Feb 15, 2013, at 4:41 PM, Brian Burkhalter wrote: > Hi Louis, > > After the two issues for which I've posted review requests (6480539 - stripTrailingZeros(), 4396272 - Parsing doubles fails to follow IEEE) are resolved, issue 7131192 is currently very near the head of my queue. Given that I still have a ways to go to get up to speed on this entire topic area and code base, I would hesitate to give a date estimate just yet. > > Brian > >> Any update on when this could get reviewed? >> >> >> On Thu, Dec 13, 2012 at 3:36 PM, Louis Wasserman wrote: >> Hi, >> >> I'm working at Google now, but I'd like to revive this patch as a contribution from Google. At the moment, what's mainly needed is review for http://bugs.sun.com/view_bug.do?bug_id=7192954, the fix to Float.parseFloat's rounding behavior, before we can go anywhere with the patch to optimize BigInteger.floatValue() and doubleValue(). >> Would anyone be able to review that patch so these can start moving forward? >> >> Thanks, >> Louis Wasserman >> Java Core Libraries Team @ Google >> guava-libraries.googlecode.com From bob.vandette at oracle.com Thu Feb 21 22:23:45 2013 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 21 Feb 2013 17:23:45 -0500 Subject: RFR: 8005545: Add System property to identify ARCH specific details such as ARM hard-float binaries In-Reply-To: <899E92AE-F8A0-4873-B8DC-EE642B615840@oracle.com> References: <899E92AE-F8A0-4873-B8DC-EE642B615840@oracle.com> Message-ID: <154E2162-BC8B-417B-871F-8D39C409FD7F@oracle.com> Looks good to me other than the variable name. I'd prefer JDK_ARCH_ABI_NAME or JDK_ARCH_ABI_PROP_NAME over ARCHABIPROPNAME. Bob. On Feb 21, 2013, at 5:02 PM, Vladimir Danushevsky wrote: > Please review changes for https://jbs.oracle.com/bugs/browse/JDK-8005545 "Add System property to identify ARCH specific details such as ARM hard-float binaries" which adds an optional sun.os.abi Java system property indicating an ABI type being used by the JVM: > > CCC Reguest: http://ccc.us.oracle.com/8005545 > > Webrev: > http://cr.openjdk.java.net/~vladidan/8005545/webrev.00/ > > Separate change to the build script (e.g. in ARM Hard-Float ABI case): > setenv ARCHABIPROPNAME gnueabihf > -DARCHABIPROPNAME="\"$(ARCHABIPROPNAME)\"" is passed to the CFLAGS > > Thanks, > Vlad From brian.burkhalter at oracle.com Thu Feb 21 22:32:20 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 21 Feb 2013 14:32:20 -0800 Subject: Withdraw: Review: 4396272 - Parsing doubles fails to follow IEEE for largest decimal that should yield 0 In-Reply-To: <4412AB7C-A91F-48A9-ACF2-3816480C28E1@oracle.com> References: <4412AB7C-A91F-48A9-ACF2-3816480C28E1@oracle.com> Message-ID: I am withdrawing this patch for the time being as properly the changes should also go into the fork sun.misc.FormattedFloatingDecimal. I'll post an updated patch once it is available. Thanks, Brian On Feb 14, 2013, at 5:23 PM, Brian Burkhalter wrote: > The patch below is as submitted to OpenJDK bugzilla but with enhanced comments. It pertains to the correction loop in the doubleValue() method of FloatingDecimal. The situation appears to arise when the candidate value is less than 2*Double.MIN_NORMAL as for such values the ULP is less than 2*Double.MIN_VALUE so that the intermediate result 0.5*ULP is less than Double.MIN_VALUE which rounds to zero per FP-strict and the correction is therefore zero. Thus the candidate value is unchanged. The fix is to add the ULP to twice the candidate value, obtain the intermediate result, and then halve it to obtain the adjusted candidate. > > I am relatively new to IEEE-754 and this area of the code so any comments would be appreciated. > > Thanks, > > Brian > > diff -r 1405ad6afb1e -r 36482ed9bb7e src/share/classes/sun/misc/FloatingDecimal.java > --- a/src/share/classes/sun/misc/FloatingDecimal.java Thu Feb 14 11:09:07 2013 -0800 > +++ b/src/share/classes/sun/misc/FloatingDecimal.java Thu Feb 14 16:47:53 2013 -0800 From robert.field at oracle.com Thu Feb 21 22:44:31 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Thu, 21 Feb 2013 22:44:31 +0000 Subject: hg: jdk8/tl/langtools: 8008405: Now that metafactory is in place, add javac lambda serialization tests Message-ID: <20130221224433.DC7AA47C57@hg.openjdk.java.net> Changeset: cd7340a84bb8 Author: rfield Date: 2013-02-21 14:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cd7340a84bb8 8008405: Now that metafactory is in place, add javac lambda serialization tests Summary: Tests part of original langtools serialization review. Reviewed-by: mcimadamore + test/tools/javac/T8004969.java + test/tools/javac/lambda/LambdaInnerTypeVarArgsSerialize.java + test/tools/javac/lambda/LambdaInnerTypeVarSerialize.java From kumar.x.srinivasan at oracle.com Thu Feb 21 23:25:21 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Thu, 21 Feb 2013 23:25:21 +0000 Subject: hg: jdk8/tl/langtools: 8008658: Four new method param jtreg tests fail in nightly tests Message-ID: <20130221232524.9E1E747C5B@hg.openjdk.java.net> Changeset: dabb36173c63 Author: ksrini Date: 2013-02-21 12:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/dabb36173c63 8008658: Four new method param jtreg tests fail in nightly tests Reviewed-by: jjg, ksrini, mcimadamore Contributed-by: eric.mccorkle at oracle.com ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! test/tools/javac/MethodParameters/EnumTest.java ! test/tools/javac/MethodParameters/LocalClassTest.java ! test/tools/javac/MethodParameters/MemberClassTest.java From robert.field at oracle.com Thu Feb 21 23:47:12 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Thu, 21 Feb 2013 23:47:12 +0000 Subject: hg: jdk8/tl/jdk: 8008356: Test LambdaSerialization.java failing Message-ID: <20130221234732.5FCA747C5C@hg.openjdk.java.net> Changeset: 1da987f0311a Author: rfield Date: 2013-02-21 15:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1da987f0311a 8008356: Test LambdaSerialization.java failing Summary: run in /othervm mode Reviewed-by: ksrini ! test/java/lang/invoke/lambda/LambdaSerialization.java From brent.christian at oracle.com Fri Feb 22 00:34:36 2013 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 21 Feb 2013 16:34:36 -0800 Subject: RFR: 8006039 : test/tools/launcher/I18NJarTest.java fails on Mac w/ LANG=C, LC_ALL=C Message-ID: <5126BD1C.8030309@oracle.com> Hi, This test started failing after 8003228 [1] was putback (setting sun.jnu.encoding to UTF-8 on Mac). It tests if java is able to launch a .jar stored in a directory named with two-byte characters. The code comments in the test case state that (on Unix) it expects LC_ALL to be set (to ja_JP.UTF-8/ja_JP.utf8/ja_JP.ujis), though it also seems to work with en_US.UTF-8). Our automated build+test Macs have LANG=C, so the test has been "passing" without actually testing the functionality. The test case determines if the environment is suitable for testing by checking if sun.jnu.encoding is either "MS932" or "UTF-8" (on Mac, this is now always UTF-8). The test doesn't actually check LC_ALL. I think the test should also check the LANG & LC_ALL env vars, and go back to "fake passing" the test if either is set to 'C'. This would allow the test to continue to run "for real" in the default Mac environment (LANG=en_US.UTF-8), and stop the test from failing on the build+test Macs. Of course it would be even better to update the test so the automated test machines actually test the intended functionality. On UNIX at least, perhaps it could find something suitable to set LC_ALL to before attempting to launch the .jar. I can file a separate bug for this. Webrev is here: http://cr.openjdk.java.net/~bchristi/8006039/webrev.00/ Thanks, -Brent [1] http://bugs.sun.com/view_bug.do?bug_id=8003228 From mandy.chung at oracle.com Fri Feb 22 01:43:03 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 21 Feb 2013 17:43:03 -0800 Subject: 8008662: Add @jdk.Supported to JDK-specific/supported API In-Reply-To: <51266B7C.3040804@oracle.com> References: <51266B7C.3040804@oracle.com> Message-ID: <5126CD27.4010608@oracle.com> On 2/21/2013 10:46 AM, Alan Bateman wrote: > > Joe Darcy recently added @jdk.Supported [1] to make it possible to > identify JDK-specific APIs. > > I'd like to add this to a number of APIs in the com.sun namespace to > make it obvious these are "supported". It's nice to be able to mark what is supported vs unsupported in the com.sun namespace since there are a mix of supported and unsupported APIs. > [...] > The webrev with the changes is here: > > http://cr.openjdk.java.net/~alanb/8008662/webrev/ > Looks good to me. > In a couple of cases the package description is legacy package.html so > I've had to move/convert them to package-info.java. > > In all but one case I've added the annotation to the package-info, the > one exception is com.sun.management where there is at least one type > that is documented as "not supported". Joe Darcy might have > suggestions on that. > I wasn't aware of the unsupported com.sun.management.OSMBeanFactory class being included in the javadoc. I think that can be fixed and I'll file a bug and hopefully we can clean that up. Mandy > Otherwise this is mostly mechanical and the patch file is easier to > review that the webrev. > > -Alan > > [1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/55cca2f38ee6 From joe.darcy at oracle.com Fri Feb 22 01:46:12 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 21 Feb 2013 17:46:12 -0800 Subject: JDK RFR of 6556996: (ann spec) SuppressWarnings strings should be documented Message-ID: <5126CDE4.5050209@oracle.com> Hello, Please review the simple fix below for 6556996: (ann spec) SuppressWarnings strings should be documented http://bugs.sun.com/view_bug.do?bug_id=6556996 the webrev is at http://cr.openjdk.java.net/~darcy/6556996.0/ and the patch is below. In brief, the only required string to be recognized in the SuppressWarnings annotation is "unchecked", which has been required by the JLS since Java SE 5. I made that adjustment to the documentation of the SuppressWarnings type. In addition, I added more @jls links relating the documentation of various annotation type to the JLS sections which discuss them. Thanks, -Joe --- old/src/share/classes/java/lang/Deprecated.java 2013-02-21 17:37:08.000000000 -0800 +++ new/src/share/classes/java/lang/Deprecated.java 2013-02-21 17:37:08.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2010, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -36,6 +36,7 @@ * * @author Neal Gafter * @since 1.5 + * @jls 9.6.3.6 @Deprecated */ @Documented @Retention(RetentionPolicy.RUNTIME) --- old/src/share/classes/java/lang/Override.java 2013-02-21 17:37:09.000000000 -0800 +++ new/src/share/classes/java/lang/Override.java 2013-02-21 17:37:09.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2011, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -43,7 +43,7 @@ * * @author Peter von der Ahé * @author Joshua Bloch - * @jls 9.6.1.4 Override + * @jls 9.6.1.4 @Override * @since 1.5 */ @Target(ElementType.METHOD) --- old/src/share/classes/java/lang/SafeVarargs.java 2013-02-21 17:37:09.000000000 -0800 +++ new/src/share/classes/java/lang/SafeVarargs.java 2013-02-21 17:37:09.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2010, 2011, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2010, 2013, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -85,6 +85,7 @@ * @since 1.7 * @jls 4.7 Reifiable Types * @jls 8.4.1 Formal Parameters + * @jls 9.6.3.7 @SafeVarargs */ @Documented @Retention(RetentionPolicy.RUNTIME) --- old/src/share/classes/java/lang/SuppressWarnings.java 2013-02-21 17:37:10.000000000 -0800 +++ new/src/share/classes/java/lang/SuppressWarnings.java 2013-02-21 17:37:09.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2004, 2011, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -41,8 +41,11 @@ * suppress a warning in a particular method, you should annotate that * method rather than its class. * - * @since 1.5 * @author Josh Bloch + * @since 1.5 + * @jls 5.1.9. Unchecked Conversion + * @jls 5.5.2. Checked Casts and Unchecked Casts + * @jls 9.6.3.5 @SuppressWarnings */ @Target({TYPE, FIELD, METHOD, PARAMETER, CONSTRUCTOR, LOCAL_VARIABLE}) @Retention(RetentionPolicy.SOURCE) @@ -56,9 +59,11 @@ * free to emit a warning if an annotation contains an unrecognized * warning name. * - *

Compiler vendors should document the warning names they support in - * conjunction with this annotation type. They are encouraged to cooperate - * to ensure that the same names work across multiple compilers. + *

The string {@code "unchecked"} is used to suppress + * unchecked warnings. Compiler vendors should document the + * additional warning names they support in conjunction with this + * annotation type. They are encouraged to cooperate to ensure + * that the same names work across multiple compilers. */ String[] value(); } --- old/src/share/classes/java/lang/annotation/Inherited.java 2013-02-21 17:37:10.000000000 -0800 +++ new/src/share/classes/java/lang/annotation/Inherited.java 2013-02-21 17:37:10.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2004, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -44,6 +44,7 @@ * * @author Joshua Bloch * @since 1.5 + * @jls 9.6.3.3 @Inherited */ @Documented @Retention(RetentionPolicy.RUNTIME) --- old/src/share/classes/java/lang/annotation/Retention.java 2013-02-21 17:37:11.000000000 -0800 +++ new/src/share/classes/java/lang/annotation/Retention.java 2013-02-21 17:37:10.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2006, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -38,6 +38,7 @@ * * @author Joshua Bloch * @since 1.5 + * @jls 9.6.3.2 @Retention */ @Documented @Retention(RetentionPolicy.RUNTIME) --- old/src/share/classes/java/lang/annotation/Target.java 2013-02-21 17:37:11.000000000 -0800 +++ new/src/share/classes/java/lang/annotation/Target.java 2013-02-21 17:37:11.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2004, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -59,6 +59,9 @@ * ... * } * + * + * @since 1.5 + * @jls 9.6.3.1 @Target */ @Documented @Retention(RetentionPolicy.RUNTIME) From joe.darcy at oracle.com Fri Feb 22 02:16:54 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 21 Feb 2013 18:16:54 -0800 Subject: 8008662: Add @jdk.Supported to JDK-specific/supported API In-Reply-To: <51266B7C.3040804@oracle.com> References: <51266B7C.3040804@oracle.com> Message-ID: <5126D516.1040005@oracle.com> On 02/21/2013 10:46 AM, Alan Bateman wrote: > > Joe Darcy recently added @jdk.Supported [1] to make it possible to > identify JDK-specific APIs. > > I'd like to add this to a number of APIs in the com.sun namespace to > make it obvious these are "supported". Specifically I'm proposing to > add it to: To add some more context here, there are various APIs outside of the Java SE namespaces (java.* and javax.*) that are shipped with the JDK. Some of these APIs and meant to be called by normal users of the JDK and evolve under essentially the same general evolution policy [1] as the SE API. Call such non-SE APIs in the JDK "supported." One example of such a supported API is the javac Tree API in com.sun.source.* JDK 7: http://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/index.html JDK 8: http://download.java.net/jdk8/docs/jdk/api/javac/tree/index.html However, the com.sun.* subpackages are a mix of APIs that are supported as described above as well as APIs that are not supported. APIs that are not supported are *not* meant to be called by normal users of the JDK and can have a very different evolution policy, up to and including deletion from the JDK in a update release. The goal of adding the @Supported annotations is to allow these API categories to be more easily distinguished from each other, including enabling tools to check that @Supported(value=false) APIs are not referenced. The jdk.Supported annotation can be applied to both types and packages; it is *not* intended to allow modeling of supported-ness down to only a subset of methods of a type. In other words, if @jdk.Supported is applied to something, it is meant to refer to the whole entity, either all the parts of a type or all the types in a package. To make the information more prominent and easier to find, I recommend applying the annotation to both all the types in a package and the package itself, which is what I've done in the tree API. [2] In Alan's case below, I would not apply the annotation to a package if the package had a mix of supported and unsupported types. Cheers, -Joe [1] http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#general_evolution_policy [2] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/011cf7e0a148 > > - Java Debug Interface (com.sun.jdi) > - Attach API (com.sun.tools.attach) > - SCTP API (com.sun.nio.sctp) > - HTTP server API (com.sun.net.httpserver) > - Management extensions (com.sun.management) > - JDK-specific API to JAAS (com.sun.security.auth) > - JDK-specific JGSS API (com.sun.security.jgss) > > The javadoc for all of these is generated as part of the regular JDK > "docs" build and so shouldn't be controversial. There are a number of > other candidates in com.sun with murkier status that I've stayed clear > of for now. > > The webrev with the changes is here: > > http://cr.openjdk.java.net/~alanb/8008662/webrev/ > > In a couple of cases the package description is legacy package.html so > I've had to move/convert them to package-info.java. > > In all but one case I've added the annotation to the package-info, the > one exception is com.sun.management where there is at least one type > that is documented as "not supported". Joe Darcy might have > suggestions on that. > > Otherwise this is mostly mechanical and the patch file is easier to > review that the webrev. > > -Alan > > [1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/55cca2f38ee6 From dmitry.nadezhin at gmail.com Fri Feb 22 03:27:27 2013 From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin) Date: Fri, 22 Feb 2013 06:27:27 +0300 Subject: Withdraw: Review: 4396272 - Parsing doubles fails to follow IEEE for largest decimal that should yield 0 In-Reply-To: References: <4412AB7C-A91F-48A9-ACF2-3816480C28E1@oracle.com> Message-ID: Do you want that I prepare this FloatingDecimal/FormattedFloatingDecimal patch ? -Dima On Fri, Feb 22, 2013 at 2:32 AM, Brian Burkhalter wrote: > I am withdrawing this patch for the time being as properly the changes should also go into the fork sun.misc.FormattedFloatingDecimal. I'll post an updated patch once it is available. > > Thanks, > > Brian > > On Feb 14, 2013, at 5:23 PM, Brian Burkhalter wrote: > >> The patch below is as submitted to OpenJDK bugzilla but with enhanced comments. It pertains to the correction loop in the doubleValue() method of FloatingDecimal. The situation appears to arise when the candidate value is less than 2*Double.MIN_NORMAL as for such values the ULP is less than 2*Double.MIN_VALUE so that the intermediate result 0.5*ULP is less than Double.MIN_VALUE which rounds to zero per FP-strict and the correction is therefore zero. Thus the candidate value is unchanged. The fix is to add the ULP to twice the candidate value, obtain the intermediate result, and then halve it to obtain the adjusted candidate. >> >> I am relatively new to IEEE-754 and this area of the code so any comments would be appreciated. >> >> Thanks, >> >> Brian >> >> diff -r 1405ad6afb1e -r 36482ed9bb7e src/share/classes/sun/misc/FloatingDecimal.java >> --- a/src/share/classes/sun/misc/FloatingDecimal.java Thu Feb 14 11:09:07 2013 -0800 >> +++ b/src/share/classes/sun/misc/FloatingDecimal.java Thu Feb 14 16:47:53 2013 -0800 > From kumar.x.srinivasan at oracle.com Fri Feb 22 03:33:39 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 21 Feb 2013 19:33:39 -0800 Subject: RFR: 8006039 : test/tools/launcher/I18NJarTest.java fails on Mac w/ LANG=C, LC_ALL=C In-Reply-To: <5126BD1C.8030309@oracle.com> References: <5126BD1C.8030309@oracle.com> Message-ID: <5126E713.9090505@oracle.com> Hi Brent, I am not an expert here, and I am hoping someone from I18N also reviews this. A nit - " LC_ALL" + LC_ALL + "\n" + + " LC_ALL=" + LC_ALL + "\n" + If Mac is the only system affected by this, should we make the checks for LC* and LANG specific to Macs since other platforms don't have this issue ? I am concerned this might pass vacuously on systems configured correctly. Since the test extends TestHelper all you have to do is: - if("C".equals(LANG) || "C".equals(LC_ALL)) { + if (isMacOSX && ("C".equals(LANG) || "C".equals(LC_ALL))) { Kumar > Hi, > > This test started failing after 8003228 [1] was putback (setting > sun.jnu.encoding to UTF-8 on Mac). It tests if java is able to launch > a .jar stored in a directory named with two-byte characters. > > The code comments in the test case state that (on Unix) it expects > LC_ALL to be set (to ja_JP.UTF-8/ja_JP.utf8/ja_JP.ujis), though it > also seems to work with en_US.UTF-8). > > Our automated build+test Macs have LANG=C, so the test has been > "passing" without actually testing the functionality. > > The test case determines if the environment is suitable for testing by > checking if sun.jnu.encoding is either "MS932" or "UTF-8" (on Mac, > this is now always UTF-8). The test doesn't actually check LC_ALL. > > I think the test should also check the LANG & LC_ALL env vars, and go > back to "fake passing" the test if either is set to 'C'. This would > allow the test to continue to run "for real" in the default Mac > environment (LANG=en_US.UTF-8), and stop the test from failing on the > build+test Macs. > > Of course it would be even better to update the test so the automated > test machines actually test the intended functionality. On UNIX at > least, perhaps it could find something suitable to set LC_ALL to > before attempting to launch the .jar. I can file a separate bug for > this. > > Webrev is here: > http://cr.openjdk.java.net/~bchristi/8006039/webrev.00/ > > Thanks, > -Brent > > [1] > http://bugs.sun.com/view_bug.do?bug_id=8003228 From lana.steuck at oracle.com Fri Feb 22 03:39:08 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 22 Feb 2013 03:39:08 +0000 Subject: hg: jdk8/tl: 9 new changesets Message-ID: <20130222033909.2CDA947C63@hg.openjdk.java.net> Changeset: ffb4d2e95140 Author: erikj Date: 2013-02-15 10:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ffb4d2e95140 8005879: Add -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 to builds on Mac Reviewed-by: ohair ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: b0642df54d63 Author: erikj Date: 2013-02-18 10:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b0642df54d63 Merge Changeset: b80abec66e70 Author: bpatel Date: 2013-01-21 00:29 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b80abec66e70 8006124: javadoc/doclet should be updated to support profiles Reviewed-by: jjg, dholmes ! common/makefiles/javadoc/Javadoc.gmk Changeset: 7ed0c9db6943 Author: dholmes Date: 2013-01-21 01:50 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/7ed0c9db6943 8004265: Add build support for Compact Profiles Reviewed-by: erikj, ohair ! NewMakefile.gmk ! common/autoconf/generated-configure.sh ! common/makefiles/Main.gmk Changeset: 2f8fd30f02e6 Author: dholmes Date: 2013-01-22 19:30 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2f8fd30f02e6 Merge ! common/autoconf/generated-configure.sh Changeset: bebeaa04ab8e Author: dholmes Date: 2013-02-04 18:08 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/bebeaa04ab8e Merge ! common/autoconf/generated-configure.sh ! common/makefiles/javadoc/Javadoc.gmk Changeset: 28071e4ca1de Author: dholmes Date: 2013-02-17 16:44 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/28071e4ca1de Merge ! common/autoconf/generated-configure.sh ! common/makefiles/Main.gmk Changeset: fd1a5574cf68 Author: dholmes Date: 2013-02-18 15:35 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/fd1a5574cf68 Merge ! common/autoconf/generated-configure.sh Changeset: b70196e01c53 Author: lana Date: 2013-02-21 17:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b70196e01c53 Merge From lana.steuck at oracle.com Fri Feb 22 03:39:30 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 22 Feb 2013 03:39:30 +0000 Subject: hg: jdk8/tl/langtools: 5 new changesets Message-ID: <20130222033945.E1B3A47C64@hg.openjdk.java.net> Changeset: 5f0731e4e5e6 Author: bpatel Date: 2013-01-21 00:45 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5f0731e4e5e6 8006124: javadoc/doclet should be updated to support profiles Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java + src/share/classes/com/sun/tools/doclets/formats/html/AbstractProfileIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java + src/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java + src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java + src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java + src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageWriterImpl.java + src/share/classes/com/sun/tools/doclets/formats/html/ProfileWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlConstants.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/ProfilePackageSummaryWriter.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/ProfileSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/WriterFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ProfilePackageSummaryBuilder.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ProfileSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPaths.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MetaKeywords.java + test/com/sun/javadoc/testProfiles/TestProfiles.java + test/com/sun/javadoc/testProfiles/pkg1/Class1Pkg1.java + test/com/sun/javadoc/testProfiles/pkg1/Class2Pkg1.java + test/com/sun/javadoc/testProfiles/pkg1/Class3Pkg1.java + test/com/sun/javadoc/testProfiles/pkg1/Interface1Pkg1.java + test/com/sun/javadoc/testProfiles/pkg2/Anno1Pkg2.java + test/com/sun/javadoc/testProfiles/pkg2/Anno2Pkg2.java + test/com/sun/javadoc/testProfiles/pkg2/Class1Pkg2.java + test/com/sun/javadoc/testProfiles/pkg3/Class1Pkg3.java + test/com/sun/javadoc/testProfiles/pkg3/Class2Pkg3.java + test/com/sun/javadoc/testProfiles/pkg3/Interface1Pkg3.java + test/com/sun/javadoc/testProfiles/pkg4/Anno1Pkg4.java + test/com/sun/javadoc/testProfiles/pkg4/Class1Pkg4.java + test/com/sun/javadoc/testProfiles/pkg5/Class1Pkg5.java + test/com/sun/javadoc/testProfiles/pkg5/Interface1Pkg5.java + test/com/sun/javadoc/testProfiles/profile-rtjar-includes.txt Changeset: 475eb15dfdad Author: jjg Date: 2013-01-21 01:27 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/475eb15dfdad 8004182: Add support for profiles in javac Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/code/Flags.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/jvm/ClassReader.java + src/share/classes/com/sun/tools/javac/jvm/Profile.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/main/Option.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/resources/javac.properties ! src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java + src/share/classes/com/sun/tools/javac/sym/Profiles.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java + test/tools/javac/diags/examples/NotInProfile.java + test/tools/javac/profiles/ProfileOptionTest.java Changeset: f91144b7da75 Author: dholmes Date: 2013-02-04 18:08 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f91144b7da75 Merge ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties ! src/share/classes/com/sun/tools/javac/code/Flags.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/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java - test/tools/javac/annotations/repeatingAnnotations/MissingContainedBy.java - test/tools/javac/annotations/repeatingAnnotations/MissingContainerFor.java - test/tools/javac/annotations/repeatingAnnotations/UseWrongContainedBy.java - test/tools/javac/annotations/repeatingAnnotations/UseWrongContainerFor.java - test/tools/javac/annotations/repeatingAnnotations/WrongContainedBy.java - test/tools/javac/annotations/repeatingAnnotations/WrongContainerFor.java - test/tools/javac/diags/examples/ContainedByDocumentedMismatch.java - test/tools/javac/diags/examples/ContainedByInheritedMismatch.java - test/tools/javac/diags/examples/ContainedByNoValue.java - test/tools/javac/diags/examples/ContainedByNonDefault.java - test/tools/javac/diags/examples/ContainedByRetentionMismatch.java - test/tools/javac/diags/examples/ContainedByTargetMismatch.java - test/tools/javac/diags/examples/ContainedByWrongValueType.java - test/tools/javac/diags/examples/InferredDoNotConformToLower.java - test/tools/javac/diags/examples/NoUniqueMaximalInstance.java - test/tools/javac/diags/examples/WrongContainedBy.java - test/tools/javac/diags/examples/WrongContainerFor.java - test/tools/javac/lambda/MethodReference26.out - test/tools/javac/lambda/TargetType06.out - test/tools/javac/lambda/TargetType11.out - test/tools/javac/lambda/TargetType45.out - test/tools/javac/lambda/VoidCompatibility.out - test/tools/javac/typeAnnotations/newlocations/BasicTest.java - test/tools/javac/typeAnnotations/newlocations/BasicTest.out Changeset: af8417e590f4 Author: dholmes Date: 2013-02-17 16:44 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/af8417e590f4 Merge ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/javac/code/Flags.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/jvm/ClassReader.java - test/tools/javac/lambda/TargetType20.out - test/tools/javac/lambda/TargetType50.out Changeset: 6118072811e5 Author: lana Date: 2013-02-21 17:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6118072811e5 Merge ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/code/Flags.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/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties From david.holmes at oracle.com Fri Feb 22 03:42:03 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Feb 2013 13:42:03 +1000 Subject: RFR: 8005545: Add System property to identify ARCH specific details such as ARM hard-float binaries In-Reply-To: <899E92AE-F8A0-4873-B8DC-EE642B615840@oracle.com> References: <899E92AE-F8A0-4873-B8DC-EE642B615840@oracle.com> Message-ID: <5126E90B.8070205@oracle.com> Hi Vlad, On 22/02/2013 8:02 AM, Vladimir Danushevsky wrote: > Please review changes for > https://jbs.oracle.com/bugs/browse/JDK-8005545 "Add System property to > identify ARCH specific details such as ARM hard-float binaries" which > adds an optional sun.os.abi Java system property indicating an ABI type > being used by the JVM: > > CCC Reguest: http://ccc.us.oracle.com/8005545 Neither of the above URLs are accessible outside Oracle. > Webrev: > http://cr.openjdk.java.net/~vladidan/8005545/webrev.00/ Looks okay (names not withstanding :)) At some point this will need to sync with profiles changes in Images.gmk that also updates the release file. I did it a slightly different way when the "obvious" way (using ifneq inside 'define create-info-file') didn't work - I added to the actual recipe: $(JRE_INFO_FILE): $(OUTPUT_ROOT)/spec.gmk $(OUTPUT_ROOT)/source_tips $(ECHO) $(LOG_INFO) Generating $(patsubst $(OUTPUT_ROOT)/%,%,$@) $(call create-info-file) ifneq ($(PROFILE),) $(call info-file-item, "JAVA_PROFILE", "$(call profile_name, $(call profile_number, $(PROFILE)))") endif (that was only needed for a JRE not the JDK). Doing it via the shell is cleaner I think. David ----- > Separate change to the build script (e.g. in ARM Hard-Float ABI case): > setenv ARCHABIPROPNAME gnueabihf > -DARCHABIPROPNAME="\"$(ARCHABIPROPNAME)\"" is passed to the CFLAGS > > Thanks, > Vlad From lana.steuck at oracle.com Fri Feb 22 03:40:45 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 22 Feb 2013 03:40:45 +0000 Subject: hg: jdk8/tl/jdk: 23 new changesets Message-ID: <20130222034515.E3E2847C65@hg.openjdk.java.net> Changeset: 90707943f83c Author: erikj Date: 2013-02-15 10:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90707943f83c 8005879: Add -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 to builds on Mac Reviewed-by: ohair ! make/common/Defs-macosx.gmk Changeset: 9a693ebd5595 Author: erikj Date: 2013-02-18 10:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9a693ebd5595 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: fb7e3edf22b2 Author: erikj Date: 2013-02-18 11:26 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fb7e3edf22b2 8008294: build-infra: Build-infra closed fails on solaris 11.1 Reviewed-by: ohrstrom, dholmes, tbell ! makefiles/CompileDemos.gmk ! makefiles/CompileNativeLibraries.gmk Changeset: a23b0df73324 Author: erikj Date: 2013-02-18 11:27 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a23b0df73324 8008295: build-infra: Cleanup in Import.gmk Reviewed-by: ohrstrom, tbell ! makefiles/Import.gmk Changeset: 32549d339437 Author: bpatel Date: 2013-01-21 00:31 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/32549d339437 8006124: javadoc/doclet should be updated to support profiles Reviewed-by: jjg, dholmes ! make/docs/Makefile Changeset: 80afadbf967d Author: alanb Date: 2013-01-21 01:46 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80afadbf967d 8004182: Add support for profiles in javac Reviewed-by: dholmes ! make/common/Release.gmk Changeset: 353b88963430 Author: dholmes Date: 2013-01-21 21:54 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/353b88963430 8006651: build-infra: Import.gmk needs to add support for the minimal VM Reviewed-by: erikj, ohair ! makefiles/Import.gmk Changeset: 7096f51288ab Author: dholmes Date: 2013-01-21 23:17 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7096f51288ab 8004265: Add build support for Compact Profiles Reviewed-by: erikj, ohair ! make/tools/src/build/tools/jarreorder/JarReorder.java ! makefiles/BuildJdk.gmk ! makefiles/CreateJars.gmk ! makefiles/Images.gmk + makefiles/ProfileNames.gmk + makefiles/Profiles.gmk Changeset: ccd0aceb1190 Author: alanb Date: 2013-01-21 23:20 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ccd0aceb1190 8003255: (profiles) Update JAR file specification to support profiles Reviewed-by: dholmes, mchung, ksrini ! src/share/classes/java/net/URLClassLoader.java ! src/share/classes/java/util/jar/Attributes.java + src/share/classes/java/util/jar/UnsupportedProfileException.java ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties ! src/share/classes/sun/misc/URLClassPath.java ! src/share/classes/sun/tools/jar/Main.java ! src/share/classes/sun/tools/jar/resources/jar.properties + test/java/net/URLClassLoader/profiles/Basic.java + test/java/net/URLClassLoader/profiles/Lib.java + test/java/net/URLClassLoader/profiles/basic.sh + test/tools/jar/AddAndUpdateProfile.java + test/tools/launcher/profiles/Basic.java + test/tools/launcher/profiles/Logging.java + test/tools/launcher/profiles/Main.java Changeset: c024147205f6 Author: alanb Date: 2013-01-21 23:21 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c024147205f6 8003256: (profiles) Add support for profile identification Reviewed-by: dholmes, mchung, ksrini ! make/java/version/Makefile ! makefiles/GensrcMisc.gmk ! src/share/classes/sun/misc/Version.java.template + test/tools/launcher/profiles/VersionCheck.java Changeset: 4b3434f5f509 Author: alanb Date: 2013-01-21 23:23 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4b3434f5f509 8004931: add/removePropertyChangeListener should not exist in subset Profiles of Java SE Reviewed-by: dholmes, mchung, ksrini + make/tools/src/build/tools/RemoveMethods.java ! makefiles/Tools.gmk ! src/share/classes/java/util/jar/Pack200.java ! src/share/classes/java/util/logging/LogManager.java + test/java/util/logging/Reflect.java + test/tools/pack200/NoBeans.java + test/tools/pack200/Reflect.java Changeset: d9cfe581c8fe Author: alanb Date: 2013-01-21 23:35 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d9cfe581c8fe 8004502: Compact Profiles contents Reviewed-by: dholmes, mchung + makefiles/profile-includes.txt + makefiles/profile-rtjar-includes.txt + test/java/lang/SecurityManager/NoAWT.java + test/java/security/cert/CertStore/NoLDAP.java + test/javax/management/remote/mandatory/connection/NoIIOP.java + test/javax/naming/InitialContext/NoApplet.java + test/sun/net/www/protocol/http/NoNTLM.java + test/sun/security/ssl/sanity/ciphersuites/NoKerberos.java Changeset: d1b29d290ebd Author: dholmes Date: 2013-01-22 19:31 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d1b29d290ebd Merge Changeset: 0918d6d9c18b Author: dholmes Date: 2013-01-22 20:04 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0918d6d9c18b 8006667: Merge issue: Profile attribute need to be examined before custom attributes Summary: swap profile checking and FXHelper checking Reviewed-by: alanb ! src/share/classes/sun/launcher/LauncherHelper.java Changeset: 77668918a388 Author: dholmes Date: 2013-02-04 18:08 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/77668918a388 Merge ! make/docs/Makefile ! makefiles/CreateJars.gmk ! makefiles/GensrcMisc.gmk ! makefiles/Tools.gmk ! src/share/classes/sun/misc/URLClassPath.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/CallbackInterface.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/Callback_Stub.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup_Stub.java Changeset: f308a689c049 Author: dholmes Date: 2013-02-17 16:44 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f308a689c049 Merge ! makefiles/Tools.gmk - src/macosx/classes/sun/lwawt/macosx/EventDispatchAccess.java - src/share/classes/java/lang/annotation/ContainedBy.java - src/share/classes/java/lang/annotation/ContainerFor.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/net/URL/abnormal_http_urls - test/java/net/URL/ftp_urls - test/java/net/URL/jar_urls - test/java/net/URL/normal_http_urls - test/java/net/URL/runconstructor.sh - test/java/net/URL/share_file_urls - test/java/net/URL/win32_file_urls - 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 - test/sun/net/www/EncDec.doc - test/sun/net/www/MarkResetTest.java - test/sun/net/www/MarkResetTest.sh - test/sun/security/util/Oid/S11N.sh - test/sun/security/util/Oid/SerialTest.java Changeset: 16c684b2ab82 Author: alanb Date: 2013-02-18 08:57 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/16c684b2ab82 8007436: (profiles) Add JSR-310 to Compact Profiles contents Reviewed-by: dholmes, erikj ! makefiles/profile-includes.txt ! makefiles/profile-rtjar-includes.txt Changeset: c24bc91caa67 Author: dholmes Date: 2013-02-18 15:35 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c24bc91caa67 Merge ! makefiles/Import.gmk Changeset: b46c75e221c7 Author: dholmes Date: 2013-02-19 06:27 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b46c75e221c7 8008424: Isolate PROFILE make variable from incidental setting in the environment Reviewed-by: erikj, alanb ! makefiles/BuildJdk.gmk Changeset: 6f4615fd32da Author: alanb Date: 2013-02-19 11:08 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6f4615fd32da 8007097: (profiles) Build needs test to ensure that profile definitions are updated Reviewed-by: dholmes, erikj - make/tools/src/build/tools/RemoveMethods.java + make/tools/src/build/tools/classfile/RemoveMethods.java + make/tools/src/build/tools/deps/CheckDeps.java + make/tools/src/build/tools/deps/refs.allowed ! makefiles/Images.gmk ! makefiles/Tools.gmk ! makefiles/profile-rtjar-includes.txt Changeset: 033f2707ef32 Author: alanb Date: 2013-02-19 11:32 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/033f2707ef32 Merge Changeset: 00b7535d743f Author: dholmes Date: 2013-02-19 17:32 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/00b7535d743f 8008481: Dependency analyzer needs exclusion for profile builds with JFR disabled Reviewed-by: alanb ! make/tools/src/build/tools/deps/refs.allowed Changeset: 03db11a7fb8e Author: lana Date: 2013-02-21 17:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/03db11a7fb8e Merge From chris.hegarty at oracle.com Fri Feb 22 08:54:06 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 22 Feb 2013 08:54:06 +0000 Subject: 8008662: Add @jdk.Supported to JDK-specific/supported API In-Reply-To: <51266B7C.3040804@oracle.com> References: <51266B7C.3040804@oracle.com> Message-ID: <5127322E.8070809@oracle.com> Thank you Alan, this will clear up a lot of issues surrounding these API's. I skimmed over the changes, paying particular attention to the httpserver and sctp packages. -Chris. On 02/21/2013 06:46 PM, Alan Bateman wrote: > > Joe Darcy recently added @jdk.Supported [1] to make it possible to > identify JDK-specific APIs. > > I'd like to add this to a number of APIs in the com.sun namespace to > make it obvious these are "supported". Specifically I'm proposing to > add it to: > > - Java Debug Interface (com.sun.jdi) > - Attach API (com.sun.tools.attach) > - SCTP API (com.sun.nio.sctp) > - HTTP server API (com.sun.net.httpserver) > - Management extensions (com.sun.management) > - JDK-specific API to JAAS (com.sun.security.auth) > - JDK-specific JGSS API (com.sun.security.jgss) > > The javadoc for all of these is generated as part of the regular JDK > "docs" build and so shouldn't be controversial. There are a number of > other candidates in com.sun with murkier status that I've stayed clear > of for now. > > The webrev with the changes is here: > > http://cr.openjdk.java.net/~alanb/8008662/webrev/ > > In a couple of cases the package description is legacy package.html so > I've had to move/convert them to package-info.java. > > In all but one case I've added the annotation to the package-info, the > one exception is com.sun.management where there is at least one type > that is documented as "not supported". Joe Darcy might have suggestions > on that. > > Otherwise this is mostly mechanical and the patch file is easier to > review that the webrev. > > -Alan > > [1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/55cca2f38ee6 From chris.hegarty at oracle.com Fri Feb 22 10:11:12 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 22 Feb 2013 10:11:12 +0000 Subject: hg: jdk8/tl/jdk: 8006182: cleanup to use java.util.Base64 in java security component, providers, and regression tests Message-ID: <20130222101139.E2A8E47C6C@hg.openjdk.java.net> Changeset: 9078c34437ab Author: msheppar Date: 2013-02-21 20:01 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9078c34437ab 8006182: cleanup to use java.util.Base64 in java security component, providers, and regression tests Summary: Refactored code to use java.util.Base64 Mime Encoder and Decoder as a replacement for sun.misc.BASE64Encoder and sun.misc.BASE64Decoder Reviewed-by: vinnie, chegar, sherman ! src/share/classes/sun/security/pkcs10/PKCS10.java ! src/share/classes/sun/security/provider/X509Factory.java ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/classes/sun/security/tools/keytool/Main.java ! src/share/classes/sun/security/util/ManifestEntryVerifier.java ! src/share/classes/sun/security/util/SignatureFileVerifier.java ! src/share/classes/sun/security/x509/X509CertImpl.java ! src/share/classes/sun/tools/jar/Manifest.java ! src/share/classes/sun/tools/jar/SignatureFile.java ! test/javax/security/auth/kerberos/KerberosTixDateTest.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/MD2InTrustAnchor.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/TrustTrustedCert.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/BasicConstraints.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SelfIssuedCert.java ! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/ProxyTunnelServer.java ! test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISensitive.java ! test/sun/security/ssl/javax/net/ssl/TLSv12/DisabledShortRSAKeys.java ! test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKey512.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/ProxyTunnelServer.java From Alan.Bateman at oracle.com Fri Feb 22 10:57:20 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 Feb 2013 10:57:20 +0000 Subject: RFR: 8005545: Add System property to identify ARCH specific details such as ARM hard-float binaries In-Reply-To: <899E92AE-F8A0-4873-B8DC-EE642B615840@oracle.com> References: <899E92AE-F8A0-4873-B8DC-EE642B615840@oracle.com> Message-ID: <51274F10.6020208@oracle.com> On 21/02/2013 22:02, Vladimir Danushevsky wrote: > : > > Webrev: > http://cr.openjdk.java.net/~vladidan/8005545/webrev.00/ > > > Separate change to the build script (e.g. in ARM Hard-Float ABI case): > setenv ARCHABIPROPNAME gnueabihf > -DARCHABIPROPNAME="\"$(ARCHABIPROPNAME)\"" is passed to the CFLAGS > I agree with Bob on the naming, otherwise it looks okay to me. On the release file and Images.gmk then jdk/tl was sync'ed up yesterday so you will probably need to re-base the patch. -Alan From nils.loodin at oracle.com Fri Feb 22 13:10:02 2013 From: nils.loodin at oracle.com (Nils Loodin) Date: Fri, 22 Feb 2013 14:10:02 +0100 Subject: Fwd: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <5115316A.8050109@oracle.com> References: <5115316A.8050109@oracle.com> Message-ID: <51276E2A.40402@oracle.com> Does anyone have anything strongly against this? This is a small change just to add a performance counter, the code to increment it and read it will live in other parts of the code and be a part of a larger separate commit. Alan Bateman gave the response that the name was inappropriate, but I don't really have a better alternative, but neither do I have strong opinions, so feedback would be appreciated! How about "sun.throwables.thrownThrowables" ? Regards, Nils Loodin -------- Original Message -------- Subject: RFR: 8007806: Need a Throwables performance counter Date: Fri, 08 Feb 2013 18:10:02 +0100 From: Nils Loodin To: core-libs-dev at openjdk.java.net, serviceability_dev_ww_grp It would be interesting to know the number of thrown throwables in the JVM, to be able to do some high level application diagnostics / statistics. A good way to put this number would be a performance counter, since it is accessible both from Java and from the VM. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007806 http://cr.openjdk.java.net/~nloodin/8007806/webrev.00/ Regards, Nils Loodin From maurizio.cimadamore at oracle.com Fri Feb 22 13:32:07 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 22 Feb 2013 13:32:07 +0000 Subject: hg: jdk8/tl/langtools: 8008337: Write test to check for compiler error when static method in interface is called via super() Message-ID: <20130222133212.B496F47C72@hg.openjdk.java.net> Changeset: 8e82e4f225e4 Author: mcimadamore Date: 2013-02-22 13:31 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8e82e4f225e4 8008337: Write test to check for compiler error when static method in interface is called via super() Reviewed-by: mcimadamore Contributed-by: sonali.goel at oracle.com + test/tools/javac/lambda/StaticMethodNegTest.java + test/tools/javac/lambda/StaticMethodNegTest.out From Alan.Bateman at oracle.com Fri Feb 22 13:44:01 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 Feb 2013 13:44:01 +0000 Subject: Fwd: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <51276E2A.40402@oracle.com> References: <5115316A.8050109@oracle.com> <51276E2A.40402@oracle.com> Message-ID: <51277621.7050407@oracle.com> On 22/02/2013 13:10, Nils Loodin wrote: > Does anyone have anything strongly against this? This is a small > change just to add a performance counter, the code to increment it and > read it will live in other parts of the code and be a part of a larger > separate commit. > > Alan Bateman gave the response that the name was inappropriate, but I > don't really have a better alternative, but neither do I have strong > opinions, so feedback would be appreciated! > > How about > "sun.throwables.thrownThrowables" ? > My comment on the counter name was mostly that sun.misc.PerfCounter isn't really the right place to create a hotspot.* counters. Using the eixsting sun.* or start a new jdk.* name space seems more appropriate. I don't have a strong opinion on the name. -Alan. From martinrb at google.com Fri Feb 22 14:06:52 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 22 Feb 2013 06:06:52 -0800 Subject: 8008662: Add @jdk.Supported to JDK-specific/supported API In-Reply-To: <5126D516.1040005@oracle.com> References: <51266B7C.3040804@oracle.com> <5126D516.1040005@oracle.com> Message-ID: On Thu, Feb 21, 2013 at 6:16 PM, Joe Darcy wrote: > > However, the com.sun.* subpackages are a mix of APIs that are supported as > described above as well as APIs that are not supported. I was under the impression that the general rule was that all of com.sun.* fell under the "jdk supported" umbrella, and the level of support was the distinction between sun.com.* and sun.* . In any case, it would be good if there was a single canonical place that documented the various levels of support with subtle distinctions, including java.* vs. javax.*, endorsed standards, com.sun.* vs. sun.* vs. jdk.*, and recommendations for where non-Oracle vendor extensions should go. Is the jdk.Supported annotation itself part of Java SE? Should third-party vendor extensions that are "supported" for public use by the third-party use jdk.Supported? What about the X's in hotspot flags and the java tools command line interfaces? From Lance.Andersen at oracle.com Fri Feb 22 14:12:05 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 22 Feb 2013 09:12:05 -0500 Subject: Review request for 8008716 to address typo in CallableStatement javadocs Message-ID: <5CC14CBA-9B33-4A50-B8E7-8CBD4DFF1A20@oracle.com> H alli, This is a review request for 8008716 to address a couple of typos in CallableStatement: $ hg diff CallableStatement.java diff -r 7dcb74c3ffba src/share/classes/java/sql/CallableStatement.java --- a/src/share/classes/java/sql/CallableStatement.java Tue Feb 12 09:25:43 2013 -0800 +++ b/src/share/classes/java/sql/CallableStatement.java Fri Feb 22 09:02:51 2013 -0500 @@ -2621,7 +2621,7 @@ * parameter determines the Java type that must be used * in the {@code get} method to read the value of that parameter. *

- * This version of {@code registrOutParameter} should be + * This version of {@code registerOutParameter} should be * used when the parameter is of JDBC type {@code JDBCType.NUMERIC} * or {@code JDBCType.DECIMAL}. *

@@ -2649,7 +2649,7 @@ /** * Registers the designated output parameter. * This version of - * the method {@code registrOutParameter} + * the method {@code registerOutParameter} * should be used for a user-defined or {@code REF} output parameter. * Examples * of user-defined types include: {@code STRUCT}, {@code DISTINCT}, @@ -2717,7 +2717,7 @@ * register the OUT Parameter. * If the parameter is of JDBC type {@code JDBCType.NUMERIC} * or {@code JDBCType.DECIMAL}, the version of - * {@code registrOutParameter} that accepts a scale value + * {@code registerOutParameter} that accepts a scale value * should be used. * @exception SQLException if parameterName does not correspond to a named * parameter; if a database access error occurs or @@ -2745,7 +2745,7 @@ * parameter determines the Java type that must be used * in the {@code get} method to read the value of that parameter. *

- * This version of {@code registrOutParameter} should be + * This version of {@code registerOutParameter} should be * used when the parameter is of JDBC type {@code JDBCType.NUMERIC} * or {@code JDBCType.DECIMAL}. *

@@ -2774,7 +2774,7 @@ /** * Registers the designated output parameter. This version of - * the method {@code registrOutParameter} + * the method {@code registerOutParameter} * should be used for a user-named or REF output parameter. Examples * of user-named types include: STRUCT, DISTINCT, JAVA_OBJECT, and * named array types. 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 alan.bateman at oracle.com Fri Feb 22 14:12:44 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 22 Feb 2013 14:12:44 +0000 Subject: hg: jdk8/tl/jdk: 8008290: (profiles) Startup regression due to additional checking of JAR file manifests Message-ID: <20130222141307.4732F47C73@hg.openjdk.java.net> Changeset: 63fe6a9820b6 Author: alanb Date: 2013-02-22 14:04 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/63fe6a9820b6 8008290: (profiles) Startup regression due to additional checking of JAR file manifests Reviewed-by: lancea, chegar, iris, mchung, sherman ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/jar/JavaUtilJarAccessImpl.java ! src/share/classes/sun/misc/JavaUtilJarAccess.java ! src/share/classes/sun/misc/URLClassPath.java From chris.hegarty at oracle.com Fri Feb 22 14:17:04 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 22 Feb 2013 14:17:04 +0000 Subject: Review request for 8008716 to address typo in CallableStatement javadocs In-Reply-To: <5CC14CBA-9B33-4A50-B8E7-8CBD4DFF1A20@oracle.com> References: <5CC14CBA-9B33-4A50-B8E7-8CBD4DFF1A20@oracle.com> Message-ID: <51277DE0.8090304@oracle.com> Looks fine to me Lance. -Chris. On 02/22/2013 02:12 PM, Lance Andersen - Oracle wrote: > H alli, > > This is a review request for 8008716 to address a couple of typos in CallableStatement: > > > $ hg diff CallableStatement.java > diff -r 7dcb74c3ffba src/share/classes/java/sql/CallableStatement.java > --- a/src/share/classes/java/sql/CallableStatement.java Tue Feb 12 09:25:43 2013 -0800 > +++ b/src/share/classes/java/sql/CallableStatement.java Fri Feb 22 09:02:51 2013 -0500 > @@ -2621,7 +2621,7 @@ > * parameter determines the Java type that must be used > * in the {@code get} method to read the value of that parameter. > *

> - * This version of {@code registrOutParameter} should be > + * This version of {@code registerOutParameter} should be > * used when the parameter is of JDBC type {@code JDBCType.NUMERIC} > * or {@code JDBCType.DECIMAL}. > *

> @@ -2649,7 +2649,7 @@ > /** > * Registers the designated output parameter. > * This version of > - * the method {@code registrOutParameter} > + * the method {@code registerOutParameter} > * should be used for a user-defined or {@code REF} output parameter. > * Examples > * of user-defined types include: {@code STRUCT}, {@code DISTINCT}, > @@ -2717,7 +2717,7 @@ > * register the OUT Parameter. > * If the parameter is of JDBC type {@code JDBCType.NUMERIC} > * or {@code JDBCType.DECIMAL}, the version of > - * {@code registrOutParameter} that accepts a scale value > + * {@code registerOutParameter} that accepts a scale value > * should be used. > * @exception SQLException if parameterName does not correspond to a named > * parameter; if a database access error occurs or > @@ -2745,7 +2745,7 @@ > * parameter determines the Java type that must be used > * in the {@code get} method to read the value of that parameter. > *

> - * This version of {@code registrOutParameter} should be > + * This version of {@code registerOutParameter} should be > * used when the parameter is of JDBC type {@code JDBCType.NUMERIC} > * or {@code JDBCType.DECIMAL}. > *

> @@ -2774,7 +2774,7 @@ > > /** > * Registers the designated output parameter. This version of > - * the method {@code registrOutParameter} > + * the method {@code registerOutParameter} > * should be used for a user-named or REF output parameter. Examples > * of user-named types include: STRUCT, DISTINCT, JAVA_OBJECT, and > * named array types. > > > 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 sean.mullan at oracle.com Fri Feb 22 14:26:55 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 22 Feb 2013 09:26:55 -0500 Subject: 8008662: Add @jdk.Supported to JDK-specific/supported API In-Reply-To: <51266B7C.3040804@oracle.com> References: <51266B7C.3040804@oracle.com> Message-ID: <5127802F.6080200@oracle.com> The security related ones look ok to me. --Sean On 02/21/2013 01:46 PM, Alan Bateman wrote: > > Joe Darcy recently added @jdk.Supported [1] to make it possible to > identify JDK-specific APIs. > > I'd like to add this to a number of APIs in the com.sun namespace to > make it obvious these are "supported". Specifically I'm proposing to > add it to: > > - Java Debug Interface (com.sun.jdi) > - Attach API (com.sun.tools.attach) > - SCTP API (com.sun.nio.sctp) > - HTTP server API (com.sun.net.httpserver) > - Management extensions (com.sun.management) > - JDK-specific API to JAAS (com.sun.security.auth) > - JDK-specific JGSS API (com.sun.security.jgss) > > The javadoc for all of these is generated as part of the regular JDK > "docs" build and so shouldn't be controversial. There are a number of > other candidates in com.sun with murkier status that I've stayed clear > of for now. > > The webrev with the changes is here: > > http://cr.openjdk.java.net/~alanb/8008662/webrev/ > > In a couple of cases the package description is legacy package.html so > I've had to move/convert them to package-info.java. > > In all but one case I've added the annotation to the package-info, the > one exception is com.sun.management where there is at least one type > that is documented as "not supported". Joe Darcy might have suggestions > on that. > > Otherwise this is mostly mechanical and the patch file is easier to > review that the webrev. > > -Alan > > [1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/55cca2f38ee6 From Alan.Bateman at oracle.com Fri Feb 22 14:37:28 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 Feb 2013 14:37:28 +0000 Subject: 8008662: Add @jdk.Supported to JDK-specific/supported API In-Reply-To: References: <51266B7C.3040804@oracle.com> <5126D516.1040005@oracle.com> Message-ID: <512782A8.3060202@oracle.com> On 22/02/2013 14:06, Martin Buchholz wrote: > > I was under the impression that the general rule was that all of > com.sun.* fell under the "jdk supported" umbrella, and the level of > support was the distinction between sun.com.* and sun.* . > com.sun is a mixed bag. There are lots of com.sun.*.internal that are clearly JDK internal/implementation/stay-away but several useful and documented APIs are in com.sun too (the JDK build generates the javadoc for these). In addition there are several APIs with murkier pasts, transitional APIs for areas that previous had a life as a standalone technology before coming into the JDK. -Alan. From lance.andersen at oracle.com Fri Feb 22 14:59:27 2013 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Fri, 22 Feb 2013 14:59:27 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130222145950.715BF47C76@hg.openjdk.java.net> Changeset: 9f9dac5a9e74 Author: lancea Date: 2013-02-22 09:29 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9f9dac5a9e74 8008716: address typo in CallableStatement javadocs Reviewed-by: chegar ! src/share/classes/java/sql/CallableStatement.java Changeset: 8d8a35ac7d40 Author: lancea Date: 2013-02-22 09:58 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8d8a35ac7d40 Merge From jason_mehrens at hotmail.com Fri Feb 22 16:16:36 2013 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Fri, 22 Feb 2013 10:16:36 -0600 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <51276E2A.40402@oracle.com> References: <5115316A.8050109@oracle.com>,<51276E2A.40402@oracle.com> Message-ID: >From this webrev http://cr.openjdk.java.net/~nloodin/exception-tracing/webrev.01/ you are counting the number of throwables constructed. You might want to change the name to reflect that. I don't think anyone would want to write a spec for how many throwables are thrown given that a throwable can be wrapped, suppressed, rethrown, etc. Jason > Date: Fri, 22 Feb 2013 14:10:02 +0100 > From: nils.loodin at oracle.com > To: core-libs-dev at openjdk.java.net; serviceability-dev at openjdk.java.net > Subject: Fwd: RFR: 8007806: Need a Throwables performance counter > > Does anyone have anything strongly against this? This is a small change > just to add a performance counter, the code to increment it and read it > will live in other parts of the code and be a part of a larger separate > commit. > > Alan Bateman gave the response that the name was inappropriate, but I > don't really have a better alternative, but neither do I have strong > opinions, so feedback would be appreciated! > > How about > "sun.throwables.thrownThrowables" ? > > Regards, > Nils Loodin > > > -------- Original Message -------- > Subject: RFR: 8007806: Need a Throwables performance counter > Date: Fri, 08 Feb 2013 18:10:02 +0100 > From: Nils Loodin > To: core-libs-dev at openjdk.java.net, serviceability_dev_ww_grp > > > It would be interesting to know the number of thrown throwables in the > JVM, to be able to do some high level application diagnostics / > statistics. A good way to put this number would be a performance > counter, since it is accessible both from Java and from the VM. > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007806 > http://cr.openjdk.java.net/~nloodin/8007806/webrev.00/ > > Regards, > Nils Loodin > > From brian.burkhalter at oracle.com Fri Feb 22 16:46:49 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 22 Feb 2013 08:46:49 -0800 Subject: Withdraw: Review: 4396272 - Parsing doubles fails to follow IEEE for largest decimal that should yield 0 In-Reply-To: References: <4412AB7C-A91F-48A9-ACF2-3816480C28E1@oracle.com> Message-ID: Hello Dima, Yes that would be helpful and appreciated. There is another patch to the same files that I will be looking into, but the changes are disjoint so there should not be a significant merge issue. Thanks, Brian On Feb 21, 2013, at 7:27 PM, Dmitry Nadezhin wrote: > Do you want that I prepare this FloatingDecimal/FormattedFloatingDecimal patch ? > > -Dima > > On Fri, Feb 22, 2013 at 2:32 AM, Brian Burkhalter > wrote: >> I am withdrawing this patch for the time being as properly the changes should also go into the fork sun.misc.FormattedFloatingDecimal. I'll post an updated patch once it is available. >> >> Thanks, >> >> Brian >> >> On Feb 14, 2013, at 5:23 PM, Brian Burkhalter wrote: >> >>> The patch below is as submitted to OpenJDK bugzilla but with enhanced comments. It pertains to the correction loop in the doubleValue() method of FloatingDecimal. The situation appears to arise when the candidate value is less than 2*Double.MIN_NORMAL as for such values the ULP is less than 2*Double.MIN_VALUE so that the intermediate result 0.5*ULP is less than Double.MIN_VALUE which rounds to zero per FP-strict and the correction is therefore zero. Thus the candidate value is unchanged. The fix is to add the ULP to twice the candidate value, obtain the intermediate result, and then halve it to obtain the adjusted candidate. >>> >>> I am relatively new to IEEE-754 and this area of the code so any comments would be appreciated. >>> >>> Thanks, >>> >>> Brian >>> >>> diff -r 1405ad6afb1e -r 36482ed9bb7e src/share/classes/sun/misc/FloatingDecimal.java >>> --- a/src/share/classes/sun/misc/FloatingDecimal.java Thu Feb 14 11:09:07 2013 -0800 >>> +++ b/src/share/classes/sun/misc/FloatingDecimal.java Thu Feb 14 16:47:53 2013 -0800 >> From dmitry.nadezhin at gmail.com Fri Feb 22 17:41:08 2013 From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin) Date: Fri, 22 Feb 2013 20:41:08 +0300 Subject: Withdraw: Review: 4396272 - Parsing doubles fails to follow IEEE for largest decimal that should yield 0 In-Reply-To: References: <4412AB7C-A91F-48A9-ACF2-3816480C28E1@oracle.com> Message-ID: Brian, Class FloatingDecimal contains both conversion from String to float/double and conversion from float/double to String. My change is in conversion from String to float/double. The methods if FloatingDecimal that implement this conversion are: static FloatingDecimal readJavaFormatString( String in ); double doubleValue(); float floatValue(); My change is in method doubleValue(). Class FormattedFloatingDecimal was forked from FloatingDecimal some time ago. This class is used only for conversion from String to float/double. The unused method readJavaFormatString( String in) was deleted from FormattedFloatingDecimal. Methods doubleValue() and floatValued() were not deleted, but they are never used in JDK code. So I think that the required change in FormattedFloatingDecimal is to delete methods doubleValue(), floatValue() and other unused methods and fields. Am I right ? -Dima On Fri, Feb 22, 2013 at 8:46 PM, Brian Burkhalter wrote: > Hello Dima, > > Yes that would be helpful and appreciated. There is another patch to the same files that I will be looking into, but the changes are disjoint so there should not be a significant merge issue. > > Thanks, > > Brian > > On Feb 21, 2013, at 7:27 PM, Dmitry Nadezhin wrote: > >> Do you want that I prepare this FloatingDecimal/FormattedFloatingDecimal patch ? >> >> -Dima >> >> On Fri, Feb 22, 2013 at 2:32 AM, Brian Burkhalter >> wrote: >>> I am withdrawing this patch for the time being as properly the changes should also go into the fork sun.misc.FormattedFloatingDecimal. I'll post an updated patch once it is available. >>> >>> Thanks, >>> >>> Brian >>> >>> On Feb 14, 2013, at 5:23 PM, Brian Burkhalter wrote: >>> >>>> The patch below is as submitted to OpenJDK bugzilla but with enhanced comments. It pertains to the correction loop in the doubleValue() method of FloatingDecimal. The situation appears to arise when the candidate value is less than 2*Double.MIN_NORMAL as for such values the ULP is less than 2*Double.MIN_VALUE so that the intermediate result 0.5*ULP is less than Double.MIN_VALUE which rounds to zero per FP-strict and the correction is therefore zero. Thus the candidate value is unchanged. The fix is to add the ULP to twice the candidate value, obtain the intermediate result, and then halve it to obtain the adjusted candidate. >>>> >>>> I am relatively new to IEEE-754 and this area of the code so any comments would be appreciated. >>>> >>>> Thanks, >>>> >>>> Brian >>>> >>>> diff -r 1405ad6afb1e -r 36482ed9bb7e src/share/classes/sun/misc/FloatingDecimal.java >>>> --- a/src/share/classes/sun/misc/FloatingDecimal.java Thu Feb 14 11:09:07 2013 -0800 >>>> +++ b/src/share/classes/sun/misc/FloatingDecimal.java Thu Feb 14 16:47:53 2013 -0800 >>> > From brian.burkhalter at oracle.com Fri Feb 22 17:49:08 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 22 Feb 2013 09:49:08 -0800 Subject: Withdraw: Review: 4396272 - Parsing doubles fails to follow IEEE for largest decimal that should yield 0 In-Reply-To: References: <4412AB7C-A91F-48A9-ACF2-3816480C28E1@oracle.com> Message-ID: Dima, If the methods are definitely unused that would be correct. I suppose if a clean build of the JDK does not complain then it is acceptable and correct. Thanks, Brian On Feb 22, 2013, at 9:41 AM, Dmitry Nadezhin wrote: > So I think that the required change in FormattedFloatingDecimal is to > delete methods > doubleValue(), floatValue() and other unused methods and fields. Am I right ? From naoto.sato at oracle.com Fri Feb 22 18:22:56 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 22 Feb 2013 10:22:56 -0800 Subject: RFR: 8006039 : test/tools/launcher/I18NJarTest.java fails on Mac w/ LANG=C, LC_ALL=C In-Reply-To: <5126BD1C.8030309@oracle.com> References: <5126BD1C.8030309@oracle.com> Message-ID: <5127B780.6090800@oracle.com> Hi Brent, I think the condition needs to check if it is on Unix environment, and check not only "C" but also other locales that do not use UTF-8 encoding. Also, "LC_ALL" precedes "LANG" environment variable, so I'd check "LC_ALL" first, and if it is not exported then check "LANG" variable. Naoto On 2/21/13 4:34 PM, Brent Christian wrote: > Hi, > > This test started failing after 8003228 [1] was putback (setting > sun.jnu.encoding to UTF-8 on Mac). It tests if java is able to launch a > .jar stored in a directory named with two-byte characters. > > The code comments in the test case state that (on Unix) it expects > LC_ALL to be set (to ja_JP.UTF-8/ja_JP.utf8/ja_JP.ujis), though it also > seems to work with en_US.UTF-8). > > Our automated build+test Macs have LANG=C, so the test has been > "passing" without actually testing the functionality. > > The test case determines if the environment is suitable for testing by > checking if sun.jnu.encoding is either "MS932" or "UTF-8" (on Mac, this > is now always UTF-8). The test doesn't actually check LC_ALL. > > I think the test should also check the LANG & LC_ALL env vars, and go > back to "fake passing" the test if either is set to 'C'. This would > allow the test to continue to run "for real" in the default Mac > environment (LANG=en_US.UTF-8), and stop the test from failing on the > build+test Macs. > > Of course it would be even better to update the test so the automated > test machines actually test the intended functionality. On UNIX at > least, perhaps it could find something suitable to set LC_ALL to before > attempting to launch the .jar. I can file a separate bug for this. > > Webrev is here: > http://cr.openjdk.java.net/~bchristi/8006039/webrev.00/ > > Thanks, > -Brent > > [1] > http://bugs.sun.com/view_bug.do?bug_id=8003228 From maurizio.cimadamore at oracle.com Fri Feb 22 18:20:20 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 22 Feb 2013 18:20:20 +0000 Subject: hg: jdk8/tl/langtools: 8008708: Regression: separate compilation causes crash in wildcards inference logic Message-ID: <20130222182026.6EB3347CC8@hg.openjdk.java.net> Changeset: 94e67bed460d Author: mcimadamore Date: 2013-02-22 18:19 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/94e67bed460d 8008708: Regression: separate compilation causes crash in wildcards inference logic Summary: Invalid use of WildcardType.bound in Types.removeWildcards Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/lambda/separate/Foo.java + test/tools/javac/lambda/separate/Test.java From joe.darcy at oracle.com Fri Feb 22 19:19:48 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 22 Feb 2013 11:19:48 -0800 Subject: 8008662: Add @jdk.Supported to JDK-specific/supported API In-Reply-To: References: <51266B7C.3040804@oracle.com> <5126D516.1040005@oracle.com> Message-ID: <5127C4D4.5090800@oracle.com> Hi Martin, On 2/22/2013 6:06 AM, Martin Buchholz wrote: > > > On Thu, Feb 21, 2013 at 6:16 PM, Joe Darcy > wrote: > > > However, the com.sun.* subpackages are a mix of APIs that are > supported as described above as well as APIs that are not supported. > > > I was under the impression that the general rule was that all of > com.sun.* fell under the "jdk supported" umbrella, and the level of > support was the distinction between sun.com.* and sun.* . Alan has previously replied on the varied supported-ness found in com.sun.*. > > In any case, it would be good if there was a single canonical place > that documented the various levels of support with subtle > distinctions, including java.* vs. javax.*, endorsed standards, > com.sun.* vs. sun.* vs. jdk.*, and recommendations for where > non-Oracle vendor extensions should go. Is the jdk.Supported > annotation itself part of Java SE? No, the jdk.Supported annotation type is part of the JDK (currently living in the langtools repo): http://hg.openjdk.java.net/jdk8/jdk8/langtools/file/56dfafbb9e1a/src/share/classes/jdk/Supported.java As you can see, the jdk.Supported type itself has a @jdk.Supported annotation :-) > Should third-party vendor extensions that are "supported" for public > use by the third-party use jdk.Supported? No; as I envision it, the jdk.Supported annotation is only meant to convey supported-ness in the JDK of parts of the JDK. > What about the X's in hotspot flags and the java tools command line > interfaces? The policy around command line interfaces is unchanged; the interfaces are mostly stable, but the more X's are in a flags name, the less stable it can be. -Joe From lowasser at google.com Fri Feb 22 19:23:23 2013 From: lowasser at google.com (Louis Wasserman) Date: Fri, 22 Feb 2013 11:23:23 -0800 Subject: [PATCH] Sunbug 7131192: Optimize BigInteger.doubleValue(), floatValue() In-Reply-To: <2867C9E8-F8FB-405A-8D00-7D4F90CA9628@oracle.com> References: <511ED22B.8030800@oracle.com> <2867C9E8-F8FB-405A-8D00-7D4F90CA9628@oracle.com> Message-ID: Sweet. Just be aware that the floatValue() optimization requires Float.parseFloat to be fixed to match IEEE 754 behavior, as you're apparently doing with Double.parseDouble, to pass tests. (The separate patch I sent in to fix that is probably invalidated by your changes, but it shouldn't be too difficult to do yourself -- it really is just copy/pasting the Double.parseDouble implementation and using updated constants.) On Thu, Feb 21, 2013 at 1:27 PM, Brian Burkhalter < brian.burkhalter at oracle.com> wrote: > My initial testing with another micro-benchmarking framework (other than > Caliper) shows a performance increase of >900X for doubleValue() and >1500X > for floatValue() on a MacBookPro5,3. > > There is some more evaluation yet to be done but we should be able to move > this patch along pretty soon. > > Brian > > On Feb 15, 2013, at 4:41 PM, Brian Burkhalter wrote: > > > Hi Louis, > > > > After the two issues for which I've posted review requests (6480539 - > stripTrailingZeros(), 4396272 - Parsing doubles fails to follow IEEE) are > resolved, issue 7131192 is currently very near the head of my queue. Given > that I still have a ways to go to get up to speed on this entire topic area > and code base, I would hesitate to give a date estimate just yet. > > > > Brian > > > >> Any update on when this could get reviewed? > >> > >> > >> On Thu, Dec 13, 2012 at 3:36 PM, Louis Wasserman > wrote: > >> Hi, > >> > >> I'm working at Google now, but I'd like to revive this patch as a > contribution from Google. At the moment, what's mainly needed is review > for http://bugs.sun.com/view_bug.do?bug_id=7192954, the fix to > Float.parseFloat's rounding behavior, before we can go anywhere with the > patch to optimize BigInteger.floatValue() and doubleValue(). > >> Would anyone be able to review that patch so these can start moving > forward? > >> > >> Thanks, > >> Louis Wasserman > >> Java Core Libraries Team @ Google > >> guava-libraries.googlecode.com > > -- Louis Wasserman From brian.burkhalter at oracle.com Fri Feb 22 19:33:47 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 22 Feb 2013 11:33:47 -0800 Subject: [PATCH] Sunbug 7131192: Optimize BigInteger.doubleValue(), floatValue() In-Reply-To: References: <511ED22B.8030800@oracle.com> <2867C9E8-F8FB-405A-8D00-7D4F90CA9628@oracle.com> Message-ID: <692B4DC6-88F3-4740-9B06-BDE56BB7B8B5@oracle.com> On Feb 22, 2013, at 11:23 AM, Louis Wasserman wrote: > Sweet. Just be aware that the floatValue() optimization requires Float.parseFloat to be fixed to match IEEE 754 behavior, as you're apparently doing with Double.parseDouble, to pass tests. Actually I missed that until yesterday but found it out myself. I do not think however that the patch for 7131192 necessarily has to precede the fix for 7192954, as long as the latter gets into the same release. > (The separate patch I sent in to fix that is probably invalidated by your changes, but it shouldn't be too difficult to do yourself -- it really is just copy/pasting the Double.parseDouble implementation and using updated constants.) Thanks for the pointer. As previously noted I am still trying to gain some traction in this area. Brian From brian.burkhalter at oracle.com Fri Feb 22 19:48:02 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 22 Feb 2013 11:48:02 -0800 Subject: [PATCH] Sunbug 7131192: Optimize BigInteger.doubleValue(), floatValue() In-Reply-To: <692B4DC6-88F3-4740-9B06-BDE56BB7B8B5@oracle.com> References: <511ED22B.8030800@oracle.com> <2867C9E8-F8FB-405A-8D00-7D4F90CA9628@oracle.com> <692B4DC6-88F3-4740-9B06-BDE56BB7B8B5@oracle.com> Message-ID: <370E52AA-385B-4117-B18E-71699243782F@oracle.com> On Feb 22, 2013, at 11:33 AM, Brian Burkhalter wrote: >> Sweet. Just be aware that the floatValue() optimization requires Float.parseFloat to be fixed to match IEEE 754 behavior, as you're apparently doing with Double.parseDouble, to pass tests. > > Actually I missed that until yesterday but found it out myself. I do not think however that the patch for 7131192 necessarily has to precede the fix for 7192954, as long as the latter gets into the same release. Oops, I had that reversed: I don't know that the patch for 7192954 has to precede that for 7131192 if the latter is deemed correct. B. From lowasser at google.com Fri Feb 22 20:10:41 2013 From: lowasser at google.com (Louis Wasserman) Date: Fri, 22 Feb 2013 12:10:41 -0800 Subject: [PATCH] Sunbug 7131192: Optimize BigInteger.doubleValue(), floatValue() In-Reply-To: <370E52AA-385B-4117-B18E-71699243782F@oracle.com> References: <511ED22B.8030800@oracle.com> <2867C9E8-F8FB-405A-8D00-7D4F90CA9628@oracle.com> <692B4DC6-88F3-4740-9B06-BDE56BB7B8B5@oracle.com> <370E52AA-385B-4117-B18E-71699243782F@oracle.com> Message-ID: It's up to you guys, probably. The issue is that the "reference implementation" being tested against is wrong, and which order you want to fix things is up to you guys. On Fri, Feb 22, 2013 at 11:48 AM, Brian Burkhalter < brian.burkhalter at oracle.com> wrote: > > On Feb 22, 2013, at 11:33 AM, Brian Burkhalter wrote: > > Sweet. Just be aware that the floatValue() optimization requires > Float.parseFloat to be fixed to match IEEE 754 behavior, as you're > apparently doing with Double.parseDouble, to pass tests. > > > Actually I missed that until yesterday but found it out myself. I do not > think however that the patch for 7131192 necessarily has to precede the fix > for 7192954, as long as the latter gets into the same release. > > > Oops, I had that reversed: I don't know that the patch for 7192954 has to > precede that for 7131192 if the latter is deemed correct. > > B. > -- Louis Wasserman From brian.burkhalter at oracle.com Fri Feb 22 20:12:05 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 22 Feb 2013 12:12:05 -0800 Subject: [PATCH] Sunbug 7131192: Optimize BigInteger.doubleValue(), floatValue() In-Reply-To: References: <511ED22B.8030800@oracle.com> <2867C9E8-F8FB-405A-8D00-7D4F90CA9628@oracle.com> <692B4DC6-88F3-4740-9B06-BDE56BB7B8B5@oracle.com> <370E52AA-385B-4117-B18E-71699243782F@oracle.com> Message-ID: On Feb 22, 2013, at 12:10 PM, Louis Wasserman wrote: > It's up to you guys, probably. The issue is that the "reference implementation" being tested against is wrong, Yes, I understand. > and which order you want to fix things is up to you guys. Brian From dmitry.nadezhin at gmail.com Fri Feb 22 20:29:49 2013 From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin) Date: Fri, 22 Feb 2013 23:29:49 +0300 Subject: Withdraw: Review: 4396272 - Parsing doubles fails to follow IEEE for largest decimal that should yield 0 In-Reply-To: References: <4412AB7C-A91F-48A9-ACF2-3816480C28E1@oracle.com> Message-ID: Brian, I removed unused methods and fields from FormattedFloatingDecimal. JDK build passes. The result of "hg diff" is attached. -Dima On Fri, Feb 22, 2013 at 9:49 PM, Brian Burkhalter wrote: > Dima, > > If the methods are definitely unused that would be correct. I suppose if a > clean build of the JDK does not complain then it is acceptable and correct. > > Thanks, > > Brian > > On Feb 22, 2013, at 9:41 AM, Dmitry Nadezhin wrote: > > So I think that the required change in FormattedFloatingDecimal is to > delete methods > doubleValue(), floatValue() and other unused methods and fields. Am I right > ? > > -------------- next part -------------- diff -r bb97c93e4fd7 src/share/classes/sun/misc/FormattedFloatingDecimal.java --- a/src/share/classes/sun/misc/FormattedFloatingDecimal.java Thu Feb 21 11:13:23 2013 -0800 +++ b/src/share/classes/sun/misc/FormattedFloatingDecimal.java Sat Feb 23 00:00:12 2013 +0400 @@ -25,10 +25,6 @@ package sun.misc; -import sun.misc.DoubleConsts; -import sun.misc.FloatConsts; -import java.util.regex.*; - public class FormattedFloatingDecimal{ boolean isExceptional; boolean isNegative; @@ -38,9 +34,6 @@ int nDigits; int bigIntExp; int bigIntNBits; - boolean mustSetRoundDir = false; - boolean fromHex = false; - int roundDir = 0; // set by doubleValue int precision; // number of digits to the right of decimal public enum Form { SCIENTIFIC, COMPATIBLE, DECIMAL_FLOAT, GENERAL }; @@ -72,10 +65,6 @@ static final long expOne = ((long)expBias)<>> expShift); - double ulpval; - if ( subtracting && ( binexp >= expShift ) && ((lbits&fractMask) == 0L) ){ - // for subtraction from normalized, powers of 2, - // use next-smaller exponent - binexp -= 1; - } - if ( binexp > expShift ){ - ulpval = Double.longBitsToDouble( ((long)(binexp-expShift))<= 0 ){ - if ( exp <= maxSmallTen ){ - /* - * Can get the answer with one operation, - * thus one roundoff. - */ - rValue = dValue * small10pow[exp]; - if ( mustSetRoundDir ){ - tValue = rValue / small10pow[exp]; - roundDir = ( tValue == dValue ) ? 0 - :( tValue < dValue ) ? 1 - : -1; - } - return (isNegative)? -rValue : rValue; - } - int slop = maxDecimalDigits - kDigits; - if ( exp <= maxSmallTen+slop ){ - /* - * We can multiply dValue by 10^(slop) - * and it is still "small" and exact. - * Then we can multiply by 10^(exp-slop) - * with one rounding. - */ - dValue *= small10pow[slop]; - rValue = dValue * small10pow[exp-slop]; - - if ( mustSetRoundDir ){ - tValue = rValue / small10pow[exp-slop]; - roundDir = ( tValue == dValue ) ? 0 - :( tValue < dValue ) ? 1 - : -1; - } - return (isNegative)? -rValue : rValue; - } - /* - * Else we have a hard case with a positive exp. - */ - } else { - if ( exp >= -maxSmallTen ){ - /* - * Can get the answer in one division. - */ - rValue = dValue / small10pow[-exp]; - tValue = rValue * small10pow[-exp]; - if ( mustSetRoundDir ){ - roundDir = ( tValue == dValue ) ? 0 - :( tValue < dValue ) ? 1 - : -1; - } - return (isNegative)? -rValue : rValue; - } - /* - * Else we have a hard case with a negative exp. - */ - } - } - - /* - * Harder cases: - * The sum of digits plus exponent is greater than - * what we think we can do with one error. - * - * Start by approximating the right answer by, - * naively, scaling by powers of 10. - */ - if ( exp > 0 ){ - if ( decExponent > maxDecimalExponent+1 ){ - /* - * Lets face it. This is going to be - * Infinity. Cut to the chase. - */ - return (isNegative)? Double.NEGATIVE_INFINITY : Double.POSITIVE_INFINITY; - } - if ( (exp&15) != 0 ){ - dValue *= small10pow[exp&15]; - } - if ( (exp>>=4) != 0 ){ - int j; - for( j = 0; exp > 1; j++, exp>>=1 ){ - if ( (exp&1)!=0) - dValue *= big10pow[j]; - } - /* - * The reason for the weird exp > 1 condition - * in the above loop was so that the last multiply - * would get unrolled. We handle it here. - * It could overflow. - */ - double t = dValue * big10pow[j]; - if ( Double.isInfinite( t ) ){ - /* - * It did overflow. - * Look more closely at the result. - * If the exponent is just one too large, - * then use the maximum finite as our estimate - * value. Else call the result infinity - * and punt it. - * ( I presume this could happen because - * rounding forces the result here to be - * an ULP or two larger than - * Double.MAX_VALUE ). - */ - t = dValue / 2.0; - t *= big10pow[j]; - if ( Double.isInfinite( t ) ){ - return (isNegative)? Double.NEGATIVE_INFINITY : Double.POSITIVE_INFINITY; - } - t = Double.MAX_VALUE; - } - dValue = t; - } - } else if ( exp < 0 ){ - exp = -exp; - if ( decExponent < minDecimalExponent-1 ){ - /* - * Lets face it. This is going to be - * zero. Cut to the chase. - */ - return (isNegative)? -0.0 : 0.0; - } - if ( (exp&15) != 0 ){ - dValue /= small10pow[exp&15]; - } - if ( (exp>>=4) != 0 ){ - int j; - for( j = 0; exp > 1; j++, exp>>=1 ){ - if ( (exp&1)!=0) - dValue *= tiny10pow[j]; - } - /* - * The reason for the weird exp > 1 condition - * in the above loop was so that the last multiply - * would get unrolled. We handle it here. - * It could underflow. - */ - double t = dValue * tiny10pow[j]; - if ( t == 0.0 ){ - /* - * It did underflow. - * Look more closely at the result. - * If the exponent is just one too small, - * then use the minimum finite as our estimate - * value. Else call the result 0.0 - * and punt it. - * ( I presume this could happen because - * rounding forces the result here to be - * an ULP or two less than - * Double.MIN_VALUE ). - */ - t = dValue * 2.0; - t *= tiny10pow[j]; - if ( t == 0.0 ){ - return (isNegative)? -0.0 : 0.0; - } - t = Double.MIN_VALUE; - } - dValue = t; - } - } - - /* - * dValue is now approximately the result. - * The hard part is adjusting it, by comparison - * with FDBigInt arithmetic. - * Formulate the EXACT big-number result as - * bigD0 * 10^exp - */ - FDBigInt bigD0 = new FDBigInt( lValue, digits, kDigits, nDigits ); - exp = decExponent - nDigits; - - correctionLoop: - while(true){ - /* AS A SIDE EFFECT, THIS METHOD WILL SET THE INSTANCE VARIABLES - * bigIntExp and bigIntNBits - */ - FDBigInt bigB = doubleToBigInt( dValue ); - - /* - * Scale bigD, bigB appropriately for - * big-integer operations. - * Naively, we multipy by powers of ten - * and powers of two. What we actually do - * is keep track of the powers of 5 and - * powers of 2 we would use, then factor out - * common divisors before doing the work. - */ - int B2, B5; // powers of 2, 5 in bigB - int D2, D5; // powers of 2, 5 in bigD - int Ulp2; // powers of 2 in halfUlp. - if ( exp >= 0 ){ - B2 = B5 = 0; - D2 = D5 = exp; - } else { - B2 = B5 = -exp; - D2 = D5 = 0; - } - if ( bigIntExp >= 0 ){ - B2 += bigIntExp; - } else { - D2 -= bigIntExp; - } - Ulp2 = B2; - // shift bigB and bigD left by a number s. t. - // halfUlp is still an integer. - int hulpbias; - if ( bigIntExp+bigIntNBits <= -expBias+1 ){ - // This is going to be a denormalized number - // (if not actually zero). - // half an ULP is at 2^-(expBias+expShift+1) - hulpbias = bigIntExp+ expBias + expShift; - } else { - hulpbias = expShift + 2 - bigIntNBits; - } - B2 += hulpbias; - D2 += hulpbias; - // if there are common factors of 2, we might just as well - // factor them out, as they add nothing useful. - int common2 = Math.min( B2, Math.min( D2, Ulp2 ) ); - B2 -= common2; - D2 -= common2; - Ulp2 -= common2; - // do multiplications by powers of 5 and 2 - bigB = multPow52( bigB, B5, B2 ); - FDBigInt bigD = multPow52( new FDBigInt( bigD0 ), D5, D2 ); - // - // to recap: - // bigB is the scaled-big-int version of our floating-point - // candidate. - // bigD is the scaled-big-int version of the exact value - // as we understand it. - // halfUlp is 1/2 an ulp of bigB, except for special cases - // of exact powers of 2 - // - // the plan is to compare bigB with bigD, and if the difference - // is less than halfUlp, then we're satisfied. Otherwise, - // use the ratio of difference to halfUlp to calculate a fudge - // factor to add to the floating value, then go 'round again. - // - FDBigInt diff; - int cmpResult; - boolean overvalue; - if ( (cmpResult = bigB.cmp( bigD ) ) > 0 ){ - overvalue = true; // our candidate is too big. - diff = bigB.sub( bigD ); - if ( (bigIntNBits == 1) && (bigIntExp > -expBias) ){ - // candidate is a normalized exact power of 2 and - // is too big. We will be subtracting. - // For our purposes, ulp is the ulp of the - // next smaller range. - Ulp2 -= 1; - if ( Ulp2 < 0 ){ - // rats. Cannot de-scale ulp this far. - // must scale diff in other direction. - Ulp2 = 0; - diff.lshiftMe( 1 ); - } - } - } else if ( cmpResult < 0 ){ - overvalue = false; // our candidate is too small. - diff = bigD.sub( bigB ); - } else { - // the candidate is exactly right! - // this happens with surprising fequency - break correctionLoop; - } - FDBigInt halfUlp = constructPow52( B5, Ulp2 ); - if ( (cmpResult = diff.cmp( halfUlp ) ) < 0 ){ - // difference is small. - // this is close enough - if (mustSetRoundDir) { - roundDir = overvalue ? -1 : 1; - } - break correctionLoop; - } else if ( cmpResult == 0 ){ - // difference is exactly half an ULP - // round to some other value maybe, then finish - dValue += 0.5*ulp( dValue, overvalue ); - // should check for bigIntNBits == 1 here?? - if (mustSetRoundDir) { - roundDir = overvalue ? -1 : 1; - } - break correctionLoop; - } else { - // difference is non-trivial. - // could scale addend by ratio of difference to - // halfUlp here, if we bothered to compute that difference. - // Most of the time ( I hope ) it is about 1 anyway. - dValue += ulp( dValue, overvalue ); - if ( dValue == 0.0 || dValue == Double.POSITIVE_INFINITY ) - break correctionLoop; // oops. Fell off end of range. - continue; // try again. - } - - } - return (isNegative)? -dValue : dValue; - } - } - - /* - * Take a FormattedFloatingDecimal, which we presumably just scanned in, - * and find out what its value is, as a float. - * This is distinct from doubleValue() to avoid the extremely - * unlikely case of a double rounding error, wherein the converstion - * to double has one rounding error, and the conversion of that double - * to a float has another rounding error, IN THE WRONG DIRECTION, - * ( because of the preference to a zero low-order bit ). - */ - - public strictfp float floatValue(){ - int kDigits = Math.min( nDigits, singleMaxDecimalDigits+1 ); - int iValue; - float fValue; - - // First, check for NaN and Infinity values - if(digits == infinity || digits == notANumber) { - if(digits == notANumber) - return Float.NaN; - else - return (isNegative?Float.NEGATIVE_INFINITY:Float.POSITIVE_INFINITY); - } - else { - /* - * convert the lead kDigits to an integer. - */ - iValue = (int)digits[0]-(int)'0'; - for ( int i=1; i < kDigits; i++ ){ - iValue = iValue*10 + (int)digits[i]-(int)'0'; - } - fValue = (float)iValue; - int exp = decExponent-kDigits; - /* - * iValue now contains an integer with the value of - * the first kDigits digits of the number. - * fValue contains the (float) of the same. - */ - - if ( nDigits <= singleMaxDecimalDigits ){ - /* - * possibly an easy case. - * We know that the digits can be represented - * exactly. And if the exponent isn't too outrageous, - * the whole thing can be done with one operation, - * thus one rounding error. - * Note that all our constructors trim all leading and - * trailing zeros, so simple values (including zero) - * will always end up here. - */ - if (exp == 0 || fValue == 0.0f) - return (isNegative)? -fValue : fValue; // small floating integer - else if ( exp >= 0 ){ - if ( exp <= singleMaxSmallTen ){ - /* - * Can get the answer with one operation, - * thus one roundoff. - */ - fValue *= singleSmall10pow[exp]; - return (isNegative)? -fValue : fValue; - } - int slop = singleMaxDecimalDigits - kDigits; - if ( exp <= singleMaxSmallTen+slop ){ - /* - * We can multiply dValue by 10^(slop) - * and it is still "small" and exact. - * Then we can multiply by 10^(exp-slop) - * with one rounding. - */ - fValue *= singleSmall10pow[slop]; - fValue *= singleSmall10pow[exp-slop]; - return (isNegative)? -fValue : fValue; - } - /* - * Else we have a hard case with a positive exp. - */ - } else { - if ( exp >= -singleMaxSmallTen ){ - /* - * Can get the answer in one division. - */ - fValue /= singleSmall10pow[-exp]; - return (isNegative)? -fValue : fValue; - } - /* - * Else we have a hard case with a negative exp. - */ - } - } else if ( (decExponent >= nDigits) && (nDigits+decExponent <= maxDecimalDigits) ){ - /* - * In double-precision, this is an exact floating integer. - * So we can compute to double, then shorten to float - * with one round, and get the right answer. - * - * First, finish accumulating digits. - * Then convert that integer to a double, multiply - * by the appropriate power of ten, and convert to float. - */ - long lValue = (long)iValue; - for ( int i=kDigits; i < nDigits; i++ ){ - lValue = lValue*10L + (long)((int)digits[i]-(int)'0'); - } - double dValue = (double)lValue; - exp = decExponent-nDigits; - dValue *= small10pow[exp]; - fValue = (float)dValue; - return (isNegative)? -fValue : fValue; - - } - /* - * Harder cases: - * The sum of digits plus exponent is greater than - * what we think we can do with one error. - * - * Start by weeding out obviously out-of-range - * results, then convert to double and go to - * common hard-case code. - */ - if ( decExponent > singleMaxDecimalExponent+1 ){ - /* - * Lets face it. This is going to be - * Infinity. Cut to the chase. - */ - return (isNegative)? Float.NEGATIVE_INFINITY : Float.POSITIVE_INFINITY; - } else if ( decExponent < singleMinDecimalExponent-1 ){ - /* - * Lets face it. This is going to be - * zero. Cut to the chase. - */ - return (isNegative)? -0.0f : 0.0f; - } - - /* - * Here, we do 'way too much work, but throwing away - * our partial results, and going and doing the whole - * thing as double, then throwing away half the bits that computes - * when we convert back to float. - * - * The alternative is to reproduce the whole multiple-precision - * algorythm for float precision, or to try to parameterize it - * for common usage. The former will take about 400 lines of code, - * and the latter I tried without success. Thus the semi-hack - * answer here. - */ - mustSetRoundDir = !fromHex; - double dValue = doubleValue(); - return stickyRound( dValue ); - } - } - - - /* - * All the positive powers of 10 that can be - * represented exactly in double/float. - */ - private static final double small10pow[] = { - 1.0e0, - 1.0e1, 1.0e2, 1.0e3, 1.0e4, 1.0e5, - 1.0e6, 1.0e7, 1.0e8, 1.0e9, 1.0e10, - 1.0e11, 1.0e12, 1.0e13, 1.0e14, 1.0e15, - 1.0e16, 1.0e17, 1.0e18, 1.0e19, 1.0e20, - 1.0e21, 1.0e22 - }; - - private static final float singleSmall10pow[] = { - 1.0e0f, - 1.0e1f, 1.0e2f, 1.0e3f, 1.0e4f, 1.0e5f, - 1.0e6f, 1.0e7f, 1.0e8f, 1.0e9f, 1.0e10f - }; - - private static final double big10pow[] = { - 1e16, 1e32, 1e64, 1e128, 1e256 }; - private static final double tiny10pow[] = { - 1e-16, 1e-32, 1e-64, 1e-128, 1e-256 }; - - private static final int maxSmallTen = small10pow.length-1; - private static final int singleMaxSmallTen = singleSmall10pow.length-1; - private static final int small5pow[] = { 1, 5, From brian.burkhalter at oracle.com Fri Feb 22 20:31:13 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 22 Feb 2013 12:31:13 -0800 Subject: Withdraw: Review: 4396272 - Parsing doubles fails to follow IEEE for largest decimal that should yield 0 In-Reply-To: References: <4412AB7C-A91F-48A9-ACF2-3816480C28E1@oracle.com> Message-ID: Dima, Great! Thanks. I will take a look later and re-post the review. Brian On Feb 22, 2013, at 12:29 PM, Dmitry Nadezhin wrote: > Brian, > > I removed unused methods and fields from FormattedFloatingDecimal. > JDK build passes. > The result of "hg diff" is attached. > > -Dima > > On Fri, Feb 22, 2013 at 9:49 PM, Brian Burkhalter > wrote: >> Dima, >> >> If the methods are definitely unused that would be correct. I suppose if a >> clean build of the JDK does not complain then it is acceptable and correct. >> >> Thanks, >> >> Brian >> >> On Feb 22, 2013, at 9:41 AM, Dmitry Nadezhin wrote: >> >> So I think that the required change in FormattedFloatingDecimal is to >> delete methods >> doubleValue(), floatValue() and other unused methods and fields. Am I right >> ? >> >> > From mike.duigou at oracle.com Fri Feb 22 21:25:50 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 22 Feb 2013 13:25:50 -0800 Subject: JDK RFR of 6556996: (ann spec) SuppressWarnings strings should be documented In-Reply-To: <5126CDE4.5050209@oracle.com> References: <5126CDE4.5050209@oracle.com> Message-ID: <0907D429-E546-4AF4-8047-589B46A6143C@oracle.com> looks good to me. Nice to see the JLS additions and good catch on the missing @since. On Feb 21 2013, at 17:46 , Joe Darcy wrote: > Hello, > > Please review the simple fix below for > > 6556996: (ann spec) SuppressWarnings strings should be documented > http://bugs.sun.com/view_bug.do?bug_id=6556996 > > the webrev is at > > http://cr.openjdk.java.net/~darcy/6556996.0/ > > and the patch is below. In brief, the only required string to be recognized in the SuppressWarnings annotation is "unchecked", which has been required by the JLS since Java SE 5. I made that adjustment to the documentation of the SuppressWarnings type. In addition, I added more @jls links relating the documentation of various annotation type to the JLS sections which discuss them. > > Thanks, > > -Joe > > --- old/src/share/classes/java/lang/Deprecated.java 2013-02-21 17:37:08.000000000 -0800 > +++ new/src/share/classes/java/lang/Deprecated.java 2013-02-21 17:37:08.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2010, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -36,6 +36,7 @@ > * > * @author Neal Gafter > * @since 1.5 > + * @jls 9.6.3.6 @Deprecated > */ > @Documented > @Retention(RetentionPolicy.RUNTIME) > --- old/src/share/classes/java/lang/Override.java 2013-02-21 17:37:09.000000000 -0800 > +++ new/src/share/classes/java/lang/Override.java 2013-02-21 17:37:09.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2011, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -43,7 +43,7 @@ > * > * @author Peter von der Ahé > * @author Joshua Bloch > - * @jls 9.6.1.4 Override > + * @jls 9.6.1.4 @Override > * @since 1.5 > */ > @Target(ElementType.METHOD) > --- old/src/share/classes/java/lang/SafeVarargs.java 2013-02-21 17:37:09.000000000 -0800 > +++ new/src/share/classes/java/lang/SafeVarargs.java 2013-02-21 17:37:09.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2010, 2011, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2010, 2013, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -85,6 +85,7 @@ > * @since 1.7 > * @jls 4.7 Reifiable Types > * @jls 8.4.1 Formal Parameters > + * @jls 9.6.3.7 @SafeVarargs > */ > @Documented > @Retention(RetentionPolicy.RUNTIME) > --- old/src/share/classes/java/lang/SuppressWarnings.java 2013-02-21 17:37:10.000000000 -0800 > +++ new/src/share/classes/java/lang/SuppressWarnings.java 2013-02-21 17:37:09.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2004, 2011, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -41,8 +41,11 @@ > * suppress a warning in a particular method, you should annotate that > * method rather than its class. > * > - * @since 1.5 > * @author Josh Bloch > + * @since 1.5 > + * @jls 5.1.9. Unchecked Conversion > + * @jls 5.5.2. Checked Casts and Unchecked Casts > + * @jls 9.6.3.5 @SuppressWarnings > */ > @Target({TYPE, FIELD, METHOD, PARAMETER, CONSTRUCTOR, LOCAL_VARIABLE}) > @Retention(RetentionPolicy.SOURCE) > @@ -56,9 +59,11 @@ > * free to emit a warning if an annotation contains an unrecognized > * warning name. > * > - *

Compiler vendors should document the warning names they support in > - * conjunction with this annotation type. They are encouraged to cooperate > - * to ensure that the same names work across multiple compilers. > + *

The string {@code "unchecked"} is used to suppress > + * unchecked warnings. Compiler vendors should document the > + * additional warning names they support in conjunction with this > + * annotation type. They are encouraged to cooperate to ensure > + * that the same names work across multiple compilers. > */ > String[] value(); > } > --- old/src/share/classes/java/lang/annotation/Inherited.java 2013-02-21 17:37:10.000000000 -0800 > +++ new/src/share/classes/java/lang/annotation/Inherited.java 2013-02-21 17:37:10.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2004, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -44,6 +44,7 @@ > * > * @author Joshua Bloch > * @since 1.5 > + * @jls 9.6.3.3 @Inherited > */ > @Documented > @Retention(RetentionPolicy.RUNTIME) > --- old/src/share/classes/java/lang/annotation/Retention.java 2013-02-21 17:37:11.000000000 -0800 > +++ new/src/share/classes/java/lang/annotation/Retention.java 2013-02-21 17:37:10.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2006, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -38,6 +38,7 @@ > * > * @author Joshua Bloch > * @since 1.5 > + * @jls 9.6.3.2 @Retention > */ > @Documented > @Retention(RetentionPolicy.RUNTIME) > --- old/src/share/classes/java/lang/annotation/Target.java 2013-02-21 17:37:11.000000000 -0800 > +++ new/src/share/classes/java/lang/annotation/Target.java 2013-02-21 17:37:11.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2004, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -59,6 +59,9 @@ > * ... > * } > * > + * > + * @since 1.5 > + * @jls 9.6.3.1 @Target > */ > @Documented > @Retention(RetentionPolicy.RUNTIME) > From bob.vandette at oracle.com Fri Feb 22 21:35:14 2013 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 22 Feb 2013 16:35:14 -0500 Subject: RFR: 8005545: Add System property to identify ARCH specific details such as ARM hard-float binaries In-Reply-To: <5D7CCEEA-EA5A-4D7C-833A-EB045ACF1AA9@oracle.com> References: <899E92AE-F8A0-4873-B8DC-EE642B615840@oracle.com> <51274F10.6020208@oracle.com> <5D7CCEEA-EA5A-4D7C-833A-EB045ACF1AA9@oracle.com> Message-ID: <3489CA98-1619-4C52-BBD0-E60AE42D1C44@oracle.com> Looks good to me. Bob. On Feb 22, 2013, at 4:33 PM, Vladimir Danushevsky wrote: > Thanks, webrev updated > http://cr.openjdk.java.net/~vladidan/8005545/webrev.01/ > > On Feb 22, 2013, at 5:57 AM, Alan Bateman wrote: > >> On 21/02/2013 22:02, Vladimir Danushevsky wrote: >>> : >>> >>> Webrev: >>> http://cr.openjdk.java.net/~vladidan/8005545/webrev.00/ >>> >>> Separate change to the build script (e.g. in ARM Hard-Float ABI case): >>> setenv ARCHABIPROPNAME gnueabihf >>> -DARCHABIPROPNAME="\"$(ARCHABIPROPNAME)\"" is passed to the CFLAGS >>> >> I agree with Bob on the naming, otherwise it looks okay to me. >> >> On the release file and Images.gmk then jdk/tl was sync'ed up yesterday so you will probably need to re-base the patch. >> >> -Alan > From martinrb at google.com Fri Feb 22 21:40:09 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 22 Feb 2013 13:40:09 -0800 Subject: 8008662: Add @jdk.Supported to JDK-specific/supported API In-Reply-To: <5127C4D4.5090800@oracle.com> References: <51266B7C.3040804@oracle.com> <5126D516.1040005@oracle.com> <5127C4D4.5090800@oracle.com> Message-ID: Hi Joe, On Fri, Feb 22, 2013 at 11:19 AM, Joe Darcy wrote: > > Should third-party vendor extensions that are "supported" for public use > by the third-party use jdk.Supported? > > > No; as I envision it, the jdk.Supported annotation is only meant to convey > supported-ness in the JDK of parts of the JDK. > > Depends on what you mean by "JDK". Suppose the icedtea project added a public "supported" method usesSystemZlib(). It would be good to provide guidance what package to put this in (org.classpath.* ?) and how to indicate level of support (by the icedtea project). Suppose the IcedTea project decided to officially support sun.misc.Unsafe. Would they do this by adding jdk.Supported annotation to their version of Unsafe.java, even if their upstream chose not to? What about the X's in hotspot flags and the java tools command line interfaces? > > The policy around command line interfaces is unchanged; the interfaces are > mostly stable, but the more X's are in a flags name, the less stable it can > be. > We all learned this by indoctrination from the local sensei greybeard, but where is it documented for the wider world? Perhaps Supported isn't a binary thing, but needs to capture different levels of support? Solaris has had such support levels. A "beta" ("laba", "experimental") support level is very useful for introducing new technology. It's a very hard problem, especially in a 1000 flowers world. From martinrb at google.com Fri Feb 22 22:03:23 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 22 Feb 2013 14:03:23 -0800 Subject: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so Message-ID: Hi Alan, Xueming, build-ers, I'd like you to do a code review. I've finally figured out why fastdebug jdk occasionally gives InternalError in the zip code. Exception in thread "main" java.lang.InternalError at java.util.zip.Inflater.init(Native Method) at java.util.zip.Inflater.(Inflater.java:101) at java.util.zip.ZipFile.getInflater(ZipFile.java:448) It's because: - jdk changed structure size of z_stream struct - making jdk zlib incompatible with stock zlib - as a result of which, it is imperative to keep jdk zlib sequestered from system zlib - so need to not export zlib symbols from libzip.so - so need to tell makefiles to use linker script unconditionally http://cr.openjdk.java.net/~martin/webrevs/openjdk8/hide-zlib/ From joe.darcy at oracle.com Fri Feb 22 22:09:18 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 22 Feb 2013 14:09:18 -0800 Subject: 8008662: Add @jdk.Supported to JDK-specific/supported API In-Reply-To: References: <51266B7C.3040804@oracle.com> <5126D516.1040005@oracle.com> <5127C4D4.5090800@oracle.com> Message-ID: <5127EC8E.4040608@oracle.com> Hi Martin, On 2/22/2013 1:40 PM, Martin Buchholz wrote: > Hi Joe, > > On Fri, Feb 22, 2013 at 11:19 AM, Joe Darcy > wrote: > > >> Should third-party vendor extensions that are "supported" for >> public use by the third-party use jdk.Supported? > > No; as I envision it, the jdk.Supported annotation is only meant > to convey supported-ness in the JDK of parts of the JDK. > > > Depends on what you mean by "JDK". Suppose the icedtea project added > a public "supported" method usesSystemZlib(). It would be good to > provide guidance what package to put this in (org.classpath.* ?) and > how to indicate level of support (by the icedtea project). > > Suppose the IcedTea project decided to officially support > sun.misc.Unsafe. Would they do this by adding jdk.Supported > annotation to their version of Unsafe.java, even if their upstream > chose not to? For some definition of "JDK", IcedTea is "JDK" too since they provide a JDK distribution, one at least a little distinct from plain OpenJDK and also distinct from OracleJDK. The long-standing problem I wanted to address was clearly indicating whether or not the upstream code in shared JDK 8 sources was regarded as a public API or not. So I don't think it would necessarily be inappropriate for a hypothetical org.classpath type to use jdk.Supported, but I wasn't really thinking about that use case. > > What about the X's in hotspot flags and the java tools command line > interfaces? > > > The policy around command line interfaces is unchanged; the > interfaces are mostly stable, but the more X's are in a flags > name, the less stable it can be. > > > We all learned this by indoctrination from the local sensei greybeard, > but where is it documented for the wider world? There is some approximation to that guidance in the java man page; options without a "X" prefix are described as "standard" and ones with at least one "X" are described as "non-standard." Not all XX options are included in the man page. > > Perhaps Supported isn't a binary thing, but needs to capture different > levels of support? > Solaris has had such support levels. > A "beta" ("laba", "experimental") support level is very useful for > introducing new technology. > > It's a very hard problem, especially in a 1000 flowers world. Yes, I'm vaguely aware that Solaris has had a rich taxonomy in this space and there are, IIRC, dtrace tools to audit if you are calling any sufficient unapproved APIs. However, at least as a first cut, I think a binary supported / not-supported distinction captures at least 80% of the distinction that needs to be made for the purposes of the JDK. Anything more involves much less favorable complexity vs benefit trade-offs. -Joe From xueming.shen at oracle.com Fri Feb 22 22:15:48 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 22 Feb 2013 14:15:48 -0800 Subject: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so In-Reply-To: References: Message-ID: <5127EE14.5010608@oracle.com> Here is the bugid you will need. 8008759: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so On 02/22/2013 02:03 PM, Martin Buchholz wrote: > Hi Alan, Xueming, build-ers, > > I'd like you to do a code review. > > I've finally figured out why fastdebug jdk occasionally gives InternalError in the zip code. > > Exception in thread "main" java.lang.InternalError > at java.util.zip.Inflater.init(Native Method) > at java.util.zip.Inflater.(Inflater.java:101) > at java.util.zip.ZipFile.getInflater(ZipFile.java:448) > > It's because: > - jdk changed structure size of z_stream struct > - making jdk zlib incompatible with stock zlib > - as a result of which, it is imperative to keep jdk zlib sequestered from system zlib > - so need to not export zlib symbols from libzip.so > - so need to tell makefiles to use linker script unconditionally > > http://cr.openjdk.java.net/~martin/webrevs/openjdk8/hide-zlib/ > From martinrb at google.com Fri Feb 22 22:29:36 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 22 Feb 2013 14:29:36 -0800 Subject: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so In-Reply-To: <5127EE14.5010608@oracle.com> References: <5127EE14.5010608@oracle.com> Message-ID: On Fri, Feb 22, 2013 at 2:15 PM, Xueming Shen wrote: > ** > Here is the bugid you will need. > > 8008759: Do not let internal JDK zlib symbols leak out of fastdebug > libzip.so > > Thanks! webrev updated. From mark.reinhold at oracle.com Fri Feb 22 23:04:26 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 22 Feb 2013 15:04:26 -0800 Subject: @Supported design issues References: <51266B7C.3040804@oracle.com>, <5126D516.1040005@oracle.com>, , <5127C4D4.5090800@oracle.com>, Message-ID: <20130222150427.1712@eggemoggin.niobe.net> I understand (deeply!) the problem that @Supported is trying to solve. Martin has raised a number of good questions about it already. Here are some additional concerns I'd like to see addressed before we use it any further in our source code. (I've been unable to find any earlier discussion or code review of this new annotation in the archives, but maybe I missed it.) - 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? - Is the "supportedness" of a package inherited by its sub-packages? - The name "Supported" is problematic. It begs the question, "Supported by whom?" Maybe the annotation should take URL and phone-number parameters so that you know where to go when you run into a problem? A name that captures a more inherent property of the API unit being annotated would avoid this. Perhaps "@Stable"? - 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. I'm not saying we should replicate all the detail of the Solaris stability taxonomy [1], but we should at least discuss whether it's worth doing something along those lines, if simpler. I think it'd be particularly valuable to be able to distinguish between at least four levels: - Supported and stable (i.e., will only evolve compatibly) until we tell you it's going to go away (or change incompatibly), and we'll give you at least one feature-release cycle's notice. - Supported in this feature release, but it might go away or change incompatibly in the next, with best-effort notice. - Supported in this update release, but evolving rapidly, with changes announced only in release notes. - Internal to the JDK, expect to get burned if you use it. 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. - The retention policy of the annotation is RUNTIME. Is that really what we want? I'd have expected CLASS. - 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. Finally, this annotation is intended for use throughout our code base, and will be of interest not just to people working on the JDK but also to people using it. Its syntax, semantics, and intended usage should hence be documented in a JEP, which will be much more visible than an obscure Javadoc page. - Mark [1] http://docs.oracle.com/cd/E19082-01/819-3620/chp-stab-1/index.html From martinrb at google.com Fri Feb 22 23:42:11 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 22 Feb 2013 15:42:11 -0800 Subject: @Supported design issues In-Reply-To: <20130222150427.1712@eggemoggin.niobe.net> References: <51266B7C.3040804@oracle.com> <5126D516.1040005@oracle.com> <5127C4D4.5090800@oracle.com> <20130222150427.1712@eggemoggin.niobe.net> Message-ID: One more thought. @Supported has RUNTIME retention, and it will be inevitable that some people will check the annotation at runtime. As a practical matter, once the annotation is added, it will never be removed (or removed only if the corresponding API is itself removed), (for fear of breaking someone), including by third parties like IcedTea. From brent.christian at oracle.com Fri Feb 22 23:56:56 2013 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 22 Feb 2013 15:56:56 -0800 Subject: RFR: 8006039 : test/tools/launcher/I18NJarTest.java fails on Mac w/ LANG=C, LC_ALL=C In-Reply-To: <5126E713.9090505@oracle.com> References: <5126BD1C.8030309@oracle.com> <5126E713.9090505@oracle.com> Message-ID: <512805C8.3070200@oracle.com> On 2/21/13 7:33 PM, Kumar Srinivasan wrote: > > A nit > - " LC_ALL" + LC_ALL + "\n" + > + " LC_ALL=" + LC_ALL + "\n" + Done, thanks. > If Mac is the only system affected by this, should we make the checks for > LC* and LANG specific to Macs since other platforms don't have this issue ? > I am concerned this might pass vacuously on systems configured correctly. LANG/LC_ALL=C is not a correct configuration for running this test. It ought to pass vacuously in this case (and does, AFAIK, on other platforms). What is Mac-specific is that sun.jnu.encoding is now always set to UTF-8, even under LANG/LC_ALL=C. The test sees this, and tries (and fails) to run the "real" test instead of passing vacuously. I don't think it does any harm to check for LANG/LC_ALL != 'C' on other platforms. But it's only on Mac that it's required in order to detect a mis-configured test environment. >> Of course it would be even better to update the test so the automated >> test machines actually test the intended functionality. >> ... >> I can file a separate bug for this. I've filed 8008761 (test/tools/launcher/I18NJarTest.java should automatically setup its environment) to cover this. To be clear, my short-term goal is to take I18NJarTest back off the ProblemList. The test does correctly test the intended functionality under the default Mac environment (LANG=en_US.UTF-8). So I want to get it running again for engineers using the "jdk_tools" test target on their local Mac (without causing nightly test failure noise). Later, as time permits, I can tackle 8008761, and get the test to configure its own environment. Thanks, -Brent From jeroen at sumatra.nl Sat Feb 23 07:45:42 2013 From: jeroen at sumatra.nl (Jeroen Frijters) Date: Sat, 23 Feb 2013 07:45:42 +0000 Subject: @Supported design issues In-Reply-To: References: <51266B7C.3040804@oracle.com> <5126D516.1040005@oracle.com> <5127C4D4.5090800@oracle.com> <20130222150427.1712@eggemoggin.niobe.net> Message-ID: I agree, but at the same time CLASS retention is really the worst of both worlds in my opinion. It doesn't have any (convenient) runtime benefit, but you can be sure that someone will depend on it at runtime by parsing the class files (this happens surprisingly often). I'd really like to see this be SOURCE initially and only after it is well understood, move it to RUNTIME in some future version of the platform (and then make it a public API instead of a jdk specific thing). 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 Martin Buchholz > Sent: Saturday, February 23, 2013 0:42 > To: mark.reinhold at oracle.com > Cc: core-libs-dev at openjdk.java.net > Subject: Re: @Supported design issues > > One more thought. @Supported has RUNTIME retention, and it will be > inevitable that some people will check the annotation at runtime. As a > practical matter, once the annotation is added, it will never be removed > (or removed only if the corresponding API is itself removed), (for fear > of breaking someone), including by third parties like IcedTea. From chris.hegarty at oracle.com Sat Feb 23 08:48:48 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 23 Feb 2013 08:48:48 +0000 Subject: JDK RFR of 6556996: (ann spec) SuppressWarnings strings should be documented In-Reply-To: <0907D429-E546-4AF4-8047-589B46A6143C@oracle.com> References: <5126CDE4.5050209@oracle.com> <0907D429-E546-4AF4-8047-589B46A6143C@oracle.com> Message-ID: <51288270.8030808@oracle.com> On 02/22/2013 09:25 PM, Mike Duigou wrote: > looks good to me. Nice to see the JLS additions and good catch on the missing @since. +1. -Chris. > > On Feb 21 2013, at 17:46 , Joe Darcy wrote: > >> Hello, >> >> Please review the simple fix below for >> >> 6556996: (ann spec) SuppressWarnings strings should be documented >> http://bugs.sun.com/view_bug.do?bug_id=6556996 >> >> the webrev is at >> >> http://cr.openjdk.java.net/~darcy/6556996.0/ >> >> and the patch is below. In brief, the only required string to be recognized in the SuppressWarnings annotation is "unchecked", which has been required by the JLS since Java SE 5. I made that adjustment to the documentation of the SuppressWarnings type. In addition, I added more @jls links relating the documentation of various annotation type to the JLS sections which discuss them. >> >> Thanks, >> >> -Joe >> >> --- old/src/share/classes/java/lang/Deprecated.java 2013-02-21 17:37:08.000000000 -0800 >> +++ new/src/share/classes/java/lang/Deprecated.java 2013-02-21 17:37:08.000000000 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2003, 2010, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -36,6 +36,7 @@ >> * >> * @author Neal Gafter >> * @since 1.5 >> + * @jls 9.6.3.6 @Deprecated >> */ >> @Documented >> @Retention(RetentionPolicy.RUNTIME) >> --- old/src/share/classes/java/lang/Override.java 2013-02-21 17:37:09.000000000 -0800 >> +++ new/src/share/classes/java/lang/Override.java 2013-02-21 17:37:09.000000000 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2003, 2011, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -43,7 +43,7 @@ >> * >> * @author Peter von der Ahé >> * @author Joshua Bloch >> - * @jls 9.6.1.4 Override >> + * @jls 9.6.1.4 @Override >> * @since 1.5 >> */ >> @Target(ElementType.METHOD) >> --- old/src/share/classes/java/lang/SafeVarargs.java 2013-02-21 17:37:09.000000000 -0800 >> +++ new/src/share/classes/java/lang/SafeVarargs.java 2013-02-21 17:37:09.000000000 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2010, 2011, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2010, 2013, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -85,6 +85,7 @@ >> * @since 1.7 >> * @jls 4.7 Reifiable Types >> * @jls 8.4.1 Formal Parameters >> + * @jls 9.6.3.7 @SafeVarargs >> */ >> @Documented >> @Retention(RetentionPolicy.RUNTIME) >> --- old/src/share/classes/java/lang/SuppressWarnings.java 2013-02-21 17:37:10.000000000 -0800 >> +++ new/src/share/classes/java/lang/SuppressWarnings.java 2013-02-21 17:37:09.000000000 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2004, 2011, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -41,8 +41,11 @@ >> * suppress a warning in a particular method, you should annotate that >> * method rather than its class. >> * >> - * @since 1.5 >> * @author Josh Bloch >> + * @since 1.5 >> + * @jls 5.1.9. Unchecked Conversion >> + * @jls 5.5.2. Checked Casts and Unchecked Casts >> + * @jls 9.6.3.5 @SuppressWarnings >> */ >> @Target({TYPE, FIELD, METHOD, PARAMETER, CONSTRUCTOR, LOCAL_VARIABLE}) >> @Retention(RetentionPolicy.SOURCE) >> @@ -56,9 +59,11 @@ >> * free to emit a warning if an annotation contains an unrecognized >> * warning name. >> * >> - *

Compiler vendors should document the warning names they support in >> - * conjunction with this annotation type. They are encouraged to cooperate >> - * to ensure that the same names work across multiple compilers. >> + *

The string {@code "unchecked"} is used to suppress >> + * unchecked warnings. Compiler vendors should document the >> + * additional warning names they support in conjunction with this >> + * annotation type. They are encouraged to cooperate to ensure >> + * that the same names work across multiple compilers. >> */ >> String[] value(); >> } >> --- old/src/share/classes/java/lang/annotation/Inherited.java 2013-02-21 17:37:10.000000000 -0800 >> +++ new/src/share/classes/java/lang/annotation/Inherited.java 2013-02-21 17:37:10.000000000 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2003, 2004, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -44,6 +44,7 @@ >> * >> * @author Joshua Bloch >> * @since 1.5 >> + * @jls 9.6.3.3 @Inherited >> */ >> @Documented >> @Retention(RetentionPolicy.RUNTIME) >> --- old/src/share/classes/java/lang/annotation/Retention.java 2013-02-21 17:37:11.000000000 -0800 >> +++ new/src/share/classes/java/lang/annotation/Retention.java 2013-02-21 17:37:10.000000000 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2003, 2006, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -38,6 +38,7 @@ >> * >> * @author Joshua Bloch >> * @since 1.5 >> + * @jls 9.6.3.2 @Retention >> */ >> @Documented >> @Retention(RetentionPolicy.RUNTIME) >> --- old/src/share/classes/java/lang/annotation/Target.java 2013-02-21 17:37:11.000000000 -0800 >> +++ new/src/share/classes/java/lang/annotation/Target.java 2013-02-21 17:37:11.000000000 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2003, 2004, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -59,6 +59,9 @@ >> * ... >> * } >> * >> + * >> + * @since 1.5 >> + * @jls 9.6.3.1 @Target >> */ >> @Documented >> @Retention(RetentionPolicy.RUNTIME) >> > From forax at univ-mlv.fr Sat Feb 23 09:25:03 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 23 Feb 2013 10:25:03 +0100 Subject: JDK RFR of 6556996: (ann spec) SuppressWarnings strings should be documented In-Reply-To: <5126CDE4.5050209@oracle.com> References: <5126CDE4.5050209@oracle.com> Message-ID: <51288AEF.5080708@univ-mlv.fr> On 02/22/2013 02:46 AM, Joe Darcy wrote: > Hello, > > Please review the simple fix below for > > 6556996: (ann spec) SuppressWarnings strings should be documented > http://bugs.sun.com/view_bug.do?bug_id=6556996 > > the webrev is at > > http://cr.openjdk.java.net/~darcy/6556996.0/ > > and the patch is below. In brief, the only required string to be > recognized in the SuppressWarnings annotation is "unchecked", which > has been required by the JLS since Java SE 5. I made that adjustment > to the documentation of the SuppressWarnings type. In addition, I > added more @jls links relating the documentation of various annotation > type to the JLS sections which discuss them. > > Thanks, > > -Joe Like the original submitter of the bug, I think that several other strings (at least rawtypes, varargs, deprecation, serial) should be documented with an explicit comment saying that they are not part of the specification. Those flags are way too common to not be documented in the API. R?mi > > --- old/src/share/classes/java/lang/Deprecated.java 2013-02-21 > 17:37:08.000000000 -0800 > +++ new/src/share/classes/java/lang/Deprecated.java 2013-02-21 > 17:37:08.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2010, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -36,6 +36,7 @@ > * > * @author Neal Gafter > * @since 1.5 > + * @jls 9.6.3.6 @Deprecated > */ > @Documented > @Retention(RetentionPolicy.RUNTIME) > --- old/src/share/classes/java/lang/Override.java 2013-02-21 > 17:37:09.000000000 -0800 > +++ new/src/share/classes/java/lang/Override.java 2013-02-21 > 17:37:09.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2011, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -43,7 +43,7 @@ > * > * @author Peter von der Ahé > * @author Joshua Bloch > - * @jls 9.6.1.4 Override > + * @jls 9.6.1.4 @Override > * @since 1.5 > */ > @Target(ElementType.METHOD) > --- old/src/share/classes/java/lang/SafeVarargs.java 2013-02-21 > 17:37:09.000000000 -0800 > +++ new/src/share/classes/java/lang/SafeVarargs.java 2013-02-21 > 17:37:09.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2010, 2011, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2010, 2013, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -85,6 +85,7 @@ > * @since 1.7 > * @jls 4.7 Reifiable Types > * @jls 8.4.1 Formal Parameters > + * @jls 9.6.3.7 @SafeVarargs > */ > @Documented > @Retention(RetentionPolicy.RUNTIME) > --- old/src/share/classes/java/lang/SuppressWarnings.java 2013-02-21 > 17:37:10.000000000 -0800 > +++ new/src/share/classes/java/lang/SuppressWarnings.java 2013-02-21 > 17:37:09.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2004, 2011, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -41,8 +41,11 @@ > * suppress a warning in a particular method, you should annotate that > * method rather than its class. > * > - * @since 1.5 > * @author Josh Bloch > + * @since 1.5 > + * @jls 5.1.9. Unchecked Conversion > + * @jls 5.5.2. Checked Casts and Unchecked Casts > + * @jls 9.6.3.5 @SuppressWarnings > */ > @Target({TYPE, FIELD, METHOD, PARAMETER, CONSTRUCTOR, LOCAL_VARIABLE}) > @Retention(RetentionPolicy.SOURCE) > @@ -56,9 +59,11 @@ > * free to emit a warning if an annotation contains an unrecognized > * warning name. > * > - *

Compiler vendors should document the warning names they > support in > - * conjunction with this annotation type. They are encouraged to > cooperate > - * to ensure that the same names work across multiple compilers. > + *

The string {@code "unchecked"} is used to suppress > + * unchecked warnings. Compiler vendors should document the > + * additional warning names they support in conjunction with this > + * annotation type. They are encouraged to cooperate to ensure > + * that the same names work across multiple compilers. > */ > String[] value(); > } > --- old/src/share/classes/java/lang/annotation/Inherited.java > 2013-02-21 17:37:10.000000000 -0800 > +++ new/src/share/classes/java/lang/annotation/Inherited.java > 2013-02-21 17:37:10.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2004, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -44,6 +44,7 @@ > * > * @author Joshua Bloch > * @since 1.5 > + * @jls 9.6.3.3 @Inherited > */ > @Documented > @Retention(RetentionPolicy.RUNTIME) > --- old/src/share/classes/java/lang/annotation/Retention.java > 2013-02-21 17:37:11.000000000 -0800 > +++ new/src/share/classes/java/lang/annotation/Retention.java > 2013-02-21 17:37:10.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2006, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -38,6 +38,7 @@ > * > * @author Joshua Bloch > * @since 1.5 > + * @jls 9.6.3.2 @Retention > */ > @Documented > @Retention(RetentionPolicy.RUNTIME) > --- old/src/share/classes/java/lang/annotation/Target.java 2013-02-21 > 17:37:11.000000000 -0800 > +++ new/src/share/classes/java/lang/annotation/Target.java 2013-02-21 > 17:37:11.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2004, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -59,6 +59,9 @@ > * ... > * } > * > + * > + * @since 1.5 > + * @jls 9.6.3.1 @Target > */ > @Documented > @Retention(RetentionPolicy.RUNTIME) > From forax at univ-mlv.fr Sat Feb 23 10:51:41 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 23 Feb 2013 11:51:41 +0100 Subject: Code review request In-Reply-To: <512672E6.1050708@oracle.com> References: <512672E6.1050708@oracle.com> Message-ID: <51289F3D.1010609@univ-mlv.fr> On 02/21/2013 08:17 PM, Brian Goetz wrote: > At > http://cr.openjdk.java.net/~briangoetz/jdk-8008670/webrev/ > > I've posted a webrev for about half the classes in java.util.stream. > None of these are public classes, so there are no public API issues > here, but plenty of internal API issues, naming issues (ooh, a > bikeshed), and code quality issues. > Hi Brian, All protected fields should not be protected but package visible. Classes are package private so there is no need to use a modifier which offer a wider visibility. The same is true for constructors. For default method, some of them are marked public, some of them are not, what the coding convention said ? Code convention again, there is a lot of if/else with no curly braces, or only curly braces on the if part but not on the else part. Also, when a if block ends with a return, there is no need to use 'else', if (result != null) { foundResult(result); return result; } else return null; can be simply written: if (result != null) { foundResult(result); return result; } return null; All inner class should not have private constructors, like by example FindOp.FindTask, because the compiler will have to generate a special accessor for them when they are called from the outer class. In AbstractShortCircuitTask: It's not clear that cancel and sharedResult can be accessed directly given that they both have methods that acts as getter and setter. If they can be accessed directly, I think it's better to declare them private and to use getters. Depending on the ops, some of them do nullcheks of arguments at creating time (ForEachOp) , some of them don't (FindOp). In ForEachUntilOp, the 'consumer' is checked but 'until' is not. in ForEachOp, most of the keyword protected are not needed, ForEachUntilOp which inherits from ForEachOp is in the same package. In ForEachUntilOp, the constructor should be private (like for all the other ops). In MatchOp, line 110, I think the compiler bug is fixed now ? The enum MatchKind should not be public and all constructor of all inner classes should not be private. In OpsUtils, some static methods are public and some are not, in Tripwire: enabled should be in uppercase (ENABLED). method trip() should be: public static void trip(Class trippingClass, String msg) cheers, R?mi From Alan.Bateman at oracle.com Sat Feb 23 11:51:31 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 23 Feb 2013 11:51:31 +0000 Subject: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so In-Reply-To: References: Message-ID: <5128AD43.2000809@oracle.com> On 22/02/2013 22:03, Martin Buchholz wrote: > Hi Alan, Xueming, build-ers, > > I'd like you to do a code review. > > I've finally figured out why fastdebug jdk occasionally gives > InternalError in the zip code. > > Exception in thread "main" java.lang.InternalError > at java.util.zip.Inflater.init(Native Method) > at java.util.zip.Inflater.(Inflater.java:101) > at java.util.zip.ZipFile.getInflater(ZipFile.java:448) > > It's because: > - jdk changed structure size of z_stream struct > - making jdk zlib incompatible with stock zlib > - as a result of which, it is imperative to keep jdk zlib sequestered > from system zlib > - so need to not export zlib symbols from libzip.so > - so need to tell makefiles to use linker script unconditionally > > http://cr.openjdk.java.net/~martin/webrevs/openjdk8/hide-zlib/ > > I see Sherman has created a bug for this but it turns out that someone else running with fastdebug ran into issues too: 8006319: fastdebug libzip.so is linked with global symbols, allowing symbols to be overridden I see you are proposing to update make/java/zip/Makefile so that is the old build. Looking at makefiles/CompileNativeLibraries.gmk (new build) then it looks to me that it is using the map file. I haven't checking the symbols in a fast debug build to double check so I'm curious if you've seen this with a recent (new) build. -Alan. From Alan.Bateman at oracle.com Sat Feb 23 12:04:47 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 23 Feb 2013 12:04:47 +0000 Subject: RFR: 8005545: Add System property to identify ARCH specific details such as ARM hard-float binaries In-Reply-To: <5D7CCEEA-EA5A-4D7C-833A-EB045ACF1AA9@oracle.com> References: <899E92AE-F8A0-4873-B8DC-EE642B615840@oracle.com> <51274F10.6020208@oracle.com> <5D7CCEEA-EA5A-4D7C-833A-EB045ACF1AA9@oracle.com> Message-ID: <5128B05F.6090900@oracle.com> On 22/02/2013 21:33, Vladimir Danushevsky wrote: > Thanks, webrev updated > http://cr.openjdk.java.net/~vladidan/8005545/webrev.01/ > > This looks good to me too. -Alan From martinrb at google.com Sat Feb 23 18:06:35 2013 From: martinrb at google.com (Martin Buchholz) Date: Sat, 23 Feb 2013 10:06:35 -0800 Subject: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so In-Reply-To: <5128AD43.2000809@oracle.com> References: <5128AD43.2000809@oracle.com> Message-ID: I am actually encountering this in openjdk7 with the old build system. I can repro the problem in openjdk8 with the old build system, but not the new one. I don't know if you consider this a bug with the new build system - it's supposed to generate the same bits, after all???!! I'm not sure why - I'd guess something to do with VARIANT or FILES_m It's highly dubious whether we should have this extremely subtle and error-prone distinction between release and fastdebug builds at all. Consider fixing this more fundamentally in Mapfile-vers.gmk, or at least document clearly why mapfiles are only on in OPT, and what the consequences might be. ifeq ($(PLATFORM), linux) ifeq ($(VARIANT), OPT) # OPT build MUST have a mapfile? ifndef FILES_m FILES_m = mapfile-vers endif endif # VARIANT Here's a repro recipe on Ubuntu Linux, running javac on any old source file: env LD_PRELOAD="/usr/lib/x86_64-linux-gnu/libz.so" ~/ws/openjdk8/build/linux-amd64-fastdebug/j2sdk-image/bin/javac Main.java An exception has occurred in the compiler (1.8.0-internal). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. java.lang.InternalError at java.util.zip.Inflater.init(Native Method) at java.util.zip.Inflater.(Inflater.java:103) at java.util.zip.ZipFile.getInflater(ZipFile.java:448) at java.util.zip.ZipFile.getInputStream(ZipFile.java:367) at java.util.jar.JarFile.getBytes(JarFile.java:379) at java.util.jar.JarFile.getManifestFromReference(JarFile.java:178) at java.util.jar.JarFile.getManifest(JarFile.java:165) at com.sun.tools.javac.file.FSInfo.getJarClassPath(FSInfo.java:69) at com.sun.tools.javac.file.CacheFSInfo.getJarClassPath(CacheFSInfo.java:94) at com.sun.tools.javac.file.Locations$Path.addJarClassPath(Locations.java:304) at com.sun.tools.javac.file.Locations$Path.addFile(Locations.java:295) at com.sun.tools.javac.file.Locations$Path.addDirectory(Locations.java:217) at com.sun.tools.javac.file.Locations$Path.addDirectories(Locations.java:192) at com.sun.tools.javac.file.Locations$BootClassPathLocationHandler.computePath(Locations.java:630) at com.sun.tools.javac.file.Locations$BootClassPathLocationHandler.lazy(Locations.java:642) at com.sun.tools.javac.file.Locations$BootClassPathLocationHandler.getLocation(Locations.java:576) at com.sun.tools.javac.file.Locations.getLocation(Locations.java:677) at com.sun.tools.javac.file.JavacFileManager.getLocation(JavacFileManager.java:803) at com.sun.tools.javac.file.JavacFileManager.list(JavacFileManager.java:617) at com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:2699) at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:2395) at com.sun.tools.javac.code.Symbol.complete(Symbol.java:434) at com.sun.tools.javac.comp.Enter.visitTopLevel(Enter.java:302) at com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:519) at com.sun.tools.javac.comp.Enter.classEnter(Enter.java:262) at com.sun.tools.javac.comp.Enter.classEnter(Enter.java:276) at com.sun.tools.javac.comp.Enter.complete(Enter.java:488) at com.sun.tools.javac.comp.Enter.main(Enter.java:473) at com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:990) at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:865) at com.sun.tools.javac.main.Main.compile(Main.java:517) at com.sun.tools.javac.main.Main.compile(Main.java:376) at com.sun.tools.javac.main.Main.compile(Main.java:365) at com.sun.tools.javac.main.Main.compile(Main.java:356) at com.sun.tools.javac.Main.compile(Main.java:76) at com.sun.tools.javac.Main.main(Main.java:61) On Sat, Feb 23, 2013 at 3:51 AM, Alan Bateman wrote: > On 22/02/2013 22:03, Martin Buchholz wrote: > > Hi Alan, Xueming, build-ers, > > I'd like you to do a code review. > > I've finally figured out why fastdebug jdk occasionally gives > InternalError in the zip code. > > Exception in thread "main" java.lang.InternalError > at java.util.zip.Inflater.init(Native Method) > at java.util.zip.Inflater.(Inflater.java:101) > at java.util.zip.ZipFile.getInflater(ZipFile.java:448) > > It's because: > - jdk changed structure size of z_stream struct > - making jdk zlib incompatible with stock zlib > - as a result of which, it is imperative to keep jdk zlib sequestered from > system zlib > - so need to not export zlib symbols from libzip.so > - so need to tell makefiles to use linker script unconditionally > > http://cr.openjdk.java.net/~martin/webrevs/openjdk8/hide-zlib/ > > I see Sherman has created a bug for this but it turns out that someone > else running with fastdebug ran into issues too: > > 8006319: fastdebug libzip.so is linked with global symbols, allowing > symbols to be overridden > > I see you are proposing to update make/java/zip/Makefile so that is the > old build. Looking at makefiles/CompileNativeLibraries.gmk (new build) then > it looks to me that it is using the map file. I haven't checking the > symbols in a fast debug build to double check so I'm curious if you've seen > this with a recent (new) build. > > -Alan. > > From peter.levart at gmail.com Sat Feb 23 19:39:23 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 23 Feb 2013 20:39:23 +0100 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <5115316A.8050109@oracle.com> References: <5115316A.8050109@oracle.com> Message-ID: <51291AEB.3040005@gmail.com> Hi Nils, If the counters are updated frequently from multiple threads, there might be contention/scalability issues. Instead of synchronization on updates, you might consider using atomic updates provided by sun.misc.Unsafe, like for example: Index: jdk/src/share/classes/sun/misc/PerfCounter.java =================================================================== --- jdk/src/share/classes/sun/misc/PerfCounter.java +++ jdk/src/share/classes/sun/misc/PerfCounter.java @@ -25,6 +25,8 @@ package sun.misc; +import sun.nio.ch.DirectBuffer; + import java.nio.ByteBuffer; import java.nio.ByteOrder; import java.nio.LongBuffer; @@ -50,6 +52,8 @@ public class PerfCounter { private static final Perf perf = AccessController.doPrivileged(new Perf.GetPerfAction()); + private static final Unsafe unsafe = + Unsafe.getUnsafe(); // Must match values defined in hotspot/src/share/vm/runtime/perfdata.hpp private final static int V_Constant = 1; @@ -59,12 +63,14 @@ private final String name; private final LongBuffer lb; + private final DirectBuffer db; private PerfCounter(String name, int type) { this.name = name; ByteBuffer bb = perf.createLong(name, U_None, type, 0L); bb.order(ByteOrder.nativeOrder()); this.lb = bb.asLongBuffer(); + this.db = bb instanceof DirectBuffer ? (DirectBuffer) bb : null; } static PerfCounter newPerfCounter(String name) { @@ -79,23 +85,44 @@ /** * Returns the current value of the perf counter. */ - public synchronized long get() { + public long get() { + if (db != null) { + return unsafe.getLongVolatile(null, db.address()); + } + else { + synchronized (this) { - return lb.get(0); - } + return lb.get(0); + } + } + } /** * Sets the value of the perf counter to the given newValue. */ - public synchronized void set(long newValue) { + public void set(long newValue) { + if (db != null) { + unsafe.putOrderedLong(null, db.address(), newValue); + } + else { + synchronized (this) { - lb.put(0, newValue); - } + lb.put(0, newValue); + } + } + } /** * Adds the given value to the perf counter. */ - public synchronized void add(long value) { - long res = get() + value; + public void add(long value) { + if (db != null) { + unsafe.getAndAddLong(null, db.address(), value); + } + else { + synchronized (this) { + long res = lb.get(0) + value; - lb.put(0, res); + lb.put(0, res); + } + } } /** Testing the PerfCounter.increment() method in a loop on multiple threads sharing the same PerfCounter instance, for example, on a 4-core Intel i7 machine produces the following results: # # PerfCounter_increment: run duration: 5,000 ms, #of logical CPUS: 8 # 1 threads, Tavg = 19.02 ns/op (? = 0.00 ns/op) 2 threads, Tavg = 109.93 ns/op (? = 6.17 ns/op) 3 threads, Tavg = 136.64 ns/op (? = 2.99 ns/op) 4 threads, Tavg = 293.26 ns/op (? = 5.30 ns/op) 5 threads, Tavg = 316.94 ns/op (? = 6.28 ns/op) 6 threads, Tavg = 686.96 ns/op (? = 7.09 ns/op) 7 threads, Tavg = 793.28 ns/op (? = 10.57 ns/op) 8 threads, Tavg = 898.15 ns/op (? = 14.63 ns/op) With the presented patch, the results are a little better: # # PerfCounter_increment: run duration: 5,000 ms, #of logical CPUS: 8 # # Measure: 1 threads, Tavg = 5.22 ns/op (? = 0.00 ns/op) 2 threads, Tavg = 34.51 ns/op (? = 0.60 ns/op) 3 threads, Tavg = 54.85 ns/op (? = 1.42 ns/op) 4 threads, Tavg = 74.67 ns/op (? = 1.71 ns/op) 5 threads, Tavg = 94.71 ns/op (? = 41.68 ns/op) 6 threads, Tavg = 114.80 ns/op (? = 32.10 ns/op) 7 threads, Tavg = 136.70 ns/op (? = 26.80 ns/op) 8 threads, Tavg = 158.48 ns/op (? = 9.93 ns/op) The scalability is not much better, but the raw speed is, so it might present less contention when used in real-world code. If you wanted even better scalability, there is a new class in JDK8, the java.util.concurrent.LongAdder. But that doesn't buy atomic "set()" - only "add()". And it can't update native-memory variables, so it could only be used for add-only counters and in conjunction with a background thread that would periodically flush the sum to the native memory.... Regards, Peter On 02/08/2013 06:10 PM, Nils Loodin wrote: > It would be interesting to know the number of thrown throwables in the > JVM, to be able to do some high level application diagnostics / > statistics. A good way to put this number would be a performance > counter, since it is accessible both from Java and from the VM. > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007806 > http://cr.openjdk.java.net/~nloodin/8007806/webrev.00/ > > Regards, > Nils Loodin From Alan.Bateman at oracle.com Sat Feb 23 20:08:27 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 23 Feb 2013 20:08:27 +0000 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <51291AEB.3040005@gmail.com> References: <5115316A.8050109@oracle.com> <51291AEB.3040005@gmail.com> Message-ID: <512921BB.502@oracle.com> On 23/02/2013 19:39, Peter Levart wrote: > Hi Nils, > > If the counters are updated frequently from multiple threads, there > might be contention/scalability issues. Instead of synchronization on > updates, you might consider using atomic updates provided by > sun.misc.Unsafe, like for example: > Most of the jvmstat counters are in VM and we only update a small number of counters in the libraries. Even so, I think your idea is good as further usage could potentially to be an issue, particularly add/increment (which involves a get at this). So irrespective of Nil's patch (which I think is now just a proposal to add a counter, not original patch that Jason was commenting on) then we should take your patch. -Alan From Alan.Bateman at oracle.com Sat Feb 23 20:12:05 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 23 Feb 2013 20:12:05 +0000 Subject: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so In-Reply-To: References: <5128AD43.2000809@oracle.com> Message-ID: <51292295.4040802@oracle.com> On 23/02/2013 18:06, Martin Buchholz wrote: > I am actually encountering this in openjdk7 with the old build system. > I can repro the problem in openjdk8 with the old build system, but not > the new one. > > I don't know if you consider this a bug with the new build system - > it's supposed to generate the same bits, after all???!! > I'm not sure why - I'd guess something to do with VARIANT or FILES_m > > It's highly dubious whether we should have this extremely subtle and > error-prone distinction between release and fastdebug builds at all. Thanks for confirming it's old build only, that was my reading too but without checking. Anyway, I do consider it a bug (in the old build), and really hard to track down too until you see both libz and the JDK's libzip loaded. Kelly might have some insight the product vs. fastdebug difference. -Alan From joe.darcy at oracle.com Sat Feb 23 20:24:39 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Sat, 23 Feb 2013 12:24:39 -0800 Subject: JDK RFR of 6556996: (ann spec) SuppressWarnings strings should be documented In-Reply-To: <51288AEF.5080708@univ-mlv.fr> References: <5126CDE4.5050209@oracle.com> <51288AEF.5080708@univ-mlv.fr> Message-ID: <51292587.6040503@oracle.com> On 2/23/2013 1:25 AM, Remi Forax wrote: > On 02/22/2013 02:46 AM, Joe Darcy wrote: >> Hello, >> >> Please review the simple fix below for >> >> 6556996: (ann spec) SuppressWarnings strings should be documented >> http://bugs.sun.com/view_bug.do?bug_id=6556996 >> >> the webrev is at >> >> http://cr.openjdk.java.net/~darcy/6556996.0/ >> >> and the patch is below. In brief, the only required string to be >> recognized in the SuppressWarnings annotation is "unchecked", which >> has been required by the JLS since Java SE 5. I made that adjustment >> to the documentation of the SuppressWarnings type. In addition, I >> added more @jls links relating the documentation of various >> annotation type to the JLS sections which discuss them. >> >> Thanks, >> >> -Joe > > Like the original submitter of the bug, I think that several other > strings (at least rawtypes, varargs, deprecation, serial) should be > documented with an explicit comment saying that they are not part of > the specification. > Those flags are way too common to not be documented in the API. > The only value mandated by the specification, the JLS in this case, is "unchecked" -- that will now be mentioned after this is pushed. javac and ecj have a somewhat differing set of recognized strings which should be documented in those tools. -Joe From joe.darcy at oracle.com Sat Feb 23 21:10:16 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Sat, 23 Feb 2013 13:10:16 -0800 Subject: @Supported design issues In-Reply-To: <20130222150427.1712@eggemoggin.niobe.net> References: <51266B7C.3040804@oracle.com>, <5126D516.1040005@oracle.com>, , <5127C4D4.5090800@oracle.com>, <20130222150427.1712@eggemoggin.niobe.net> Message-ID: <51293038.7090503@oracle.com> On 2/22/2013 3:04 PM, mark.reinhold at oracle.com wrote: > I understand (deeply!) the problem that @Supported is trying to solve. > Martin has raised a number of good questions about it already. Here are > some additional concerns I'd like to see addressed before we use it any > further in our source code. (I've been unable to find any earlier > discussion or code review of this new annotation in the archives, but > maybe I missed it.) > > - 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. 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..." > > - Is the "supportedness" of a package inherited by its sub-packages? No; for at least two reasons. First, annotation inheritance is only defined to work for classes along the superclass chain; there is no defined inheritance of annotations on methods or from superinterfaces. Second, subpackages of a package can have at most a tenuous logical relationship to the parent package (and they have no additional language-level access). For example, javax.annotation.processing added by JSR 269 is not really at all related to javax.annotation added by JSR 250. > > - The name "Supported" is problematic. It begs the question, > "Supported by whom?" Maybe the annotation should take URL and > phone-number parameters so that you know where to go when you run > into a problem? I would trust that users of a JDK distribution would by default turn to the provider of their distribution for support, or barring that, stackoverflow. > A name that captures a more inherent property of > the API unit being annotated would avoid this. Perhaps "@Stable"? > > - 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. > I'm not saying we should replicate all the detail of the Solaris > stability taxonomy [1], but we should at least discuss whether it's > worth doing something along those lines, if simpler. I think it'd > be particularly valuable to be able to distinguish between at least > four levels: > > - Supported and stable (i.e., will only evolve compatibly) until > we tell you it's going to go away (or change incompatibly), and > we'll give you at least one feature-release cycle's notice. > > - Supported in this feature release, but it might go away or > change incompatibly in the next, with best-effort notice. > > - Supported in this update release, but evolving rapidly, with > changes announced only in release notes. > > - Internal to the JDK, expect to get burned if you use it. 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. 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. > > 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 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. > > - 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 There are four packages with "annotation" as the last component of their name in the main JDK javadoc bundle: * java.lang.annotation - types supporting the annotations language feature + 6 annotation types + 1 interface, 2 enum types, 4 throwables * javax.annotation - JSR 250's " Common Annotations for the Java Platform" + 5 annotation types + 1 enum * javax.tools.annotation - defines a single annotation used by javah functionality (probably should get a new home) + 1 annotation type * javax.xml.bind.annotation + 30 annotation types + 1 interface, 6 classes, 3 enum types 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. As one example, the annotation types defined in javax.annotation.processing relate directly to annotation processing and are thus in the same package as and quite at home next to the other types related to annotation processing. > > Finally, this annotation is intended for use throughout our code base, > and will be of interest not just to people working on the JDK but also > to people using it. Its syntax, semantics, and intended usage should > hence be documented in a JEP, which will be much more visible than an > obscure Javadoc page. The listed criteria for a JEP are: > It requires two or more weeks of engineering effort, > > It makes a significant change to the JDK, or to the processes and > infrastructure by which it is developed, or > > It is in high demand by developers or customers. Perhaps excluding this email thread, the first condition does not hold for this work and the second two conditions are debatable. In addition, this work is a direct outgrowth of the pre-modularization work going on under JEP 162: Prepare for Modularization http://openjdk.java.net/jeps/162 Given the apparent heightened interest in this topic, I trust that if a JEP for this is sent in, it will be promptly published in the JEP index. -Joe From joe.darcy at oracle.com Sat Feb 23 21:32:52 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Sat, 23 Feb 2013 21:32:52 +0000 Subject: hg: jdk8/tl/jdk: 6556996: (ann spec) SuppressWarnings strings should be documented Message-ID: <20130223213315.CE89947D92@hg.openjdk.java.net> Changeset: 6f9b3e216b01 Author: darcy Date: 2013-02-23 13:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6f9b3e216b01 6556996: (ann spec) SuppressWarnings strings should be documented Reviewed-by: mduigou, chegar, abuckley ! src/share/classes/java/lang/Deprecated.java ! src/share/classes/java/lang/Override.java ! src/share/classes/java/lang/SafeVarargs.java ! src/share/classes/java/lang/SuppressWarnings.java ! src/share/classes/java/lang/annotation/Inherited.java ! src/share/classes/java/lang/annotation/Retention.java ! src/share/classes/java/lang/annotation/Target.java From david.holmes at oracle.com Sat Feb 23 23:35:42 2013 From: david.holmes at oracle.com (David Holmes) Date: Sun, 24 Feb 2013 09:35:42 +1000 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <512921BB.502@oracle.com> References: <5115316A.8050109@oracle.com> <51291AEB.3040005@gmail.com> <512921BB.502@oracle.com> Message-ID: <5129524E.7040608@oracle.com> On 24/02/2013 6:08 AM, Alan Bateman wrote: > On 23/02/2013 19:39, Peter Levart wrote: >> Hi Nils, >> >> If the counters are updated frequently from multiple threads, there >> might be contention/scalability issues. Instead of synchronization on >> updates, you might consider using atomic updates provided by >> sun.misc.Unsafe, like for example: >> > Most of the jvmstat counters are in VM and we only update a small number > of counters in the libraries. Even so, I think your idea is good as > further usage could potentially to be an issue, particularly > add/increment (which involves a get at this). So irrespective of Nil's > patch (which I think is now just a proposal to add a counter, not > original patch that Jason was commenting on) then we should take your > patch. Before we rush down this path. Atomic operations on 64-bit types are not supported natively on all 32-bit platforms. Atomic updates on those platforms will degenerate into locking - which is the barrier to implementing frequently used counters in the first place. David > -Alan > From david.holmes at oracle.com Sat Feb 23 23:39:54 2013 From: david.holmes at oracle.com (David Holmes) Date: Sun, 24 Feb 2013 09:39:54 +1000 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <51291AEB.3040005@gmail.com> References: <5115316A.8050109@oracle.com> <51291AEB.3040005@gmail.com> Message-ID: <5129534A.8000500@oracle.com> Peter, In your use of Unsafe you pass "null" as the object. I'm pretty certain you can't pass null here. Unsafe operates on fields or array elements. David On 24/02/2013 5:39 AM, Peter Levart wrote: > Hi Nils, > > If the counters are updated frequently from multiple threads, there > might be contention/scalability issues. Instead of synchronization on > updates, you might consider using atomic updates provided by > sun.misc.Unsafe, like for example: > > > Index: jdk/src/share/classes/sun/misc/PerfCounter.java > =================================================================== > --- jdk/src/share/classes/sun/misc/PerfCounter.java > +++ jdk/src/share/classes/sun/misc/PerfCounter.java > @@ -25,6 +25,8 @@ > > package sun.misc; > > +import sun.nio.ch.DirectBuffer; > + > import java.nio.ByteBuffer; > import java.nio.ByteOrder; > import java.nio.LongBuffer; > @@ -50,6 +52,8 @@ > public class PerfCounter { > private static final Perf perf = > AccessController.doPrivileged(new Perf.GetPerfAction()); > + private static final Unsafe unsafe = > + Unsafe.getUnsafe(); > > // Must match values defined in > hotspot/src/share/vm/runtime/perfdata.hpp > private final static int V_Constant = 1; > @@ -59,12 +63,14 @@ > > private final String name; > private final LongBuffer lb; > + private final DirectBuffer db; > > private PerfCounter(String name, int type) { > this.name = name; > ByteBuffer bb = perf.createLong(name, U_None, type, 0L); > bb.order(ByteOrder.nativeOrder()); > this.lb = bb.asLongBuffer(); > + this.db = bb instanceof DirectBuffer ? (DirectBuffer) bb : null; > } > > static PerfCounter newPerfCounter(String name) { > @@ -79,23 +85,44 @@ > /** > * Returns the current value of the perf counter. > */ > - public synchronized long get() { > + public long get() { > + if (db != null) { > + return unsafe.getLongVolatile(null, db.address()); > + } > + else { > + synchronized (this) { > - return lb.get(0); > - } > + return lb.get(0); > + } > + } > + } > > /** > * Sets the value of the perf counter to the given newValue. > */ > - public synchronized void set(long newValue) { > + public void set(long newValue) { > + if (db != null) { > + unsafe.putOrderedLong(null, db.address(), newValue); > + } > + else { > + synchronized (this) { > - lb.put(0, newValue); > - } > + lb.put(0, newValue); > + } > + } > + } > > /** > * Adds the given value to the perf counter. > */ > - public synchronized void add(long value) { > - long res = get() + value; > + public void add(long value) { > + if (db != null) { > + unsafe.getAndAddLong(null, db.address(), value); > + } > + else { > + synchronized (this) { > + long res = lb.get(0) + value; > - lb.put(0, res); > + lb.put(0, res); > + } > + } > } > > /** > > > > Testing the PerfCounter.increment() method in a loop on multiple threads > sharing the same PerfCounter instance, for example, on a 4-core Intel i7 > machine produces the following results: > > # > # PerfCounter_increment: run duration: 5,000 ms, #of logical CPUS: 8 > # > 1 threads, Tavg = 19.02 ns/op (? = 0.00 ns/op) > 2 threads, Tavg = 109.93 ns/op (? = 6.17 ns/op) > 3 threads, Tavg = 136.64 ns/op (? = 2.99 ns/op) > 4 threads, Tavg = 293.26 ns/op (? = 5.30 ns/op) > 5 threads, Tavg = 316.94 ns/op (? = 6.28 ns/op) > 6 threads, Tavg = 686.96 ns/op (? = 7.09 ns/op) > 7 threads, Tavg = 793.28 ns/op (? = 10.57 ns/op) > 8 threads, Tavg = 898.15 ns/op (? = 14.63 ns/op) > > > With the presented patch, the results are a little better: > > # > # PerfCounter_increment: run duration: 5,000 ms, #of logical CPUS: 8 > # > # Measure: > 1 threads, Tavg = 5.22 ns/op (? = 0.00 ns/op) > 2 threads, Tavg = 34.51 ns/op (? = 0.60 ns/op) > 3 threads, Tavg = 54.85 ns/op (? = 1.42 ns/op) > 4 threads, Tavg = 74.67 ns/op (? = 1.71 ns/op) > 5 threads, Tavg = 94.71 ns/op (? = 41.68 ns/op) > 6 threads, Tavg = 114.80 ns/op (? = 32.10 ns/op) > 7 threads, Tavg = 136.70 ns/op (? = 26.80 ns/op) > 8 threads, Tavg = 158.48 ns/op (? = 9.93 ns/op) > > > The scalability is not much better, but the raw speed is, so it might > present less contention when used in real-world code. If you wanted even > better scalability, there is a new class in JDK8, the > java.util.concurrent.LongAdder. But that doesn't buy atomic "set()" - > only "add()". And it can't update native-memory variables, so it could > only be used for add-only counters and in conjunction with a background > thread that would periodically flush the sum to the native memory.... > > Regards, Peter > > > On 02/08/2013 06:10 PM, Nils Loodin wrote: >> It would be interesting to know the number of thrown throwables in the >> JVM, to be able to do some high level application diagnostics / >> statistics. A good way to put this number would be a performance >> counter, since it is accessible both from Java and from the VM. >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007806 >> http://cr.openjdk.java.net/~nloodin/8007806/webrev.00/ >> >> Regards, >> Nils Loodin > From peter.levart at gmail.com Sun Feb 24 08:50:34 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 24 Feb 2013 09:50:34 +0100 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <5129534A.8000500@oracle.com> References: <5115316A.8050109@oracle.com> <51291AEB.3040005@gmail.com> <5129534A.8000500@oracle.com> Message-ID: <5129D45A.6010802@gmail.com> Hi David, I thought it was ok to pass null, but I don't know the "portability" issues in-depth. The javadoc for Unsafe says: /"This method refers to a variable by means of two parameters, and so it provides (in effect) a double-register addressing mode for Java variables. When the object reference is null, this method uses its offset as an absolute address. This is similar in operation to methods such as getInt(long), which provide (in effect) a single-register addressing mode for non-Java variables. However, because Java variables may have a different layout in memory from non-Java variables, programmers should not assume that these two addressing modes are ever equivalent. Also, programmers should remember that offsets from the double-register addressing mode cannot be portably confused with longs used in the single-register addressing mode."/ Does anybody know the in-depth interpretation of the above? Is it only the particular Java/native type differences (for example, endianess of variables) that these two addressing modes might interpret differently or something else too? Regards, Peter On 02/24/2013 12:39 AM, David Holmes wrote: > Peter, > > In your use of Unsafe you pass "null" as the object. I'm pretty > certain you can't pass null here. Unsafe operates on fields or array > elements. > > David > > On 24/02/2013 5:39 AM, Peter Levart wrote: >> Hi Nils, >> >> If the counters are updated frequently from multiple threads, there >> might be contention/scalability issues. Instead of synchronization on >> updates, you might consider using atomic updates provided by >> sun.misc.Unsafe, like for example: >> >> >> Index: jdk/src/share/classes/sun/misc/PerfCounter.java >> =================================================================== >> --- jdk/src/share/classes/sun/misc/PerfCounter.java >> +++ jdk/src/share/classes/sun/misc/PerfCounter.java >> @@ -25,6 +25,8 @@ >> >> package sun.misc; >> >> +import sun.nio.ch.DirectBuffer; >> + >> import java.nio.ByteBuffer; >> import java.nio.ByteOrder; >> import java.nio.LongBuffer; >> @@ -50,6 +52,8 @@ >> public class PerfCounter { >> private static final Perf perf = >> AccessController.doPrivileged(new Perf.GetPerfAction()); >> + private static final Unsafe unsafe = >> + Unsafe.getUnsafe(); >> >> // Must match values defined in >> hotspot/src/share/vm/runtime/perfdata.hpp >> private final static int V_Constant = 1; >> @@ -59,12 +63,14 @@ >> >> private final String name; >> private final LongBuffer lb; >> + private final DirectBuffer db; >> >> private PerfCounter(String name, int type) { >> this.name = name; >> ByteBuffer bb = perf.createLong(name, U_None, type, 0L); >> bb.order(ByteOrder.nativeOrder()); >> this.lb = bb.asLongBuffer(); >> + this.db = bb instanceof DirectBuffer ? (DirectBuffer) bb : >> null; >> } >> >> static PerfCounter newPerfCounter(String name) { >> @@ -79,23 +85,44 @@ >> /** >> * Returns the current value of the perf counter. >> */ >> - public synchronized long get() { >> + public long get() { >> + if (db != null) { >> + return unsafe.getLongVolatile(null, db.address()); >> + } >> + else { >> + synchronized (this) { >> - return lb.get(0); >> - } >> + return lb.get(0); >> + } >> + } >> + } >> >> /** >> * Sets the value of the perf counter to the given newValue. >> */ >> - public synchronized void set(long newValue) { >> + public void set(long newValue) { >> + if (db != null) { >> + unsafe.putOrderedLong(null, db.address(), newValue); >> + } >> + else { >> + synchronized (this) { >> - lb.put(0, newValue); >> - } >> + lb.put(0, newValue); >> + } >> + } >> + } >> >> /** >> * Adds the given value to the perf counter. >> */ >> - public synchronized void add(long value) { >> - long res = get() + value; >> + public void add(long value) { >> + if (db != null) { >> + unsafe.getAndAddLong(null, db.address(), value); >> + } >> + else { >> + synchronized (this) { >> + long res = lb.get(0) + value; >> - lb.put(0, res); >> + lb.put(0, res); >> + } >> + } >> } >> >> /** >> >> >> >> Testing the PerfCounter.increment() method in a loop on multiple threads >> sharing the same PerfCounter instance, for example, on a 4-core Intel i7 >> machine produces the following results: >> >> # >> # PerfCounter_increment: run duration: 5,000 ms, #of logical CPUS: 8 >> # >> 1 threads, Tavg = 19.02 ns/op (? = 0.00 ns/op) >> 2 threads, Tavg = 109.93 ns/op (? = 6.17 ns/op) >> 3 threads, Tavg = 136.64 ns/op (? = 2.99 ns/op) >> 4 threads, Tavg = 293.26 ns/op (? = 5.30 ns/op) >> 5 threads, Tavg = 316.94 ns/op (? = 6.28 ns/op) >> 6 threads, Tavg = 686.96 ns/op (? = 7.09 ns/op) >> 7 threads, Tavg = 793.28 ns/op (? = 10.57 ns/op) >> 8 threads, Tavg = 898.15 ns/op (? = 14.63 ns/op) >> >> >> With the presented patch, the results are a little better: >> >> # >> # PerfCounter_increment: run duration: 5,000 ms, #of logical CPUS: 8 >> # >> # Measure: >> 1 threads, Tavg = 5.22 ns/op (? = 0.00 ns/op) >> 2 threads, Tavg = 34.51 ns/op (? = 0.60 ns/op) >> 3 threads, Tavg = 54.85 ns/op (? = 1.42 ns/op) >> 4 threads, Tavg = 74.67 ns/op (? = 1.71 ns/op) >> 5 threads, Tavg = 94.71 ns/op (? = 41.68 ns/op) >> 6 threads, Tavg = 114.80 ns/op (? = 32.10 ns/op) >> 7 threads, Tavg = 136.70 ns/op (? = 26.80 ns/op) >> 8 threads, Tavg = 158.48 ns/op (? = 9.93 ns/op) >> >> >> The scalability is not much better, but the raw speed is, so it might >> present less contention when used in real-world code. If you wanted even >> better scalability, there is a new class in JDK8, the >> java.util.concurrent.LongAdder. But that doesn't buy atomic "set()" - >> only "add()". And it can't update native-memory variables, so it could >> only be used for add-only counters and in conjunction with a background >> thread that would periodically flush the sum to the native memory.... >> >> Regards, Peter >> >> >> On 02/08/2013 06:10 PM, Nils Loodin wrote: >>> It would be interesting to know the number of thrown throwables in the >>> JVM, to be able to do some high level application diagnostics / >>> statistics. A good way to put this number would be a performance >>> counter, since it is accessible both from Java and from the VM. >>> >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007806 >>> http://cr.openjdk.java.net/~nloodin/8007806/webrev.00/ >>> >>> Regards, >>> Nils Loodin >> From Alan.Bateman at oracle.com Sun Feb 24 08:56:26 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 24 Feb 2013 08:56:26 +0000 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <5129524E.7040608@oracle.com> References: <5115316A.8050109@oracle.com> <51291AEB.3040005@gmail.com> <512921BB.502@oracle.com> <5129524E.7040608@oracle.com> Message-ID: <5129D5B9.5080706@oracle.com> On 23/02/2013 23:35, David Holmes wrote: > > Before we rush down this path. Atomic operations on 64-bit types are > not supported natively on all 32-bit platforms. Atomic updates on > those platforms will degenerate into locking - which is the barrier to > implementing frequently used counters in the first place. I understand, and clearly more work/investigation is required, but I think it's worth looking into, particularly if Nils and others are going are adding further counters and instrumenting code dynamic to use them. -Alan From david.holmes at oracle.com Sun Feb 24 10:31:01 2013 From: david.holmes at oracle.com (David Holmes) Date: Sun, 24 Feb 2013 20:31:01 +1000 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <5129D45A.6010802@gmail.com> References: <5115316A.8050109@oracle.com> <51291AEB.3040005@gmail.com> <5129534A.8000500@oracle.com> <5129D45A.6010802@gmail.com> Message-ID: <5129EBE5.1030207@oracle.com> On 24/02/2013 6:50 PM, Peter Levart wrote: > Hi David, > > I thought it was ok to pass null, but I don't know the "portability" > issues in-depth. The javadoc for Unsafe says: > > /"This method refers to a variable by means of two parameters, and so it > provides (in effect) a double-register addressing mode for Java > variables. When the object reference is null, this method uses its > offset as an absolute address. This is similar in operation to methods > such as getInt(long), which provide (in effect) a single-register > addressing mode for non-Java variables. However, because Java variables > may have a different layout in memory from non-Java variables, > programmers should not assume that these two addressing modes are ever > equivalent. Also, programmers should remember that offsets from the > double-register addressing mode cannot be portably confused with longs > used in the single-register addressing mode."/ That is the doc for getXXX but not for getAndAddXXX or compareAndSwapXXX. You can't have null here: UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapLong(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jlong e, jlong x)) UnsafeWrapper("Unsafe_CompareAndSwapLong"); Handle p (THREAD, JNIHandles::resolve(obj)); jlong* addr = (jlong*)(index_oop_from_field_offset_long(p(), offset)); if (VM_Version::supports_cx8()) return (jlong)(Atomic::cmpxchg(x, addr, e)) == e; else { jboolean success = false; ObjectLocker ol(p, THREAD); if (*addr == e) { *addr = x; success = true; } return success; } UNSAFE_END David ----- > Does anybody know the in-depth interpretation of the above? Is it only > the particular Java/native type differences (for example, endianess of > variables) that these two addressing modes might interpret differently > or something else too? > > Regards, Peter > > > On 02/24/2013 12:39 AM, David Holmes wrote: >> Peter, >> >> In your use of Unsafe you pass "null" as the object. I'm pretty >> certain you can't pass null here. Unsafe operates on fields or array >> elements. >> >> David >> >> On 24/02/2013 5:39 AM, Peter Levart wrote: >>> Hi Nils, >>> >>> If the counters are updated frequently from multiple threads, there >>> might be contention/scalability issues. Instead of synchronization on >>> updates, you might consider using atomic updates provided by >>> sun.misc.Unsafe, like for example: >>> >>> >>> Index: jdk/src/share/classes/sun/misc/PerfCounter.java >>> =================================================================== >>> --- jdk/src/share/classes/sun/misc/PerfCounter.java >>> +++ jdk/src/share/classes/sun/misc/PerfCounter.java >>> @@ -25,6 +25,8 @@ >>> >>> package sun.misc; >>> >>> +import sun.nio.ch.DirectBuffer; >>> + >>> import java.nio.ByteBuffer; >>> import java.nio.ByteOrder; >>> import java.nio.LongBuffer; >>> @@ -50,6 +52,8 @@ >>> public class PerfCounter { >>> private static final Perf perf = >>> AccessController.doPrivileged(new Perf.GetPerfAction()); >>> + private static final Unsafe unsafe = >>> + Unsafe.getUnsafe(); >>> >>> // Must match values defined in >>> hotspot/src/share/vm/runtime/perfdata.hpp >>> private final static int V_Constant = 1; >>> @@ -59,12 +63,14 @@ >>> >>> private final String name; >>> private final LongBuffer lb; >>> + private final DirectBuffer db; >>> >>> private PerfCounter(String name, int type) { >>> this.name = name; >>> ByteBuffer bb = perf.createLong(name, U_None, type, 0L); >>> bb.order(ByteOrder.nativeOrder()); >>> this.lb = bb.asLongBuffer(); >>> + this.db = bb instanceof DirectBuffer ? (DirectBuffer) bb : >>> null; >>> } >>> >>> static PerfCounter newPerfCounter(String name) { >>> @@ -79,23 +85,44 @@ >>> /** >>> * Returns the current value of the perf counter. >>> */ >>> - public synchronized long get() { >>> + public long get() { >>> + if (db != null) { >>> + return unsafe.getLongVolatile(null, db.address()); >>> + } >>> + else { >>> + synchronized (this) { >>> - return lb.get(0); >>> - } >>> + return lb.get(0); >>> + } >>> + } >>> + } >>> >>> /** >>> * Sets the value of the perf counter to the given newValue. >>> */ >>> - public synchronized void set(long newValue) { >>> + public void set(long newValue) { >>> + if (db != null) { >>> + unsafe.putOrderedLong(null, db.address(), newValue); >>> + } >>> + else { >>> + synchronized (this) { >>> - lb.put(0, newValue); >>> - } >>> + lb.put(0, newValue); >>> + } >>> + } >>> + } >>> >>> /** >>> * Adds the given value to the perf counter. >>> */ >>> - public synchronized void add(long value) { >>> - long res = get() + value; >>> + public void add(long value) { >>> + if (db != null) { >>> + unsafe.getAndAddLong(null, db.address(), value); >>> + } >>> + else { >>> + synchronized (this) { >>> + long res = lb.get(0) + value; >>> - lb.put(0, res); >>> + lb.put(0, res); >>> + } >>> + } >>> } >>> >>> /** >>> >>> >>> >>> Testing the PerfCounter.increment() method in a loop on multiple threads >>> sharing the same PerfCounter instance, for example, on a 4-core Intel i7 >>> machine produces the following results: >>> >>> # >>> # PerfCounter_increment: run duration: 5,000 ms, #of logical CPUS: 8 >>> # >>> 1 threads, Tavg = 19.02 ns/op (? = 0.00 ns/op) >>> 2 threads, Tavg = 109.93 ns/op (? = 6.17 ns/op) >>> 3 threads, Tavg = 136.64 ns/op (? = 2.99 ns/op) >>> 4 threads, Tavg = 293.26 ns/op (? = 5.30 ns/op) >>> 5 threads, Tavg = 316.94 ns/op (? = 6.28 ns/op) >>> 6 threads, Tavg = 686.96 ns/op (? = 7.09 ns/op) >>> 7 threads, Tavg = 793.28 ns/op (? = 10.57 ns/op) >>> 8 threads, Tavg = 898.15 ns/op (? = 14.63 ns/op) >>> >>> >>> With the presented patch, the results are a little better: >>> >>> # >>> # PerfCounter_increment: run duration: 5,000 ms, #of logical CPUS: 8 >>> # >>> # Measure: >>> 1 threads, Tavg = 5.22 ns/op (? = 0.00 ns/op) >>> 2 threads, Tavg = 34.51 ns/op (? = 0.60 ns/op) >>> 3 threads, Tavg = 54.85 ns/op (? = 1.42 ns/op) >>> 4 threads, Tavg = 74.67 ns/op (? = 1.71 ns/op) >>> 5 threads, Tavg = 94.71 ns/op (? = 41.68 ns/op) >>> 6 threads, Tavg = 114.80 ns/op (? = 32.10 ns/op) >>> 7 threads, Tavg = 136.70 ns/op (? = 26.80 ns/op) >>> 8 threads, Tavg = 158.48 ns/op (? = 9.93 ns/op) >>> >>> >>> The scalability is not much better, but the raw speed is, so it might >>> present less contention when used in real-world code. If you wanted even >>> better scalability, there is a new class in JDK8, the >>> java.util.concurrent.LongAdder. But that doesn't buy atomic "set()" - >>> only "add()". And it can't update native-memory variables, so it could >>> only be used for add-only counters and in conjunction with a background >>> thread that would periodically flush the sum to the native memory.... >>> >>> Regards, Peter >>> >>> >>> On 02/08/2013 06:10 PM, Nils Loodin wrote: >>>> It would be interesting to know the number of thrown throwables in the >>>> JVM, to be able to do some high level application diagnostics / >>>> statistics. A good way to put this number would be a performance >>>> counter, since it is accessible both from Java and from the VM. >>>> >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007806 >>>> http://cr.openjdk.java.net/~nloodin/8007806/webrev.00/ >>>> >>>> Regards, >>>> Nils Loodin >>> > From peter.levart at gmail.com Sun Feb 24 10:31:46 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 24 Feb 2013 11:31:46 +0100 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <5129524E.7040608@oracle.com> References: <5115316A.8050109@oracle.com> <51291AEB.3040005@gmail.com> <512921BB.502@oracle.com> <5129524E.7040608@oracle.com> Message-ID: <5129EC12.6080805@gmail.com> On 02/24/2013 12:35 AM, David Holmes wrote: > On 24/02/2013 6:08 AM, Alan Bateman wrote: >> On 23/02/2013 19:39, Peter Levart wrote: >>> Hi Nils, >>> >>> If the counters are updated frequently from multiple threads, there >>> might be contention/scalability issues. Instead of synchronization on >>> updates, you might consider using atomic updates provided by >>> sun.misc.Unsafe, like for example: >>> >> Most of the jvmstat counters are in VM and we only update a small number >> of counters in the libraries. Even so, I think your idea is good as >> further usage could potentially to be an issue, particularly >> add/increment (which involves a get at this). So irrespective of Nil's >> patch (which I think is now just a proposal to add a counter, not >> original patch that Jason was commenting on) then we should take your >> patch. > > Before we rush down this path. Atomic operations on 64-bit types are > not supported natively on all 32-bit platforms. Atomic updates on > those platforms will degenerate into locking - which is the barrier to > implementing frequently used counters in the first place. > > David It's true, yes. I tried replacing atomic add with a read/CAS loop (like it is coded in Unsafe as a fall-back for platforms that don't support atomic add) and even on Intel 64bit such add performs on-par with synchronized method as scalability is concerned. It's raw speed when not contended is 2x the synchronized variant. I also found out the "compatibility" gotcha when using "null" as the 1st argument to Unsafe "double-register" addressing mode methods. On platforms, that don't support 64bit CAS natively, the argument is used as an Object reference to synchronize on to emulate the CAS instruction. On Raspery-PI (armv6) for example, the patch causes a crash for that reason: # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x40659f80, pid=2450, tid=1086497904 # # JRE version: Java(TM) SE Runtime Environment (8.0) # Java VM: Java HotSpot(TM) Client VM (25.0-b04 mixed mode linux-arm ) # Problematic frame: # V [libjvm.so+0x3d3f80] ObjectSynchronizer::slow_enter(Handle, BasicLock*, Thread*)+0x4 Regards, Peter > >> -Alan >> From peter.levart at gmail.com Sun Feb 24 10:37:51 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 24 Feb 2013 11:37:51 +0100 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <5129EBE5.1030207@oracle.com> References: <5115316A.8050109@oracle.com> <51291AEB.3040005@gmail.com> <5129534A.8000500@oracle.com> <5129D45A.6010802@gmail.com> <5129EBE5.1030207@oracle.com> Message-ID: <5129ED7F.9090004@gmail.com> On 02/24/2013 11:31 AM, David Holmes wrote: > On 24/02/2013 6:50 PM, Peter Levart wrote: >> Hi David, >> >> I thought it was ok to pass null, but I don't know the "portability" >> issues in-depth. The javadoc for Unsafe says: >> >> /"This method refers to a variable by means of two parameters, and so it >> provides (in effect) a double-register addressing mode for Java >> variables. When the object reference is null, this method uses its >> offset as an absolute address. This is similar in operation to methods >> such as getInt(long), which provide (in effect) a single-register >> addressing mode for non-Java variables. However, because Java variables >> may have a different layout in memory from non-Java variables, >> programmers should not assume that these two addressing modes are ever >> equivalent. Also, programmers should remember that offsets from the >> double-register addressing mode cannot be portably confused with longs >> used in the single-register addressing mode."/ > > That is the doc for getXXX but not for getAndAddXXX or > compareAndSwapXXX. You can't have null here: > > UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapLong(JNIEnv *env, jobject > unsafe, jobject obj, jlong offset, jlong e, jlong x)) > UnsafeWrapper("Unsafe_CompareAndSwapLong"); > Handle p (THREAD, JNIHandles::resolve(obj)); > jlong* addr = (jlong*)(index_oop_from_field_offset_long(p(), offset)); > if (VM_Version::supports_cx8()) > return (jlong)(Atomic::cmpxchg(x, addr, e)) == e; > else { > jboolean success = false; > ObjectLocker ol(p, THREAD); > if (*addr == e) { *addr = x; success = true; } > return success; > } > UNSAFE_END > > David > ----- > Oh yes, I found that out too... :-( Thanks, Peter > >> Does anybody know the in-depth interpretation of the above? Is it only >> the particular Java/native type differences (for example, endianess of >> variables) that these two addressing modes might interpret differently >> or something else too? >> >> Regards, Peter >> >> >> On 02/24/2013 12:39 AM, David Holmes wrote: >>> Peter, >>> >>> In your use of Unsafe you pass "null" as the object. I'm pretty >>> certain you can't pass null here. Unsafe operates on fields or array >>> elements. >>> >>> David >>> >>> On 24/02/2013 5:39 AM, Peter Levart wrote: >>>> Hi Nils, >>>> >>>> If the counters are updated frequently from multiple threads, there >>>> might be contention/scalability issues. Instead of synchronization on >>>> updates, you might consider using atomic updates provided by >>>> sun.misc.Unsafe, like for example: >>>> >>>> >>>> Index: jdk/src/share/classes/sun/misc/PerfCounter.java >>>> =================================================================== >>>> --- jdk/src/share/classes/sun/misc/PerfCounter.java >>>> +++ jdk/src/share/classes/sun/misc/PerfCounter.java >>>> @@ -25,6 +25,8 @@ >>>> >>>> package sun.misc; >>>> >>>> +import sun.nio.ch.DirectBuffer; >>>> + >>>> import java.nio.ByteBuffer; >>>> import java.nio.ByteOrder; >>>> import java.nio.LongBuffer; >>>> @@ -50,6 +52,8 @@ >>>> public class PerfCounter { >>>> private static final Perf perf = >>>> AccessController.doPrivileged(new Perf.GetPerfAction()); >>>> + private static final Unsafe unsafe = >>>> + Unsafe.getUnsafe(); >>>> >>>> // Must match values defined in >>>> hotspot/src/share/vm/runtime/perfdata.hpp >>>> private final static int V_Constant = 1; >>>> @@ -59,12 +63,14 @@ >>>> >>>> private final String name; >>>> private final LongBuffer lb; >>>> + private final DirectBuffer db; >>>> >>>> private PerfCounter(String name, int type) { >>>> this.name = name; >>>> ByteBuffer bb = perf.createLong(name, U_None, type, 0L); >>>> bb.order(ByteOrder.nativeOrder()); >>>> this.lb = bb.asLongBuffer(); >>>> + this.db = bb instanceof DirectBuffer ? (DirectBuffer) bb : >>>> null; >>>> } >>>> >>>> static PerfCounter newPerfCounter(String name) { >>>> @@ -79,23 +85,44 @@ >>>> /** >>>> * Returns the current value of the perf counter. >>>> */ >>>> - public synchronized long get() { >>>> + public long get() { >>>> + if (db != null) { >>>> + return unsafe.getLongVolatile(null, db.address()); >>>> + } >>>> + else { >>>> + synchronized (this) { >>>> - return lb.get(0); >>>> - } >>>> + return lb.get(0); >>>> + } >>>> + } >>>> + } >>>> >>>> /** >>>> * Sets the value of the perf counter to the given newValue. >>>> */ >>>> - public synchronized void set(long newValue) { >>>> + public void set(long newValue) { >>>> + if (db != null) { >>>> + unsafe.putOrderedLong(null, db.address(), newValue); >>>> + } >>>> + else { >>>> + synchronized (this) { >>>> - lb.put(0, newValue); >>>> - } >>>> + lb.put(0, newValue); >>>> + } >>>> + } >>>> + } >>>> >>>> /** >>>> * Adds the given value to the perf counter. >>>> */ >>>> - public synchronized void add(long value) { >>>> - long res = get() + value; >>>> + public void add(long value) { >>>> + if (db != null) { >>>> + unsafe.getAndAddLong(null, db.address(), value); >>>> + } >>>> + else { >>>> + synchronized (this) { >>>> + long res = lb.get(0) + value; >>>> - lb.put(0, res); >>>> + lb.put(0, res); >>>> + } >>>> + } >>>> } >>>> >>>> /** >>>> >>>> >>>> >>>> Testing the PerfCounter.increment() method in a loop on multiple >>>> threads >>>> sharing the same PerfCounter instance, for example, on a 4-core >>>> Intel i7 >>>> machine produces the following results: >>>> >>>> # >>>> # PerfCounter_increment: run duration: 5,000 ms, #of logical CPUS: 8 >>>> # >>>> 1 threads, Tavg = 19.02 ns/op (? = 0.00 ns/op) >>>> 2 threads, Tavg = 109.93 ns/op (? = 6.17 ns/op) >>>> 3 threads, Tavg = 136.64 ns/op (? = 2.99 ns/op) >>>> 4 threads, Tavg = 293.26 ns/op (? = 5.30 ns/op) >>>> 5 threads, Tavg = 316.94 ns/op (? = 6.28 ns/op) >>>> 6 threads, Tavg = 686.96 ns/op (? = 7.09 ns/op) >>>> 7 threads, Tavg = 793.28 ns/op (? = 10.57 ns/op) >>>> 8 threads, Tavg = 898.15 ns/op (? = 14.63 ns/op) >>>> >>>> >>>> With the presented patch, the results are a little better: >>>> >>>> # >>>> # PerfCounter_increment: run duration: 5,000 ms, #of logical CPUS: 8 >>>> # >>>> # Measure: >>>> 1 threads, Tavg = 5.22 ns/op (? = 0.00 ns/op) >>>> 2 threads, Tavg = 34.51 ns/op (? = 0.60 ns/op) >>>> 3 threads, Tavg = 54.85 ns/op (? = 1.42 ns/op) >>>> 4 threads, Tavg = 74.67 ns/op (? = 1.71 ns/op) >>>> 5 threads, Tavg = 94.71 ns/op (? = 41.68 ns/op) >>>> 6 threads, Tavg = 114.80 ns/op (? = 32.10 ns/op) >>>> 7 threads, Tavg = 136.70 ns/op (? = 26.80 ns/op) >>>> 8 threads, Tavg = 158.48 ns/op (? = 9.93 ns/op) >>>> >>>> >>>> The scalability is not much better, but the raw speed is, so it might >>>> present less contention when used in real-world code. If you wanted >>>> even >>>> better scalability, there is a new class in JDK8, the >>>> java.util.concurrent.LongAdder. But that doesn't buy atomic "set()" - >>>> only "add()". And it can't update native-memory variables, so it could >>>> only be used for add-only counters and in conjunction with a >>>> background >>>> thread that would periodically flush the sum to the native memory.... >>>> >>>> Regards, Peter >>>> >>>> >>>> On 02/08/2013 06:10 PM, Nils Loodin wrote: >>>>> It would be interesting to know the number of thrown throwables in >>>>> the >>>>> JVM, to be able to do some high level application diagnostics / >>>>> statistics. A good way to put this number would be a performance >>>>> counter, since it is accessible both from Java and from the VM. >>>>> >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007806 >>>>> http://cr.openjdk.java.net/~nloodin/8007806/webrev.00/ >>>>> >>>>> Regards, >>>>> Nils Loodin >>>> >> From Alan.Bateman at oracle.com Sun Feb 24 13:24:45 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 24 Feb 2013 13:24:45 +0000 Subject: hg: jdk8/tl/jdk: 8008167: IdentityHashMap.[keySet|values|entrySet].toArray speed-up In-Reply-To: <20130214175538.236EC47A96@hg.openjdk.java.net> References: <20130214175538.236EC47A96@hg.openjdk.java.net> Message-ID: <512A149D.3030204@oracle.com> On 14/02/2013 17:55, mike.duigou at oracle.com wrote: > Changeset: e57019d2f34a > Author: mduigou > Date: 2013-02-13 14:50 -0800 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e57019d2f34a > > 8008167: IdentityHashMap.[keySet|values|entrySet].toArray speed-up > Reviewed-by: mduigou, martin > Contributed-by: Peter Levart > > ! src/share/classes/java/util/IdentityHashMap.java > A belated comment on this is that CME will now be thrown for cases where it wasn't previously. We need to make sure this behavior change is tracked (for release notes, etc.). -Alan From peter.levart at gmail.com Sun Feb 24 14:42:24 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 24 Feb 2013 15:42:24 +0100 Subject: hg: jdk8/tl/jdk: 8008167: IdentityHashMap.[keySet|values|entrySet].toArray speed-up In-Reply-To: <512A149D.3030204@oracle.com> References: <20130214175538.236EC47A96@hg.openjdk.java.net> <512A149D.3030204@oracle.com> Message-ID: Hi Alan, I think ConcurrentModificationException could be thrown previously too, if the Map was modified from other thread while iterating using iterator (fail-fast iterator). Will check this in detail when I'm back at screen... Regards, Peter On Feb 24, 2013 2:25 PM, "Alan Bateman" wrote: > On 14/02/2013 17:55, mike.duigou at oracle.com wrote: > >> Changeset: e57019d2f34a >> Author: mduigou >> Date: 2013-02-13 14:50 -0800 >> URL: http://hg.openjdk.java.net/**jdk8/tl/jdk/rev/e57019d2f34a >> >> 8008167: IdentityHashMap.[keySet|**values|entrySet].toArray speed-up >> Reviewed-by: mduigou, martin >> Contributed-by: Peter Levart >> >> ! src/share/classes/java/util/**IdentityHashMap.java >> >> A belated comment on this is that CME will now be thrown for cases where > it wasn't previously. We need to make sure this behavior change is tracked > (for release notes, etc.). > > -Alan > From peter.levart at gmail.com Sun Feb 24 15:49:29 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 24 Feb 2013 16:49:29 +0100 Subject: hg: jdk8/tl/jdk: 8008167: IdentityHashMap.[keySet|values|entrySet].toArray speed-up In-Reply-To: References: <20130214175538.236EC47A96@hg.openjdk.java.net> <512A149D.3030204@oracle.com> Message-ID: <512A3689.3000900@gmail.com> Hi Alan, I checked and it seems all 3 IHM views [keySet|values|entrySet] have a fail-fast iterator implementation (IdentityHashMap.IdentityHashMapIterator) and all 3 are (were) using the iterator for .toArray implementations. So this patch tries to preserve the behavior when there is a concurrent modification (which is only possible from other thread and is illegal usage anyway since IHM is not thread-safe) while executing the toArray methods on the views... Do you see something I don't see? Regards, Peter On 02/24/2013 03:42 PM, Peter Levart wrote: > > Hi Alan, > > I think ConcurrentModificationException could be thrown previously > too, if the Map was modified from other thread while iterating using > iterator (fail-fast iterator). Will check this in detail when I'm back > at screen... > > Regards, Peter > > On Feb 24, 2013 2:25 PM, "Alan Bateman" > wrote: > > On 14/02/2013 17:55, mike.duigou at oracle.com > wrote: > > Changeset: e57019d2f34a > Author: mduigou > Date: 2013-02-13 14:50 -0800 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e57019d2f34a > > 8008167: IdentityHashMap.[keySet|values|entrySet].toArray speed-up > Reviewed-by: mduigou, martin > Contributed-by: Peter Levart > > > ! src/share/classes/java/util/IdentityHashMap.java > > A belated comment on this is that CME will now be thrown for cases > where it wasn't previously. We need to make sure this behavior > change is tracked (for release notes, etc.). > > -Alan > From Alan.Bateman at oracle.com Sun Feb 24 18:48:58 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 24 Feb 2013 18:48:58 +0000 Subject: hg: jdk8/tl/jdk: 8008167: IdentityHashMap.[keySet|values|entrySet].toArray speed-up In-Reply-To: <512A3689.3000900@gmail.com> References: <20130214175538.236EC47A96@hg.openjdk.java.net> <512A149D.3030204@oracle.com> <512A3689.3000900@gmail.com> Message-ID: <512A609A.10002@oracle.com> On 24/02/2013 15:49, Peter Levart wrote: > Hi Alan, > > I checked and it seems all 3 IHM views [keySet|values|entrySet] have a > fail-fast iterator implementation > (IdentityHashMap.IdentityHashMapIterator) and all 3 are (were) using > the iterator for .toArray implementations. So this patch tries to > preserve the behavior when there is a concurrent modification (which > is only possible from other thread and is illegal usage anyway since > IHM is not thread-safe) while executing the toArray methods on the > views... > > Do you see something I don't see? My apologies, I see it does check the modification count in IdentityHashMapIterator.nextIndex. However, as this forced me to looks at the changes-set again then the copy loop in Values.toArray has caught by eye: for (int si = 0; si < tab.length; si += 2) { if (tab[si++] != null) { // key present ? // more elements than expected -> concurrent modification from other thread if (ti >= size) { throw new ConcurrentModificationException(); } a[ti++] = (T) tab[si]; // copy value } } Looks like si is incrementing by 3 rather than 2 (which ironically will cause a CME later because there will be fewer elements copied than expected). Do you concur? If so then we can create a bug to change this to test tab[si] and copy in tab[si+1]. -Alan From mike.duigou at oracle.com Sun Feb 24 18:53:10 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Sun, 24 Feb 2013 10:53:10 -0800 Subject: hg: jdk8/tl/jdk: 8008167: IdentityHashMap.[keySet|values|entrySet].toArray speed-up In-Reply-To: <512A609A.10002@oracle.com> References: <20130214175538.236EC47A96@hg.openjdk.java.net> <512A149D.3030204@oracle.com> <512A3689.3000900@gmail.com> <512A609A.10002@oracle.com> Message-ID: <03FC4A5C-AF4D-45A2-908C-CFAC0AEA562B@oracle.com> Ouch, this would have been introduced by me. I will check to see how this could have passed the pre-commit regression testing. I suspect that a regression test needs to be improved. Mike On Feb 24 2013, at 10:48 , Alan Bateman wrote: > On 24/02/2013 15:49, Peter Levart wrote: >> >> Hi Alan, >> >> I checked and it seems all 3 IHM views [keySet|values|entrySet] have a fail-fast iterator implementation (IdentityHashMap.IdentityHashMapIterator) and all 3 are (were) using the iterator for .toArray implementations. So this patch tries to preserve the behavior when there is a concurrent modification (which is only possible from other thread and is illegal usage anyway since IHM is not thread-safe) while executing the toArray methods on the views... >> >> Do you see something I don't see? > My apologies, I see it does check the modification count in IdentityHashMapIterator.nextIndex. > > However, as this forced me to looks at the changes-set again then the copy loop in Values.toArray has caught by eye: > > for (int si = 0; si < tab.length; si += 2) { > if (tab[si++] != null) { // key present ? > // more elements than expected -> concurrent modification from other thread > if (ti >= size) { > throw new ConcurrentModificationException(); > } > a[ti++] = (T) tab[si]; // copy value > } > } > > Looks like si is incrementing by 3 rather than 2 (which ironically will cause a CME later because there will be fewer elements copied than expected). > > Do you concur? If so then we can create a bug to change this to test tab[si] and copy in tab[si+1]. > > -Alan From jonathan.gibbons at oracle.com Sun Feb 24 19:38:23 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sun, 24 Feb 2013 19:38:23 +0000 Subject: hg: jdk8/tl/langtools: 7112427: The doclet needs to be able to generate JavaFX documentation. Message-ID: <20130224193826.A335947DEC@hg.openjdk.java.net> Changeset: ccbe7ffdd867 Author: jjg Date: 2013-02-24 11:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ccbe7ffdd867 7112427: The doclet needs to be able to generate JavaFX documentation. Reviewed-by: jjg Contributed-by: jan.valenta at oracle.com ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java + src/share/classes/com/sun/tools/doclets/formats/html/PropertyWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlConstants.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/PropertyWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/WriterFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PropertyBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties + src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BasePropertyTaglet.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ExpertTaglet.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/PropertyGetterTaglet.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/PropertySetterTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/IndexBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java + test/com/sun/javadoc/testJavaFX/C.java + test/com/sun/javadoc/testJavaFX/D.java + test/com/sun/javadoc/testJavaFX/TestJavaFX.java ! test/com/sun/javadoc/testLambdaFeature/TestLambdaFeature.java From peter.levart at gmail.com Sun Feb 24 20:18:27 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 24 Feb 2013 21:18:27 +0100 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <5129EBE5.1030207@oracle.com> References: <5115316A.8050109@oracle.com> <51291AEB.3040005@gmail.com> <5129534A.8000500@oracle.com> <5129D45A.6010802@gmail.com> <5129EBE5.1030207@oracle.com> Message-ID: <512A7593.7040807@gmail.com> Hi Alan, David, Nils, I just want to clear something regarding PerfCounter implementation. Access to 64bit value in native memory is through a direct buffer which uses normal read/write (non-volatile, Unsafe.[get|set]Long). So on processors that don't support atomic 64bit stores/loads, each access results in two separate 32bit load/store accesses right? The PerfCounter methods that access the 64bit value are synchronized, using PerfCounter instance as a lock. But how is this 64bit value accessed for example in the jstat utility? Is it possible that jstat can see one half of the 64bit value before the update and the other half after the update? If this is true and it is not that important, then instead of a synchronized update of 64bit counter, a 32bit CAS could be used, optionally (rarely) followed by a second 32bit CAS, like for example: http://dl.dropbox.com/u/101777488/jdk8-tl/PerfCounter/webrev.01/index.html I tried this on ARM v6 and it works much better than synchronized access, but I don't know if it's acceptable. It guarantees eventual correctness of summed value if the only operation performed is add() (no set() intermingled) and has the same possibility of incorrect half-half reads by observers as current PerfCounter has for unsynchronized observers. Here's the comparison of unpatched/patched PerfCounter.increment() micro-benchmark on single-core ARM v6 (Raspbery-PI): *** Original PerfCounter, ARM v6 # # PerfCounter_increment: run duration: 5,000 ms, #of logical CPUS: 1 # 1 threads, Tavg = 269.34 ns/op (? = 0.00 ns/op) [ 269.34] 2 threads, Tavg = 7,170.48 ns/op (? = 410.77 ns/op) [ 6,783.73, 7,603.95] 3 threads, Tavg = 12,034.82 ns/op (? = 418.99 ns/op) [11,792.33, 11,714.67, 12,639.26] 4 threads, Tavg = 16,029.76 ns/op (? = 1,411.44 ns/op) [15,592.04, 18,511.52, 15,642.52, 14,818.16] *** Patched PerfCounter, ARM v6 # # PerfCounter_increment: run duration: 5,000 ms, #of logical CPUS: 1 # 1 threads, Tavg = 166.21 ns/op (? = 0.00 ns/op) [ 166.21] 2 threads, Tavg = 332.58 ns/op (? = 0.12 ns/op) [ 332.45, 332.70] 3 threads, Tavg = 500.30 ns/op (? = 0.22 ns/op) [ 500.04, 500.29, 500.58] 4 threads, Tavg = 667.95 ns/op (? = 2.11 ns/op) [ 665.22, 667.18, 668.40, 671.04] Regards, Peter On 02/24/2013 11:31 AM, David Holmes wrote: > On 24/02/2013 6:50 PM, Peter Levart wrote: >> Hi David, >> >> I thought it was ok to pass null, but I don't know the "portability" >> issues in-depth. The javadoc for Unsafe says: >> >> /"This method refers to a variable by means of two parameters, and so it >> provides (in effect) a double-register addressing mode for Java >> variables. When the object reference is null, this method uses its >> offset as an absolute address. This is similar in operation to methods >> such as getInt(long), which provide (in effect) a single-register >> addressing mode for non-Java variables. However, because Java variables >> may have a different layout in memory from non-Java variables, >> programmers should not assume that these two addressing modes are ever >> equivalent. Also, programmers should remember that offsets from the >> double-register addressing mode cannot be portably confused with longs >> used in the single-register addressing mode."/ > > That is the doc for getXXX but not for getAndAddXXX or > compareAndSwapXXX. You can't have null here: > > UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapLong(JNIEnv *env, jobject > unsafe, jobject obj, jlong offset, jlong e, jlong x)) > UnsafeWrapper("Unsafe_CompareAndSwapLong"); > Handle p (THREAD, JNIHandles::resolve(obj)); > jlong* addr = (jlong*)(index_oop_from_field_offset_long(p(), offset)); > if (VM_Version::supports_cx8()) > return (jlong)(Atomic::cmpxchg(x, addr, e)) == e; > else { > jboolean success = false; > ObjectLocker ol(p, THREAD); > if (*addr == e) { *addr = x; success = true; } > return success; > } > UNSAFE_END > > David > ----- > > >> Does anybody know the in-depth interpretation of the above? Is it only >> the particular Java/native type differences (for example, endianess of >> variables) that these two addressing modes might interpret differently >> or something else too? >> >> Regards, Peter >> >> >> On 02/24/2013 12:39 AM, David Holmes wrote: >>> Peter, >>> >>> In your use of Unsafe you pass "null" as the object. I'm pretty >>> certain you can't pass null here. Unsafe operates on fields or array >>> elements. >>> >>> David >>> >>> On 24/02/2013 5:39 AM, Peter Levart wrote: >>>> Hi Nils, >>>> >>>> If the counters are updated frequently from multiple threads, there >>>> might be contention/scalability issues. Instead of synchronization on >>>> updates, you might consider using atomic updates provided by >>>> sun.misc.Unsafe, like for example: >>>> >>>> >>>> Index: jdk/src/share/classes/sun/misc/PerfCounter.java >>>> =================================================================== >>>> --- jdk/src/share/classes/sun/misc/PerfCounter.java >>>> +++ jdk/src/share/classes/sun/misc/PerfCounter.java >>>> @@ -25,6 +25,8 @@ >>>> >>>> package sun.misc; >>>> >>>> +import sun.nio.ch.DirectBuffer; >>>> + >>>> import java.nio.ByteBuffer; >>>> import java.nio.ByteOrder; >>>> import java.nio.LongBuffer; >>>> @@ -50,6 +52,8 @@ >>>> public class PerfCounter { >>>> private static final Perf perf = >>>> AccessController.doPrivileged(new Perf.GetPerfAction()); >>>> + private static final Unsafe unsafe = >>>> + Unsafe.getUnsafe(); >>>> >>>> // Must match values defined in >>>> hotspot/src/share/vm/runtime/perfdata.hpp >>>> private final static int V_Constant = 1; >>>> @@ -59,12 +63,14 @@ >>>> >>>> private final String name; >>>> private final LongBuffer lb; >>>> + private final DirectBuffer db; >>>> >>>> private PerfCounter(String name, int type) { >>>> this.name = name; >>>> ByteBuffer bb = perf.createLong(name, U_None, type, 0L); >>>> bb.order(ByteOrder.nativeOrder()); >>>> this.lb = bb.asLongBuffer(); >>>> + this.db = bb instanceof DirectBuffer ? (DirectBuffer) bb : >>>> null; >>>> } >>>> >>>> static PerfCounter newPerfCounter(String name) { >>>> @@ -79,23 +85,44 @@ >>>> /** >>>> * Returns the current value of the perf counter. >>>> */ >>>> - public synchronized long get() { >>>> + public long get() { >>>> + if (db != null) { >>>> + return unsafe.getLongVolatile(null, db.address()); >>>> + } >>>> + else { >>>> + synchronized (this) { >>>> - return lb.get(0); >>>> - } >>>> + return lb.get(0); >>>> + } >>>> + } >>>> + } >>>> >>>> /** >>>> * Sets the value of the perf counter to the given newValue. >>>> */ >>>> - public synchronized void set(long newValue) { >>>> + public void set(long newValue) { >>>> + if (db != null) { >>>> + unsafe.putOrderedLong(null, db.address(), newValue); >>>> + } >>>> + else { >>>> + synchronized (this) { >>>> - lb.put(0, newValue); >>>> - } >>>> + lb.put(0, newValue); >>>> + } >>>> + } >>>> + } >>>> >>>> /** >>>> * Adds the given value to the perf counter. >>>> */ >>>> - public synchronized void add(long value) { >>>> - long res = get() + value; >>>> + public void add(long value) { >>>> + if (db != null) { >>>> + unsafe.getAndAddLong(null, db.address(), value); >>>> + } >>>> + else { >>>> + synchronized (this) { >>>> + long res = lb.get(0) + value; >>>> - lb.put(0, res); >>>> + lb.put(0, res); >>>> + } >>>> + } >>>> } >>>> >>>> /** >>>> >>>> >>>> >>>> Testing the PerfCounter.increment() method in a loop on multiple >>>> threads >>>> sharing the same PerfCounter instance, for example, on a 4-core >>>> Intel i7 >>>> machine produces the following results: >>>> >>>> # >>>> # PerfCounter_increment: run duration: 5,000 ms, #of logical CPUS: 8 >>>> # >>>> 1 threads, Tavg = 19.02 ns/op (? = 0.00 ns/op) >>>> 2 threads, Tavg = 109.93 ns/op (? = 6.17 ns/op) >>>> 3 threads, Tavg = 136.64 ns/op (? = 2.99 ns/op) >>>> 4 threads, Tavg = 293.26 ns/op (? = 5.30 ns/op) >>>> 5 threads, Tavg = 316.94 ns/op (? = 6.28 ns/op) >>>> 6 threads, Tavg = 686.96 ns/op (? = 7.09 ns/op) >>>> 7 threads, Tavg = 793.28 ns/op (? = 10.57 ns/op) >>>> 8 threads, Tavg = 898.15 ns/op (? = 14.63 ns/op) >>>> >>>> >>>> With the presented patch, the results are a little better: >>>> >>>> # >>>> # PerfCounter_increment: run duration: 5,000 ms, #of logical CPUS: 8 >>>> # >>>> # Measure: >>>> 1 threads, Tavg = 5.22 ns/op (? = 0.00 ns/op) >>>> 2 threads, Tavg = 34.51 ns/op (? = 0.60 ns/op) >>>> 3 threads, Tavg = 54.85 ns/op (? = 1.42 ns/op) >>>> 4 threads, Tavg = 74.67 ns/op (? = 1.71 ns/op) >>>> 5 threads, Tavg = 94.71 ns/op (? = 41.68 ns/op) >>>> 6 threads, Tavg = 114.80 ns/op (? = 32.10 ns/op) >>>> 7 threads, Tavg = 136.70 ns/op (? = 26.80 ns/op) >>>> 8 threads, Tavg = 158.48 ns/op (? = 9.93 ns/op) >>>> >>>> >>>> The scalability is not much better, but the raw speed is, so it might >>>> present less contention when used in real-world code. If you wanted >>>> even >>>> better scalability, there is a new class in JDK8, the >>>> java.util.concurrent.LongAdder. But that doesn't buy atomic "set()" - >>>> only "add()". And it can't update native-memory variables, so it could >>>> only be used for add-only counters and in conjunction with a >>>> background >>>> thread that would periodically flush the sum to the native memory.... >>>> >>>> Regards, Peter >>>> >>>> >>>> On 02/08/2013 06:10 PM, Nils Loodin wrote: >>>>> It would be interesting to know the number of thrown throwables in >>>>> the >>>>> JVM, to be able to do some high level application diagnostics / >>>>> statistics. A good way to put this number would be a performance >>>>> counter, since it is accessible both from Java and from the VM. >>>>> >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007806 >>>>> http://cr.openjdk.java.net/~nloodin/8007806/webrev.00/ >>>>> >>>>> Regards, >>>>> Nils Loodin >>>> >> From peter.levart at gmail.com Sun Feb 24 20:27:47 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 24 Feb 2013 21:27:47 +0100 Subject: hg: jdk8/tl/jdk: 8008167: IdentityHashMap.[keySet|values|entrySet].toArray speed-up In-Reply-To: <03FC4A5C-AF4D-45A2-908C-CFAC0AEA562B@oracle.com> References: <20130214175538.236EC47A96@hg.openjdk.java.net> <512A149D.3030204@oracle.com> <512A3689.3000900@gmail.com> <512A609A.10002@oracle.com> <03FC4A5C-AF4D-45A2-908C-CFAC0AEA562B@oracle.com> Message-ID: <512A77C3.9070902@gmail.com> Hi Mike, I thought I saw that too when you commited the change, but then re-examinig the whole source in detail, I couldn't spot it again. I must have stared at the wrong third of change... Regards, Peter On 02/24/2013 07:53 PM, Mike Duigou wrote: > Ouch, this would have been introduced by me. > > I will check to see how this could have passed the pre-commit regression testing. I suspect that a regression test needs to be improved. > > Mike > > On Feb 24 2013, at 10:48 , Alan Bateman wrote: > >> On 24/02/2013 15:49, Peter Levart wrote: >>> Hi Alan, >>> >>> I checked and it seems all 3 IHM views [keySet|values|entrySet] have a fail-fast iterator implementation (IdentityHashMap.IdentityHashMapIterator) and all 3 are (were) using the iterator for .toArray implementations. So this patch tries to preserve the behavior when there is a concurrent modification (which is only possible from other thread and is illegal usage anyway since IHM is not thread-safe) while executing the toArray methods on the views... >>> >>> Do you see something I don't see? >> My apologies, I see it does check the modification count in IdentityHashMapIterator.nextIndex. >> >> However, as this forced me to looks at the changes-set again then the copy loop in Values.toArray has caught by eye: >> >> for (int si = 0; si < tab.length; si += 2) { >> if (tab[si++] != null) { // key present ? >> // more elements than expected -> concurrent modification from other thread >> if (ti >= size) { >> throw new ConcurrentModificationException(); >> } >> a[ti++] = (T) tab[si]; // copy value >> } >> } >> >> Looks like si is incrementing by 3 rather than 2 (which ironically will cause a CME later because there will be fewer elements copied than expected). >> >> Do you concur? If so then we can create a bug to change this to test tab[si] and copy in tab[si+1]. >> >> -Alan From david.holmes at oracle.com Sun Feb 24 20:57:26 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Feb 2013 06:57:26 +1000 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <512A7593.7040807@gmail.com> References: <5115316A.8050109@oracle.com> <51291AEB.3040005@gmail.com> <5129534A.8000500@oracle.com> <5129D45A.6010802@gmail.com> <5129EBE5.1030207@oracle.com> <512A7593.7040807@gmail.com> Message-ID: <512A7EB6.8090503@oracle.com> On 25/02/2013 6:18 AM, Peter Levart wrote: > Hi Alan, David, Nils, > > I just want to clear something regarding PerfCounter implementation. > > Access to 64bit value in native memory is through a direct buffer which > uses normal read/write (non-volatile, Unsafe.[get|set]Long). So on > processors that don't support atomic 64bit stores/loads, each access > results in two separate 32bit load/store accesses right? Unsafe.get|setLong uses locking on those platforms. > The PerfCounter methods that access the 64bit value are synchronized, > using PerfCounter instance as a lock. But how is this 64bit value > accessed for example in the jstat utility? Is it possible that jstat can > see one half of the 64bit value before the update and the other half > after the update? Does jstat access these values directly or only via the synchronized methods? If the latter then the value can't be "torn" that way. The sync method will store the value in 2 32-bit registers, and the variable load in jstat will take two instructions, but nothing can touch those registers. David ----- > If this is true and it is not that important, then instead of a > synchronized update of 64bit counter, a 32bit CAS could be used, > optionally (rarely) followed by a second 32bit CAS, like for example: > > http://dl.dropbox.com/u/101777488/jdk8-tl/PerfCounter/webrev.01/index.html > > I tried this on ARM v6 and it works much better than synchronized > access, but I don't know if it's acceptable. It guarantees eventual > correctness of summed value if the only operation performed is add() (no > set() intermingled) and has the same possibility of incorrect half-half > reads by observers as current PerfCounter has for unsynchronized observers. > > Here's the comparison of unpatched/patched PerfCounter.increment() > micro-benchmark on single-core ARM v6 (Raspbery-PI): > > *** Original PerfCounter, ARM v6 > > # > # PerfCounter_increment: run duration: 5,000 ms, #of logical CPUS: 1 > # > 1 threads, Tavg = 269.34 ns/op (? = 0.00 ns/op) [ 269.34] > 2 threads, Tavg = 7,170.48 ns/op (? = 410.77 ns/op) [ > 6,783.73, 7,603.95] > 3 threads, Tavg = 12,034.82 ns/op (? = 418.99 ns/op) > [11,792.33, 11,714.67, 12,639.26] > 4 threads, Tavg = 16,029.76 ns/op (? = 1,411.44 ns/op) > [15,592.04, 18,511.52, 15,642.52, 14,818.16] > > > *** Patched PerfCounter, ARM v6 > > # > # PerfCounter_increment: run duration: 5,000 ms, #of logical CPUS: 1 > # > 1 threads, Tavg = 166.21 ns/op (? = 0.00 ns/op) [ 166.21] > 2 threads, Tavg = 332.58 ns/op (? = 0.12 ns/op) [ > 332.45, 332.70] > 3 threads, Tavg = 500.30 ns/op (? = 0.22 ns/op) [ > 500.04, 500.29, 500.58] > 4 threads, Tavg = 667.95 ns/op (? = 2.11 ns/op) [ > 665.22, 667.18, 668.40, 671.04] > > > Regards, Peter > > > On 02/24/2013 11:31 AM, David Holmes wrote: >> On 24/02/2013 6:50 PM, Peter Levart wrote: >>> Hi David, >>> >>> I thought it was ok to pass null, but I don't know the "portability" >>> issues in-depth. The javadoc for Unsafe says: >>> >>> /"This method refers to a variable by means of two parameters, and so it >>> provides (in effect) a double-register addressing mode for Java >>> variables. When the object reference is null, this method uses its >>> offset as an absolute address. This is similar in operation to methods >>> such as getInt(long), which provide (in effect) a single-register >>> addressing mode for non-Java variables. However, because Java variables >>> may have a different layout in memory from non-Java variables, >>> programmers should not assume that these two addressing modes are ever >>> equivalent. Also, programmers should remember that offsets from the >>> double-register addressing mode cannot be portably confused with longs >>> used in the single-register addressing mode."/ >> >> That is the doc for getXXX but not for getAndAddXXX or >> compareAndSwapXXX. You can't have null here: >> >> UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapLong(JNIEnv *env, jobject >> unsafe, jobject obj, jlong offset, jlong e, jlong x)) >> UnsafeWrapper("Unsafe_CompareAndSwapLong"); >> Handle p (THREAD, JNIHandles::resolve(obj)); >> jlong* addr = (jlong*)(index_oop_from_field_offset_long(p(), offset)); >> if (VM_Version::supports_cx8()) >> return (jlong)(Atomic::cmpxchg(x, addr, e)) == e; >> else { >> jboolean success = false; >> ObjectLocker ol(p, THREAD); >> if (*addr == e) { *addr = x; success = true; } >> return success; >> } >> UNSAFE_END >> >> David >> ----- >> >> >>> Does anybody know the in-depth interpretation of the above? Is it only >>> the particular Java/native type differences (for example, endianess of >>> variables) that these two addressing modes might interpret differently >>> or something else too? >>> >>> Regards, Peter >>> >>> >>> On 02/24/2013 12:39 AM, David Holmes wrote: >>>> Peter, >>>> >>>> In your use of Unsafe you pass "null" as the object. I'm pretty >>>> certain you can't pass null here. Unsafe operates on fields or array >>>> elements. >>>> >>>> David >>>> >>>> On 24/02/2013 5:39 AM, Peter Levart wrote: >>>>> Hi Nils, >>>>> >>>>> If the counters are updated frequently from multiple threads, there >>>>> might be contention/scalability issues. Instead of synchronization on >>>>> updates, you might consider using atomic updates provided by >>>>> sun.misc.Unsafe, like for example: >>>>> >>>>> >>>>> Index: jdk/src/share/classes/sun/misc/PerfCounter.java >>>>> =================================================================== >>>>> --- jdk/src/share/classes/sun/misc/PerfCounter.java >>>>> +++ jdk/src/share/classes/sun/misc/PerfCounter.java >>>>> @@ -25,6 +25,8 @@ >>>>> >>>>> package sun.misc; >>>>> >>>>> +import sun.nio.ch.DirectBuffer; >>>>> + >>>>> import java.nio.ByteBuffer; >>>>> import java.nio.ByteOrder; >>>>> import java.nio.LongBuffer; >>>>> @@ -50,6 +52,8 @@ >>>>> public class PerfCounter { >>>>> private static final Perf perf = >>>>> AccessController.doPrivileged(new Perf.GetPerfAction()); >>>>> + private static final Unsafe unsafe = >>>>> + Unsafe.getUnsafe(); >>>>> >>>>> // Must match values defined in >>>>> hotspot/src/share/vm/runtime/perfdata.hpp >>>>> private final static int V_Constant = 1; >>>>> @@ -59,12 +63,14 @@ >>>>> >>>>> private final String name; >>>>> private final LongBuffer lb; >>>>> + private final DirectBuffer db; >>>>> >>>>> private PerfCounter(String name, int type) { >>>>> this.name = name; >>>>> ByteBuffer bb = perf.createLong(name, U_None, type, 0L); >>>>> bb.order(ByteOrder.nativeOrder()); >>>>> this.lb = bb.asLongBuffer(); >>>>> + this.db = bb instanceof DirectBuffer ? (DirectBuffer) bb : >>>>> null; >>>>> } >>>>> >>>>> static PerfCounter newPerfCounter(String name) { >>>>> @@ -79,23 +85,44 @@ >>>>> /** >>>>> * Returns the current value of the perf counter. >>>>> */ >>>>> - public synchronized long get() { >>>>> + public long get() { >>>>> + if (db != null) { >>>>> + return unsafe.getLongVolatile(null, db.address()); >>>>> + } >>>>> + else { >>>>> + synchronized (this) { >>>>> - return lb.get(0); >>>>> - } >>>>> + return lb.get(0); >>>>> + } >>>>> + } >>>>> + } >>>>> >>>>> /** >>>>> * Sets the value of the perf counter to the given newValue. >>>>> */ >>>>> - public synchronized void set(long newValue) { >>>>> + public void set(long newValue) { >>>>> + if (db != null) { >>>>> + unsafe.putOrderedLong(null, db.address(), newValue); >>>>> + } >>>>> + else { >>>>> + synchronized (this) { >>>>> - lb.put(0, newValue); >>>>> - } >>>>> + lb.put(0, newValue); >>>>> + } >>>>> + } >>>>> + } >>>>> >>>>> /** >>>>> * Adds the given value to the perf counter. >>>>> */ >>>>> - public synchronized void add(long value) { >>>>> - long res = get() + value; >>>>> + public void add(long value) { >>>>> + if (db != null) { >>>>> + unsafe.getAndAddLong(null, db.address(), value); >>>>> + } >>>>> + else { >>>>> + synchronized (this) { >>>>> + long res = lb.get(0) + value; >>>>> - lb.put(0, res); >>>>> + lb.put(0, res); >>>>> + } >>>>> + } >>>>> } >>>>> >>>>> /** >>>>> >>>>> >>>>> >>>>> Testing the PerfCounter.increment() method in a loop on multiple >>>>> threads >>>>> sharing the same PerfCounter instance, for example, on a 4-core >>>>> Intel i7 >>>>> machine produces the following results: >>>>> >>>>> # >>>>> # PerfCounter_increment: run duration: 5,000 ms, #of logical CPUS: 8 >>>>> # >>>>> 1 threads, Tavg = 19.02 ns/op (? = 0.00 ns/op) >>>>> 2 threads, Tavg = 109.93 ns/op (? = 6.17 ns/op) >>>>> 3 threads, Tavg = 136.64 ns/op (? = 2.99 ns/op) >>>>> 4 threads, Tavg = 293.26 ns/op (? = 5.30 ns/op) >>>>> 5 threads, Tavg = 316.94 ns/op (? = 6.28 ns/op) >>>>> 6 threads, Tavg = 686.96 ns/op (? = 7.09 ns/op) >>>>> 7 threads, Tavg = 793.28 ns/op (? = 10.57 ns/op) >>>>> 8 threads, Tavg = 898.15 ns/op (? = 14.63 ns/op) >>>>> >>>>> >>>>> With the presented patch, the results are a little better: >>>>> >>>>> # >>>>> # PerfCounter_increment: run duration: 5,000 ms, #of logical CPUS: 8 >>>>> # >>>>> # Measure: >>>>> 1 threads, Tavg = 5.22 ns/op (? = 0.00 ns/op) >>>>> 2 threads, Tavg = 34.51 ns/op (? = 0.60 ns/op) >>>>> 3 threads, Tavg = 54.85 ns/op (? = 1.42 ns/op) >>>>> 4 threads, Tavg = 74.67 ns/op (? = 1.71 ns/op) >>>>> 5 threads, Tavg = 94.71 ns/op (? = 41.68 ns/op) >>>>> 6 threads, Tavg = 114.80 ns/op (? = 32.10 ns/op) >>>>> 7 threads, Tavg = 136.70 ns/op (? = 26.80 ns/op) >>>>> 8 threads, Tavg = 158.48 ns/op (? = 9.93 ns/op) >>>>> >>>>> >>>>> The scalability is not much better, but the raw speed is, so it might >>>>> present less contention when used in real-world code. If you wanted >>>>> even >>>>> better scalability, there is a new class in JDK8, the >>>>> java.util.concurrent.LongAdder. But that doesn't buy atomic "set()" - >>>>> only "add()". And it can't update native-memory variables, so it could >>>>> only be used for add-only counters and in conjunction with a >>>>> background >>>>> thread that would periodically flush the sum to the native memory.... >>>>> >>>>> Regards, Peter >>>>> >>>>> >>>>> On 02/08/2013 06:10 PM, Nils Loodin wrote: >>>>>> It would be interesting to know the number of thrown throwables in >>>>>> the >>>>>> JVM, to be able to do some high level application diagnostics / >>>>>> statistics. A good way to put this number would be a performance >>>>>> counter, since it is accessible both from Java and from the VM. >>>>>> >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007806 >>>>>> http://cr.openjdk.java.net/~nloodin/8007806/webrev.00/ >>>>>> >>>>>> Regards, >>>>>> Nils Loodin >>>>> >>> > From peter.levart at gmail.com Sun Feb 24 21:25:40 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 24 Feb 2013 22:25:40 +0100 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <512A7EB6.8090503@oracle.com> References: <5115316A.8050109@oracle.com> <51291AEB.3040005@gmail.com> <5129534A.8000500@oracle.com> <5129D45A.6010802@gmail.com> <5129EBE5.1030207@oracle.com> <512A7593.7040807@gmail.com> <512A7EB6.8090503@oracle.com> Message-ID: <512A8554.6080203@gmail.com> On 02/24/2013 09:57 PM, David Holmes wrote: > On 25/02/2013 6:18 AM, Peter Levart wrote: >> Hi Alan, David, Nils, >> >> I just want to clear something regarding PerfCounter implementation. >> >> Access to 64bit value in native memory is through a direct buffer which >> uses normal read/write (non-volatile, Unsafe.[get|set]Long). So on >> processors that don't support atomic 64bit stores/loads, each access >> results in two separate 32bit load/store accesses right? > > Unsafe.get|setLong uses locking on those platforms. Even if it does, it is important whether "all" accesses to this 64bit value are using locking and whether they are using the same lock. Aren't performance counters JVM native variables where just some of them happen to be updated from Java? > >> The PerfCounter methods that access the 64bit value are synchronized, >> using PerfCounter instance as a lock. But how is this 64bit value >> accessed for example in the jstat utility? Is it possible that jstat can >> see one half of the 64bit value before the update and the other half >> after the update? > > Does jstat access these values directly or only via the synchronized > methods? If the latter then the value can't be "torn" that way. The > sync method will store the value in 2 32-bit registers, and the > variable load in jstat will take two instructions, but nothing can > touch those registers. I'm not saying that the value could be corrupted in any way, just that the unsynchronized observer (like jstat) could see it "torn" sometimes. Regards, Peter > > David > ----- > >> If this is true and it is not that important, then instead of a >> synchronized update of 64bit counter, a 32bit CAS could be used, >> optionally (rarely) followed by a second 32bit CAS, like for example: >> >> http://dl.dropbox.com/u/101777488/jdk8-tl/PerfCounter/webrev.01/index.html >> >> >> I tried this on ARM v6 and it works much better than synchronized >> access, but I don't know if it's acceptable. It guarantees eventual >> correctness of summed value if the only operation performed is add() (no >> set() intermingled) and has the same possibility of incorrect half-half >> reads by observers as current PerfCounter has for unsynchronized >> observers. >> >> Here's the comparison of unpatched/patched PerfCounter.increment() >> micro-benchmark on single-core ARM v6 (Raspbery-PI): >> >> *** Original PerfCounter, ARM v6 >> >> # >> # PerfCounter_increment: run duration: 5,000 ms, #of logical CPUS: 1 >> # >> 1 threads, Tavg = 269.34 ns/op (? = 0.00 ns/op) [ >> 269.34] >> 2 threads, Tavg = 7,170.48 ns/op (? = 410.77 ns/op) [ >> 6,783.73, 7,603.95] >> 3 threads, Tavg = 12,034.82 ns/op (? = 418.99 ns/op) >> [11,792.33, 11,714.67, 12,639.26] >> 4 threads, Tavg = 16,029.76 ns/op (? = 1,411.44 ns/op) >> [15,592.04, 18,511.52, 15,642.52, 14,818.16] >> >> >> *** Patched PerfCounter, ARM v6 >> >> # >> # PerfCounter_increment: run duration: 5,000 ms, #of logical CPUS: 1 >> # >> 1 threads, Tavg = 166.21 ns/op (? = 0.00 ns/op) [ >> 166.21] >> 2 threads, Tavg = 332.58 ns/op (? = 0.12 ns/op) [ >> 332.45, 332.70] >> 3 threads, Tavg = 500.30 ns/op (? = 0.22 ns/op) [ >> 500.04, 500.29, 500.58] >> 4 threads, Tavg = 667.95 ns/op (? = 2.11 ns/op) [ >> 665.22, 667.18, 668.40, 671.04] >> >> >> Regards, Peter >> >> >> On 02/24/2013 11:31 AM, David Holmes wrote: >>> On 24/02/2013 6:50 PM, Peter Levart wrote: >>>> Hi David, >>>> >>>> I thought it was ok to pass null, but I don't know the "portability" >>>> issues in-depth. The javadoc for Unsafe says: >>>> >>>> /"This method refers to a variable by means of two parameters, and >>>> so it >>>> provides (in effect) a double-register addressing mode for Java >>>> variables. When the object reference is null, this method uses its >>>> offset as an absolute address. This is similar in operation to methods >>>> such as getInt(long), which provide (in effect) a single-register >>>> addressing mode for non-Java variables. However, because Java >>>> variables >>>> may have a different layout in memory from non-Java variables, >>>> programmers should not assume that these two addressing modes are ever >>>> equivalent. Also, programmers should remember that offsets from the >>>> double-register addressing mode cannot be portably confused with longs >>>> used in the single-register addressing mode."/ >>> >>> That is the doc for getXXX but not for getAndAddXXX or >>> compareAndSwapXXX. You can't have null here: >>> >>> UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapLong(JNIEnv *env, jobject >>> unsafe, jobject obj, jlong offset, jlong e, jlong x)) >>> UnsafeWrapper("Unsafe_CompareAndSwapLong"); >>> Handle p (THREAD, JNIHandles::resolve(obj)); >>> jlong* addr = (jlong*)(index_oop_from_field_offset_long(p(), >>> offset)); >>> if (VM_Version::supports_cx8()) >>> return (jlong)(Atomic::cmpxchg(x, addr, e)) == e; >>> else { >>> jboolean success = false; >>> ObjectLocker ol(p, THREAD); >>> if (*addr == e) { *addr = x; success = true; } >>> return success; >>> } >>> UNSAFE_END >>> >>> David >>> ----- >>> >>> >>>> Does anybody know the in-depth interpretation of the above? Is it only >>>> the particular Java/native type differences (for example, endianess of >>>> variables) that these two addressing modes might interpret differently >>>> or something else too? >>>> >>>> Regards, Peter >>>> >>>> >>>> On 02/24/2013 12:39 AM, David Holmes wrote: >>>>> Peter, >>>>> >>>>> In your use of Unsafe you pass "null" as the object. I'm pretty >>>>> certain you can't pass null here. Unsafe operates on fields or array >>>>> elements. >>>>> >>>>> David >>>>> >>>>> On 24/02/2013 5:39 AM, Peter Levart wrote: >>>>>> Hi Nils, >>>>>> >>>>>> If the counters are updated frequently from multiple threads, there >>>>>> might be contention/scalability issues. Instead of >>>>>> synchronization on >>>>>> updates, you might consider using atomic updates provided by >>>>>> sun.misc.Unsafe, like for example: >>>>>> >>>>>> >>>>>> Index: jdk/src/share/classes/sun/misc/PerfCounter.java >>>>>> =================================================================== >>>>>> --- jdk/src/share/classes/sun/misc/PerfCounter.java >>>>>> +++ jdk/src/share/classes/sun/misc/PerfCounter.java >>>>>> @@ -25,6 +25,8 @@ >>>>>> >>>>>> package sun.misc; >>>>>> >>>>>> +import sun.nio.ch.DirectBuffer; >>>>>> + >>>>>> import java.nio.ByteBuffer; >>>>>> import java.nio.ByteOrder; >>>>>> import java.nio.LongBuffer; >>>>>> @@ -50,6 +52,8 @@ >>>>>> public class PerfCounter { >>>>>> private static final Perf perf = >>>>>> AccessController.doPrivileged(new Perf.GetPerfAction()); >>>>>> + private static final Unsafe unsafe = >>>>>> + Unsafe.getUnsafe(); >>>>>> >>>>>> // Must match values defined in >>>>>> hotspot/src/share/vm/runtime/perfdata.hpp >>>>>> private final static int V_Constant = 1; >>>>>> @@ -59,12 +63,14 @@ >>>>>> >>>>>> private final String name; >>>>>> private final LongBuffer lb; >>>>>> + private final DirectBuffer db; >>>>>> >>>>>> private PerfCounter(String name, int type) { >>>>>> this.name = name; >>>>>> ByteBuffer bb = perf.createLong(name, U_None, type, 0L); >>>>>> bb.order(ByteOrder.nativeOrder()); >>>>>> this.lb = bb.asLongBuffer(); >>>>>> + this.db = bb instanceof DirectBuffer ? (DirectBuffer) bb : >>>>>> null; >>>>>> } >>>>>> >>>>>> static PerfCounter newPerfCounter(String name) { >>>>>> @@ -79,23 +85,44 @@ >>>>>> /** >>>>>> * Returns the current value of the perf counter. >>>>>> */ >>>>>> - public synchronized long get() { >>>>>> + public long get() { >>>>>> + if (db != null) { >>>>>> + return unsafe.getLongVolatile(null, db.address()); >>>>>> + } >>>>>> + else { >>>>>> + synchronized (this) { >>>>>> - return lb.get(0); >>>>>> - } >>>>>> + return lb.get(0); >>>>>> + } >>>>>> + } >>>>>> + } >>>>>> >>>>>> /** >>>>>> * Sets the value of the perf counter to the given newValue. >>>>>> */ >>>>>> - public synchronized void set(long newValue) { >>>>>> + public void set(long newValue) { >>>>>> + if (db != null) { >>>>>> + unsafe.putOrderedLong(null, db.address(), newValue); >>>>>> + } >>>>>> + else { >>>>>> + synchronized (this) { >>>>>> - lb.put(0, newValue); >>>>>> - } >>>>>> + lb.put(0, newValue); >>>>>> + } >>>>>> + } >>>>>> + } >>>>>> >>>>>> /** >>>>>> * Adds the given value to the perf counter. >>>>>> */ >>>>>> - public synchronized void add(long value) { >>>>>> - long res = get() + value; >>>>>> + public void add(long value) { >>>>>> + if (db != null) { >>>>>> + unsafe.getAndAddLong(null, db.address(), value); >>>>>> + } >>>>>> + else { >>>>>> + synchronized (this) { >>>>>> + long res = lb.get(0) + value; >>>>>> - lb.put(0, res); >>>>>> + lb.put(0, res); >>>>>> + } >>>>>> + } >>>>>> } >>>>>> >>>>>> /** >>>>>> >>>>>> >>>>>> >>>>>> Testing the PerfCounter.increment() method in a loop on multiple >>>>>> threads >>>>>> sharing the same PerfCounter instance, for example, on a 4-core >>>>>> Intel i7 >>>>>> machine produces the following results: >>>>>> >>>>>> # >>>>>> # PerfCounter_increment: run duration: 5,000 ms, #of logical >>>>>> CPUS: 8 >>>>>> # >>>>>> 1 threads, Tavg = 19.02 ns/op (? = 0.00 ns/op) >>>>>> 2 threads, Tavg = 109.93 ns/op (? = 6.17 ns/op) >>>>>> 3 threads, Tavg = 136.64 ns/op (? = 2.99 ns/op) >>>>>> 4 threads, Tavg = 293.26 ns/op (? = 5.30 ns/op) >>>>>> 5 threads, Tavg = 316.94 ns/op (? = 6.28 ns/op) >>>>>> 6 threads, Tavg = 686.96 ns/op (? = 7.09 ns/op) >>>>>> 7 threads, Tavg = 793.28 ns/op (? = 10.57 ns/op) >>>>>> 8 threads, Tavg = 898.15 ns/op (? = 14.63 ns/op) >>>>>> >>>>>> >>>>>> With the presented patch, the results are a little better: >>>>>> >>>>>> # >>>>>> # PerfCounter_increment: run duration: 5,000 ms, #of logical >>>>>> CPUS: 8 >>>>>> # >>>>>> # Measure: >>>>>> 1 threads, Tavg = 5.22 ns/op (? = 0.00 ns/op) >>>>>> 2 threads, Tavg = 34.51 ns/op (? = 0.60 ns/op) >>>>>> 3 threads, Tavg = 54.85 ns/op (? = 1.42 ns/op) >>>>>> 4 threads, Tavg = 74.67 ns/op (? = 1.71 ns/op) >>>>>> 5 threads, Tavg = 94.71 ns/op (? = 41.68 ns/op) >>>>>> 6 threads, Tavg = 114.80 ns/op (? = 32.10 ns/op) >>>>>> 7 threads, Tavg = 136.70 ns/op (? = 26.80 ns/op) >>>>>> 8 threads, Tavg = 158.48 ns/op (? = 9.93 ns/op) >>>>>> >>>>>> >>>>>> The scalability is not much better, but the raw speed is, so it >>>>>> might >>>>>> present less contention when used in real-world code. If you wanted >>>>>> even >>>>>> better scalability, there is a new class in JDK8, the >>>>>> java.util.concurrent.LongAdder. But that doesn't buy atomic >>>>>> "set()" - >>>>>> only "add()". And it can't update native-memory variables, so it >>>>>> could >>>>>> only be used for add-only counters and in conjunction with a >>>>>> background >>>>>> thread that would periodically flush the sum to the native >>>>>> memory.... >>>>>> >>>>>> Regards, Peter >>>>>> >>>>>> >>>>>> On 02/08/2013 06:10 PM, Nils Loodin wrote: >>>>>>> It would be interesting to know the number of thrown throwables in >>>>>>> the >>>>>>> JVM, to be able to do some high level application diagnostics / >>>>>>> statistics. A good way to put this number would be a performance >>>>>>> counter, since it is accessible both from Java and from the VM. >>>>>>> >>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007806 >>>>>>> http://cr.openjdk.java.net/~nloodin/8007806/webrev.00/ >>>>>>> >>>>>>> Regards, >>>>>>> Nils Loodin >>>>>> >>>> >> From david.holmes at oracle.com Sun Feb 24 21:48:50 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Feb 2013 07:48:50 +1000 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <512A8554.6080203@gmail.com> References: <5115316A.8050109@oracle.com> <51291AEB.3040005@gmail.com> <5129534A.8000500@oracle.com> <5129D45A.6010802@gmail.com> <5129EBE5.1030207@oracle.com> <512A7593.7040807@gmail.com> <512A7EB6.8090503@oracle.com> <512A8554.6080203@gmail.com> Message-ID: <512A8AC2.9020800@oracle.com> Peter, On 25/02/2013 7:25 AM, Peter Levart wrote: > > On 02/24/2013 09:57 PM, David Holmes wrote: >> On 25/02/2013 6:18 AM, Peter Levart wrote: >>> Hi Alan, David, Nils, >>> >>> I just want to clear something regarding PerfCounter implementation. >>> >>> Access to 64bit value in native memory is through a direct buffer which >>> uses normal read/write (non-volatile, Unsafe.[get|set]Long). So on >>> processors that don't support atomic 64bit stores/loads, each access >>> results in two separate 32bit load/store accesses right? >> >> Unsafe.get|setLong uses locking on those platforms. > > Even if it does, it is important whether "all" accesses to this 64bit > value are using locking and whether they are using the same lock. Aren't > performance counters JVM native variables where just some of them happen > to be updated from Java? AFAICS PerfCounters have no thread-safety properties or guarantees. So it is up to the user of each counter to use it in an appropriate way. I think the serviceability folk would have to chime in here as to how PerfCounters are supposed to be used. >>> The PerfCounter methods that access the 64bit value are synchronized, >>> using PerfCounter instance as a lock. But how is this 64bit value >>> accessed for example in the jstat utility? Is it possible that jstat can >>> see one half of the 64bit value before the update and the other half >>> after the update? >> >> Does jstat access these values directly or only via the synchronized >> methods? If the latter then the value can't be "torn" that way. The >> sync method will store the value in 2 32-bit registers, and the >> variable load in jstat will take two instructions, but nothing can >> touch those registers. > > I'm not saying that the value could be corrupted in any way, just that > the unsynchronized observer (like jstat) could see it "torn" sometimes. If the value is initially read in a sync block and all updates are also synchronized, then I don't think it can. But you need to look at actual code to determine this. David > Regards, Peter > >> >> David >> ----- >> >>> If this is true and it is not that important, then instead of a >>> synchronized update of 64bit counter, a 32bit CAS could be used, >>> optionally (rarely) followed by a second 32bit CAS, like for example: >>> >>> http://dl.dropbox.com/u/101777488/jdk8-tl/PerfCounter/webrev.01/index.html >>> >>> >>> I tried this on ARM v6 and it works much better than synchronized >>> access, but I don't know if it's acceptable. It guarantees eventual >>> correctness of summed value if the only operation performed is add() (no >>> set() intermingled) and has the same possibility of incorrect half-half >>> reads by observers as current PerfCounter has for unsynchronized >>> observers. >>> >>> Here's the comparison of unpatched/patched PerfCounter.increment() >>> micro-benchmark on single-core ARM v6 (Raspbery-PI): >>> >>> *** Original PerfCounter, ARM v6 >>> >>> # >>> # PerfCounter_increment: run duration: 5,000 ms, #of logical CPUS: 1 >>> # >>> 1 threads, Tavg = 269.34 ns/op (? = 0.00 ns/op) [ >>> 269.34] >>> 2 threads, Tavg = 7,170.48 ns/op (? = 410.77 ns/op) [ >>> 6,783.73, 7,603.95] >>> 3 threads, Tavg = 12,034.82 ns/op (? = 418.99 ns/op) >>> [11,792.33, 11,714.67, 12,639.26] >>> 4 threads, Tavg = 16,029.76 ns/op (? = 1,411.44 ns/op) >>> [15,592.04, 18,511.52, 15,642.52, 14,818.16] >>> >>> >>> *** Patched PerfCounter, ARM v6 >>> >>> # >>> # PerfCounter_increment: run duration: 5,000 ms, #of logical CPUS: 1 >>> # >>> 1 threads, Tavg = 166.21 ns/op (? = 0.00 ns/op) [ >>> 166.21] >>> 2 threads, Tavg = 332.58 ns/op (? = 0.12 ns/op) [ >>> 332.45, 332.70] >>> 3 threads, Tavg = 500.30 ns/op (? = 0.22 ns/op) [ >>> 500.04, 500.29, 500.58] >>> 4 threads, Tavg = 667.95 ns/op (? = 2.11 ns/op) [ >>> 665.22, 667.18, 668.40, 671.04] >>> >>> >>> Regards, Peter >>> >>> >>> On 02/24/2013 11:31 AM, David Holmes wrote: >>>> On 24/02/2013 6:50 PM, Peter Levart wrote: >>>>> Hi David, >>>>> >>>>> I thought it was ok to pass null, but I don't know the "portability" >>>>> issues in-depth. The javadoc for Unsafe says: >>>>> >>>>> /"This method refers to a variable by means of two parameters, and >>>>> so it >>>>> provides (in effect) a double-register addressing mode for Java >>>>> variables. When the object reference is null, this method uses its >>>>> offset as an absolute address. This is similar in operation to methods >>>>> such as getInt(long), which provide (in effect) a single-register >>>>> addressing mode for non-Java variables. However, because Java >>>>> variables >>>>> may have a different layout in memory from non-Java variables, >>>>> programmers should not assume that these two addressing modes are ever >>>>> equivalent. Also, programmers should remember that offsets from the >>>>> double-register addressing mode cannot be portably confused with longs >>>>> used in the single-register addressing mode."/ >>>> >>>> That is the doc for getXXX but not for getAndAddXXX or >>>> compareAndSwapXXX. You can't have null here: >>>> >>>> UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapLong(JNIEnv *env, jobject >>>> unsafe, jobject obj, jlong offset, jlong e, jlong x)) >>>> UnsafeWrapper("Unsafe_CompareAndSwapLong"); >>>> Handle p (THREAD, JNIHandles::resolve(obj)); >>>> jlong* addr = (jlong*)(index_oop_from_field_offset_long(p(), >>>> offset)); >>>> if (VM_Version::supports_cx8()) >>>> return (jlong)(Atomic::cmpxchg(x, addr, e)) == e; >>>> else { >>>> jboolean success = false; >>>> ObjectLocker ol(p, THREAD); >>>> if (*addr == e) { *addr = x; success = true; } >>>> return success; >>>> } >>>> UNSAFE_END >>>> >>>> David >>>> ----- >>>> >>>> >>>>> Does anybody know the in-depth interpretation of the above? Is it only >>>>> the particular Java/native type differences (for example, endianess of >>>>> variables) that these two addressing modes might interpret differently >>>>> or something else too? >>>>> >>>>> Regards, Peter >>>>> >>>>> >>>>> On 02/24/2013 12:39 AM, David Holmes wrote: >>>>>> Peter, >>>>>> >>>>>> In your use of Unsafe you pass "null" as the object. I'm pretty >>>>>> certain you can't pass null here. Unsafe operates on fields or array >>>>>> elements. >>>>>> >>>>>> David >>>>>> >>>>>> On 24/02/2013 5:39 AM, Peter Levart wrote: >>>>>>> Hi Nils, >>>>>>> >>>>>>> If the counters are updated frequently from multiple threads, there >>>>>>> might be contention/scalability issues. Instead of >>>>>>> synchronization on >>>>>>> updates, you might consider using atomic updates provided by >>>>>>> sun.misc.Unsafe, like for example: >>>>>>> >>>>>>> >>>>>>> Index: jdk/src/share/classes/sun/misc/PerfCounter.java >>>>>>> =================================================================== >>>>>>> --- jdk/src/share/classes/sun/misc/PerfCounter.java >>>>>>> +++ jdk/src/share/classes/sun/misc/PerfCounter.java >>>>>>> @@ -25,6 +25,8 @@ >>>>>>> >>>>>>> package sun.misc; >>>>>>> >>>>>>> +import sun.nio.ch.DirectBuffer; >>>>>>> + >>>>>>> import java.nio.ByteBuffer; >>>>>>> import java.nio.ByteOrder; >>>>>>> import java.nio.LongBuffer; >>>>>>> @@ -50,6 +52,8 @@ >>>>>>> public class PerfCounter { >>>>>>> private static final Perf perf = >>>>>>> AccessController.doPrivileged(new Perf.GetPerfAction()); >>>>>>> + private static final Unsafe unsafe = >>>>>>> + Unsafe.getUnsafe(); >>>>>>> >>>>>>> // Must match values defined in >>>>>>> hotspot/src/share/vm/runtime/perfdata.hpp >>>>>>> private final static int V_Constant = 1; >>>>>>> @@ -59,12 +63,14 @@ >>>>>>> >>>>>>> private final String name; >>>>>>> private final LongBuffer lb; >>>>>>> + private final DirectBuffer db; >>>>>>> >>>>>>> private PerfCounter(String name, int type) { >>>>>>> this.name = name; >>>>>>> ByteBuffer bb = perf.createLong(name, U_None, type, 0L); >>>>>>> bb.order(ByteOrder.nativeOrder()); >>>>>>> this.lb = bb.asLongBuffer(); >>>>>>> + this.db = bb instanceof DirectBuffer ? (DirectBuffer) bb : >>>>>>> null; >>>>>>> } >>>>>>> >>>>>>> static PerfCounter newPerfCounter(String name) { >>>>>>> @@ -79,23 +85,44 @@ >>>>>>> /** >>>>>>> * Returns the current value of the perf counter. >>>>>>> */ >>>>>>> - public synchronized long get() { >>>>>>> + public long get() { >>>>>>> + if (db != null) { >>>>>>> + return unsafe.getLongVolatile(null, db.address()); >>>>>>> + } >>>>>>> + else { >>>>>>> + synchronized (this) { >>>>>>> - return lb.get(0); >>>>>>> - } >>>>>>> + return lb.get(0); >>>>>>> + } >>>>>>> + } >>>>>>> + } >>>>>>> >>>>>>> /** >>>>>>> * Sets the value of the perf counter to the given newValue. >>>>>>> */ >>>>>>> - public synchronized void set(long newValue) { >>>>>>> + public void set(long newValue) { >>>>>>> + if (db != null) { >>>>>>> + unsafe.putOrderedLong(null, db.address(), newValue); >>>>>>> + } >>>>>>> + else { >>>>>>> + synchronized (this) { >>>>>>> - lb.put(0, newValue); >>>>>>> - } >>>>>>> + lb.put(0, newValue); >>>>>>> + } >>>>>>> + } >>>>>>> + } >>>>>>> >>>>>>> /** >>>>>>> * Adds the given value to the perf counter. >>>>>>> */ >>>>>>> - public synchronized void add(long value) { >>>>>>> - long res = get() + value; >>>>>>> + public void add(long value) { >>>>>>> + if (db != null) { >>>>>>> + unsafe.getAndAddLong(null, db.address(), value); >>>>>>> + } >>>>>>> + else { >>>>>>> + synchronized (this) { >>>>>>> + long res = lb.get(0) + value; >>>>>>> - lb.put(0, res); >>>>>>> + lb.put(0, res); >>>>>>> + } >>>>>>> + } >>>>>>> } >>>>>>> >>>>>>> /** >>>>>>> >>>>>>> >>>>>>> >>>>>>> Testing the PerfCounter.increment() method in a loop on multiple >>>>>>> threads >>>>>>> sharing the same PerfCounter instance, for example, on a 4-core >>>>>>> Intel i7 >>>>>>> machine produces the following results: >>>>>>> >>>>>>> # >>>>>>> # PerfCounter_increment: run duration: 5,000 ms, #of logical >>>>>>> CPUS: 8 >>>>>>> # >>>>>>> 1 threads, Tavg = 19.02 ns/op (? = 0.00 ns/op) >>>>>>> 2 threads, Tavg = 109.93 ns/op (? = 6.17 ns/op) >>>>>>> 3 threads, Tavg = 136.64 ns/op (? = 2.99 ns/op) >>>>>>> 4 threads, Tavg = 293.26 ns/op (? = 5.30 ns/op) >>>>>>> 5 threads, Tavg = 316.94 ns/op (? = 6.28 ns/op) >>>>>>> 6 threads, Tavg = 686.96 ns/op (? = 7.09 ns/op) >>>>>>> 7 threads, Tavg = 793.28 ns/op (? = 10.57 ns/op) >>>>>>> 8 threads, Tavg = 898.15 ns/op (? = 14.63 ns/op) >>>>>>> >>>>>>> >>>>>>> With the presented patch, the results are a little better: >>>>>>> >>>>>>> # >>>>>>> # PerfCounter_increment: run duration: 5,000 ms, #of logical >>>>>>> CPUS: 8 >>>>>>> # >>>>>>> # Measure: >>>>>>> 1 threads, Tavg = 5.22 ns/op (? = 0.00 ns/op) >>>>>>> 2 threads, Tavg = 34.51 ns/op (? = 0.60 ns/op) >>>>>>> 3 threads, Tavg = 54.85 ns/op (? = 1.42 ns/op) >>>>>>> 4 threads, Tavg = 74.67 ns/op (? = 1.71 ns/op) >>>>>>> 5 threads, Tavg = 94.71 ns/op (? = 41.68 ns/op) >>>>>>> 6 threads, Tavg = 114.80 ns/op (? = 32.10 ns/op) >>>>>>> 7 threads, Tavg = 136.70 ns/op (? = 26.80 ns/op) >>>>>>> 8 threads, Tavg = 158.48 ns/op (? = 9.93 ns/op) >>>>>>> >>>>>>> >>>>>>> The scalability is not much better, but the raw speed is, so it >>>>>>> might >>>>>>> present less contention when used in real-world code. If you wanted >>>>>>> even >>>>>>> better scalability, there is a new class in JDK8, the >>>>>>> java.util.concurrent.LongAdder. But that doesn't buy atomic >>>>>>> "set()" - >>>>>>> only "add()". And it can't update native-memory variables, so it >>>>>>> could >>>>>>> only be used for add-only counters and in conjunction with a >>>>>>> background >>>>>>> thread that would periodically flush the sum to the native >>>>>>> memory.... >>>>>>> >>>>>>> Regards, Peter >>>>>>> >>>>>>> >>>>>>> On 02/08/2013 06:10 PM, Nils Loodin wrote: >>>>>>>> It would be interesting to know the number of thrown throwables in >>>>>>>> the >>>>>>>> JVM, to be able to do some high level application diagnostics / >>>>>>>> statistics. A good way to put this number would be a performance >>>>>>>> counter, since it is accessible both from Java and from the VM. >>>>>>>> >>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007806 >>>>>>>> http://cr.openjdk.java.net/~nloodin/8007806/webrev.00/ >>>>>>>> >>>>>>>> Regards, >>>>>>>> Nils Loodin >>>>>>> >>>>> >>> > From peter.levart at gmail.com Sun Feb 24 22:05:09 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 24 Feb 2013 23:05:09 +0100 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <512A8AC2.9020800@oracle.com> References: <5115316A.8050109@oracle.com> <51291AEB.3040005@gmail.com> <5129534A.8000500@oracle.com> <5129D45A.6010802@gmail.com> <5129EBE5.1030207@oracle.com> <512A7593.7040807@gmail.com> <512A7EB6.8090503@oracle.com> <512A8554.6080203@gmail.com> <512A8AC2.9020800@oracle.com> Message-ID: <512A8E95.9000902@gmail.com> On 02/24/2013 10:48 PM, David Holmes wrote: > Peter, > > On 25/02/2013 7:25 AM, Peter Levart wrote: >> >> On 02/24/2013 09:57 PM, David Holmes wrote: >>> On 25/02/2013 6:18 AM, Peter Levart wrote: >>>> Hi Alan, David, Nils, >>>> >>>> I just want to clear something regarding PerfCounter implementation. >>>> >>>> Access to 64bit value in native memory is through a direct buffer >>>> which >>>> uses normal read/write (non-volatile, Unsafe.[get|set]Long). So on >>>> processors that don't support atomic 64bit stores/loads, each access >>>> results in two separate 32bit load/store accesses right? >>> >>> Unsafe.get|setLong uses locking on those platforms. >> >> Even if it does, it is important whether "all" accesses to this 64bit >> value are using locking and whether they are using the same lock. Aren't >> performance counters JVM native variables where just some of them happen >> to be updated from Java? > > AFAICS PerfCounters have no thread-safety properties or guarantees. So > it is up to the user of each counter to use it in an appropriate way. > I think the serviceability folk would have to chime in here as to how > PerfCounters are supposed to be used. > >>>> The PerfCounter methods that access the 64bit value are synchronized, >>>> using PerfCounter instance as a lock. But how is this 64bit value >>>> accessed for example in the jstat utility? Is it possible that >>>> jstat can >>>> see one half of the 64bit value before the update and the other half >>>> after the update? >>> >>> Does jstat access these values directly or only via the synchronized >>> methods? If the latter then the value can't be "torn" that way. The >>> sync method will store the value in 2 32-bit registers, and the >>> variable load in jstat will take two instructions, but nothing can >>> touch those registers. >> >> I'm not saying that the value could be corrupted in any way, just that >> the unsynchronized observer (like jstat) could see it "torn" sometimes. > > If the value is initially read in a sync block and all updates are > also synchronized, then I don't think it can. But you need to look at > actual code to determine this. Just looked at one way jstat accesses the counters. It runs in a separate VM and maps-in a file that is already mapped in the observing VM in the direct buffer. It then accesses it via a LongBuffer view (for long counters). So there's no synchronization between counter updater and counter reader. On ARM v6 jstat could see a "torn" long counter then, right? The double-32bit-CAS updater that I presented would not make it worse then on such platforms, I suppose. On the platforms that support 64bit atomic stores, there are not such problems. And I assume those same platforms also support 64bit CAS, or are there platforms with 64bit atomic stores and no 64bit CAS? Regards, Peter > > David > >> Regards, Peter >> >>> >>> David >>> ----- >>> >>>> If this is true and it is not that important, then instead of a >>>> synchronized update of 64bit counter, a 32bit CAS could be used, >>>> optionally (rarely) followed by a second 32bit CAS, like for example: >>>> >>>> http://dl.dropbox.com/u/101777488/jdk8-tl/PerfCounter/webrev.01/index.html >>>> >>>> >>>> >>>> I tried this on ARM v6 and it works much better than synchronized >>>> access, but I don't know if it's acceptable. It guarantees eventual >>>> correctness of summed value if the only operation performed is >>>> add() (no >>>> set() intermingled) and has the same possibility of incorrect >>>> half-half >>>> reads by observers as current PerfCounter has for unsynchronized >>>> observers. >>>> >>>> Here's the comparison of unpatched/patched PerfCounter.increment() >>>> micro-benchmark on single-core ARM v6 (Raspbery-PI): >>>> >>>> *** Original PerfCounter, ARM v6 >>>> >>>> # >>>> # PerfCounter_increment: run duration: 5,000 ms, #of logical CPUS: 1 >>>> # >>>> 1 threads, Tavg = 269.34 ns/op (? = 0.00 ns/op) [ >>>> 269.34] >>>> 2 threads, Tavg = 7,170.48 ns/op (? = 410.77 ns/op) [ >>>> 6,783.73, 7,603.95] >>>> 3 threads, Tavg = 12,034.82 ns/op (? = 418.99 ns/op) >>>> [11,792.33, 11,714.67, 12,639.26] >>>> 4 threads, Tavg = 16,029.76 ns/op (? = 1,411.44 ns/op) >>>> [15,592.04, 18,511.52, 15,642.52, 14,818.16] >>>> >>>> >>>> *** Patched PerfCounter, ARM v6 >>>> >>>> # >>>> # PerfCounter_increment: run duration: 5,000 ms, #of logical CPUS: 1 >>>> # >>>> 1 threads, Tavg = 166.21 ns/op (? = 0.00 ns/op) [ >>>> 166.21] >>>> 2 threads, Tavg = 332.58 ns/op (? = 0.12 ns/op) [ >>>> 332.45, 332.70] >>>> 3 threads, Tavg = 500.30 ns/op (? = 0.22 ns/op) [ >>>> 500.04, 500.29, 500.58] >>>> 4 threads, Tavg = 667.95 ns/op (? = 2.11 ns/op) [ >>>> 665.22, 667.18, 668.40, 671.04] >>>> >>>> >>>> Regards, Peter >>>> >>>> >>>> On 02/24/2013 11:31 AM, David Holmes wrote: >>>>> On 24/02/2013 6:50 PM, Peter Levart wrote: >>>>>> Hi David, >>>>>> >>>>>> I thought it was ok to pass null, but I don't know the "portability" >>>>>> issues in-depth. The javadoc for Unsafe says: >>>>>> >>>>>> /"This method refers to a variable by means of two parameters, and >>>>>> so it >>>>>> provides (in effect) a double-register addressing mode for Java >>>>>> variables. When the object reference is null, this method uses its >>>>>> offset as an absolute address. This is similar in operation to >>>>>> methods >>>>>> such as getInt(long), which provide (in effect) a single-register >>>>>> addressing mode for non-Java variables. However, because Java >>>>>> variables >>>>>> may have a different layout in memory from non-Java variables, >>>>>> programmers should not assume that these two addressing modes are >>>>>> ever >>>>>> equivalent. Also, programmers should remember that offsets from the >>>>>> double-register addressing mode cannot be portably confused with >>>>>> longs >>>>>> used in the single-register addressing mode."/ >>>>> >>>>> That is the doc for getXXX but not for getAndAddXXX or >>>>> compareAndSwapXXX. You can't have null here: >>>>> >>>>> UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapLong(JNIEnv *env, jobject >>>>> unsafe, jobject obj, jlong offset, jlong e, jlong x)) >>>>> UnsafeWrapper("Unsafe_CompareAndSwapLong"); >>>>> Handle p (THREAD, JNIHandles::resolve(obj)); >>>>> jlong* addr = (jlong*)(index_oop_from_field_offset_long(p(), >>>>> offset)); >>>>> if (VM_Version::supports_cx8()) >>>>> return (jlong)(Atomic::cmpxchg(x, addr, e)) == e; >>>>> else { >>>>> jboolean success = false; >>>>> ObjectLocker ol(p, THREAD); >>>>> if (*addr == e) { *addr = x; success = true; } >>>>> return success; >>>>> } >>>>> UNSAFE_END >>>>> >>>>> David >>>>> ----- >>>>> >>>>> >>>>>> Does anybody know the in-depth interpretation of the above? Is it >>>>>> only >>>>>> the particular Java/native type differences (for example, >>>>>> endianess of >>>>>> variables) that these two addressing modes might interpret >>>>>> differently >>>>>> or something else too? >>>>>> >>>>>> Regards, Peter >>>>>> >>>>>> >>>>>> On 02/24/2013 12:39 AM, David Holmes wrote: >>>>>>> Peter, >>>>>>> >>>>>>> In your use of Unsafe you pass "null" as the object. I'm pretty >>>>>>> certain you can't pass null here. Unsafe operates on fields or >>>>>>> array >>>>>>> elements. >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On 24/02/2013 5:39 AM, Peter Levart wrote: >>>>>>>> Hi Nils, >>>>>>>> >>>>>>>> If the counters are updated frequently from multiple threads, >>>>>>>> there >>>>>>>> might be contention/scalability issues. Instead of >>>>>>>> synchronization on >>>>>>>> updates, you might consider using atomic updates provided by >>>>>>>> sun.misc.Unsafe, like for example: >>>>>>>> >>>>>>>> >>>>>>>> Index: jdk/src/share/classes/sun/misc/PerfCounter.java >>>>>>>> =================================================================== >>>>>>>> >>>>>>>> --- jdk/src/share/classes/sun/misc/PerfCounter.java >>>>>>>> +++ jdk/src/share/classes/sun/misc/PerfCounter.java >>>>>>>> @@ -25,6 +25,8 @@ >>>>>>>> >>>>>>>> package sun.misc; >>>>>>>> >>>>>>>> +import sun.nio.ch.DirectBuffer; >>>>>>>> + >>>>>>>> import java.nio.ByteBuffer; >>>>>>>> import java.nio.ByteOrder; >>>>>>>> import java.nio.LongBuffer; >>>>>>>> @@ -50,6 +52,8 @@ >>>>>>>> public class PerfCounter { >>>>>>>> private static final Perf perf = >>>>>>>> AccessController.doPrivileged(new Perf.GetPerfAction()); >>>>>>>> + private static final Unsafe unsafe = >>>>>>>> + Unsafe.getUnsafe(); >>>>>>>> >>>>>>>> // Must match values defined in >>>>>>>> hotspot/src/share/vm/runtime/perfdata.hpp >>>>>>>> private final static int V_Constant = 1; >>>>>>>> @@ -59,12 +63,14 @@ >>>>>>>> >>>>>>>> private final String name; >>>>>>>> private final LongBuffer lb; >>>>>>>> + private final DirectBuffer db; >>>>>>>> >>>>>>>> private PerfCounter(String name, int type) { >>>>>>>> this.name = name; >>>>>>>> ByteBuffer bb = perf.createLong(name, U_None, type, 0L); >>>>>>>> bb.order(ByteOrder.nativeOrder()); >>>>>>>> this.lb = bb.asLongBuffer(); >>>>>>>> + this.db = bb instanceof DirectBuffer ? (DirectBuffer) >>>>>>>> bb : >>>>>>>> null; >>>>>>>> } >>>>>>>> >>>>>>>> static PerfCounter newPerfCounter(String name) { >>>>>>>> @@ -79,23 +85,44 @@ >>>>>>>> /** >>>>>>>> * Returns the current value of the perf counter. >>>>>>>> */ >>>>>>>> - public synchronized long get() { >>>>>>>> + public long get() { >>>>>>>> + if (db != null) { >>>>>>>> + return unsafe.getLongVolatile(null, db.address()); >>>>>>>> + } >>>>>>>> + else { >>>>>>>> + synchronized (this) { >>>>>>>> - return lb.get(0); >>>>>>>> - } >>>>>>>> + return lb.get(0); >>>>>>>> + } >>>>>>>> + } >>>>>>>> + } >>>>>>>> >>>>>>>> /** >>>>>>>> * Sets the value of the perf counter to the given newValue. >>>>>>>> */ >>>>>>>> - public synchronized void set(long newValue) { >>>>>>>> + public void set(long newValue) { >>>>>>>> + if (db != null) { >>>>>>>> + unsafe.putOrderedLong(null, db.address(), newValue); >>>>>>>> + } >>>>>>>> + else { >>>>>>>> + synchronized (this) { >>>>>>>> - lb.put(0, newValue); >>>>>>>> - } >>>>>>>> + lb.put(0, newValue); >>>>>>>> + } >>>>>>>> + } >>>>>>>> + } >>>>>>>> >>>>>>>> /** >>>>>>>> * Adds the given value to the perf counter. >>>>>>>> */ >>>>>>>> - public synchronized void add(long value) { >>>>>>>> - long res = get() + value; >>>>>>>> + public void add(long value) { >>>>>>>> + if (db != null) { >>>>>>>> + unsafe.getAndAddLong(null, db.address(), value); >>>>>>>> + } >>>>>>>> + else { >>>>>>>> + synchronized (this) { >>>>>>>> + long res = lb.get(0) + value; >>>>>>>> - lb.put(0, res); >>>>>>>> + lb.put(0, res); >>>>>>>> + } >>>>>>>> + } >>>>>>>> } >>>>>>>> >>>>>>>> /** >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Testing the PerfCounter.increment() method in a loop on multiple >>>>>>>> threads >>>>>>>> sharing the same PerfCounter instance, for example, on a 4-core >>>>>>>> Intel i7 >>>>>>>> machine produces the following results: >>>>>>>> >>>>>>>> # >>>>>>>> # PerfCounter_increment: run duration: 5,000 ms, #of logical >>>>>>>> CPUS: 8 >>>>>>>> # >>>>>>>> 1 threads, Tavg = 19.02 ns/op (? = 0.00 ns/op) >>>>>>>> 2 threads, Tavg = 109.93 ns/op (? = 6.17 ns/op) >>>>>>>> 3 threads, Tavg = 136.64 ns/op (? = 2.99 ns/op) >>>>>>>> 4 threads, Tavg = 293.26 ns/op (? = 5.30 ns/op) >>>>>>>> 5 threads, Tavg = 316.94 ns/op (? = 6.28 ns/op) >>>>>>>> 6 threads, Tavg = 686.96 ns/op (? = 7.09 ns/op) >>>>>>>> 7 threads, Tavg = 793.28 ns/op (? = 10.57 ns/op) >>>>>>>> 8 threads, Tavg = 898.15 ns/op (? = 14.63 ns/op) >>>>>>>> >>>>>>>> >>>>>>>> With the presented patch, the results are a little better: >>>>>>>> >>>>>>>> # >>>>>>>> # PerfCounter_increment: run duration: 5,000 ms, #of logical >>>>>>>> CPUS: 8 >>>>>>>> # >>>>>>>> # Measure: >>>>>>>> 1 threads, Tavg = 5.22 ns/op (? = 0.00 ns/op) >>>>>>>> 2 threads, Tavg = 34.51 ns/op (? = 0.60 ns/op) >>>>>>>> 3 threads, Tavg = 54.85 ns/op (? = 1.42 ns/op) >>>>>>>> 4 threads, Tavg = 74.67 ns/op (? = 1.71 ns/op) >>>>>>>> 5 threads, Tavg = 94.71 ns/op (? = 41.68 ns/op) >>>>>>>> 6 threads, Tavg = 114.80 ns/op (? = 32.10 ns/op) >>>>>>>> 7 threads, Tavg = 136.70 ns/op (? = 26.80 ns/op) >>>>>>>> 8 threads, Tavg = 158.48 ns/op (? = 9.93 ns/op) >>>>>>>> >>>>>>>> >>>>>>>> The scalability is not much better, but the raw speed is, so it >>>>>>>> might >>>>>>>> present less contention when used in real-world code. If you >>>>>>>> wanted >>>>>>>> even >>>>>>>> better scalability, there is a new class in JDK8, the >>>>>>>> java.util.concurrent.LongAdder. But that doesn't buy atomic >>>>>>>> "set()" - >>>>>>>> only "add()". And it can't update native-memory variables, so it >>>>>>>> could >>>>>>>> only be used for add-only counters and in conjunction with a >>>>>>>> background >>>>>>>> thread that would periodically flush the sum to the native >>>>>>>> memory.... >>>>>>>> >>>>>>>> Regards, Peter >>>>>>>> >>>>>>>> >>>>>>>> On 02/08/2013 06:10 PM, Nils Loodin wrote: >>>>>>>>> It would be interesting to know the number of thrown >>>>>>>>> throwables in >>>>>>>>> the >>>>>>>>> JVM, to be able to do some high level application diagnostics / >>>>>>>>> statistics. A good way to put this number would be a performance >>>>>>>>> counter, since it is accessible both from Java and from the VM. >>>>>>>>> >>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007806 >>>>>>>>> http://cr.openjdk.java.net/~nloodin/8007806/webrev.00/ >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Nils Loodin >>>>>>>> >>>>>> >>>> >> From david.holmes at oracle.com Sun Feb 24 22:18:14 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Feb 2013 08:18:14 +1000 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <512A8E95.9000902@gmail.com> References: <5115316A.8050109@oracle.com> <51291AEB.3040005@gmail.com> <5129534A.8000500@oracle.com> <5129D45A.6010802@gmail.com> <5129EBE5.1030207@oracle.com> <512A7593.7040807@gmail.com> <512A7EB6.8090503@oracle.com> <512A8554.6080203@gmail.com> <512A8AC2.9020800@oracle.com> <512A8E95.9000902@gmail.com> Message-ID: <512A91A6.7090804@oracle.com> We've not-so-slightly hijacked Nils' thread here - apologies for that. On 25/02/2013 8:05 AM, Peter Levart wrote: > > Just looked at one way jstat accesses the counters. It runs in a > separate VM and maps-in a file that is already mapped in the observing > VM in the direct buffer. It then accesses it via a LongBuffer view (for > long counters). So there's no synchronization between counter updater > and counter reader. On ARM v6 jstat could see a "torn" long counter > then, right? Right. With current implementation of PerfLongCounter it uses simple stores (not atomic ops). > The double-32bit-CAS updater that I presented would not make it worse > then on such platforms, I suppose. No change in tearing abaility. > On the platforms that support 64bit atomic stores, there are not such > problems. And I assume those same platforms also support 64bit CAS, or > are there platforms with 64bit atomic stores and no 64bit CAS? Most of them actually :) All Java platforms must support atomic load/store of 64-bit values to support volatile long and double variables. On 32-bit platforms this is done via a range of techniques - for example on x86 it is done via the FPU. But these atomic accesses are currently restricted to Java volatile field accesses via bytecode - there are not exposed via the Unsafe methods, nor are they made available via the Atomic:: class in the VM. Some of these 32-bit platforms also support the 64-bit CAS, which is what supports_cx8() is intended to indicate. If the PerfCounters were supposed to be thread-safe then they might use these alternate atomic access operations. David > Regards, Peter > >> >> David >> >>> Regards, Peter >>> >>>> >>>> David >>>> ----- >>>> >>>>> If this is true and it is not that important, then instead of a >>>>> synchronized update of 64bit counter, a 32bit CAS could be used, >>>>> optionally (rarely) followed by a second 32bit CAS, like for example: >>>>> >>>>> http://dl.dropbox.com/u/101777488/jdk8-tl/PerfCounter/webrev.01/index.html >>>>> >>>>> >>>>> >>>>> I tried this on ARM v6 and it works much better than synchronized >>>>> access, but I don't know if it's acceptable. It guarantees eventual >>>>> correctness of summed value if the only operation performed is >>>>> add() (no >>>>> set() intermingled) and has the same possibility of incorrect >>>>> half-half >>>>> reads by observers as current PerfCounter has for unsynchronized >>>>> observers. >>>>> >>>>> Here's the comparison of unpatched/patched PerfCounter.increment() >>>>> micro-benchmark on single-core ARM v6 (Raspbery-PI): >>>>> >>>>> *** Original PerfCounter, ARM v6 >>>>> >>>>> # >>>>> # PerfCounter_increment: run duration: 5,000 ms, #of logical CPUS: 1 >>>>> # >>>>> 1 threads, Tavg = 269.34 ns/op (? = 0.00 ns/op) [ >>>>> 269.34] >>>>> 2 threads, Tavg = 7,170.48 ns/op (? = 410.77 ns/op) [ >>>>> 6,783.73, 7,603.95] >>>>> 3 threads, Tavg = 12,034.82 ns/op (? = 418.99 ns/op) >>>>> [11,792.33, 11,714.67, 12,639.26] >>>>> 4 threads, Tavg = 16,029.76 ns/op (? = 1,411.44 ns/op) >>>>> [15,592.04, 18,511.52, 15,642.52, 14,818.16] >>>>> >>>>> >>>>> *** Patched PerfCounter, ARM v6 >>>>> >>>>> # >>>>> # PerfCounter_increment: run duration: 5,000 ms, #of logical CPUS: 1 >>>>> # >>>>> 1 threads, Tavg = 166.21 ns/op (? = 0.00 ns/op) [ >>>>> 166.21] >>>>> 2 threads, Tavg = 332.58 ns/op (? = 0.12 ns/op) [ >>>>> 332.45, 332.70] >>>>> 3 threads, Tavg = 500.30 ns/op (? = 0.22 ns/op) [ >>>>> 500.04, 500.29, 500.58] >>>>> 4 threads, Tavg = 667.95 ns/op (? = 2.11 ns/op) [ >>>>> 665.22, 667.18, 668.40, 671.04] >>>>> >>>>> >>>>> Regards, Peter >>>>> >>>>> >>>>> On 02/24/2013 11:31 AM, David Holmes wrote: >>>>>> On 24/02/2013 6:50 PM, Peter Levart wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> I thought it was ok to pass null, but I don't know the "portability" >>>>>>> issues in-depth. The javadoc for Unsafe says: >>>>>>> >>>>>>> /"This method refers to a variable by means of two parameters, and >>>>>>> so it >>>>>>> provides (in effect) a double-register addressing mode for Java >>>>>>> variables. When the object reference is null, this method uses its >>>>>>> offset as an absolute address. This is similar in operation to >>>>>>> methods >>>>>>> such as getInt(long), which provide (in effect) a single-register >>>>>>> addressing mode for non-Java variables. However, because Java >>>>>>> variables >>>>>>> may have a different layout in memory from non-Java variables, >>>>>>> programmers should not assume that these two addressing modes are >>>>>>> ever >>>>>>> equivalent. Also, programmers should remember that offsets from the >>>>>>> double-register addressing mode cannot be portably confused with >>>>>>> longs >>>>>>> used in the single-register addressing mode."/ >>>>>> >>>>>> That is the doc for getXXX but not for getAndAddXXX or >>>>>> compareAndSwapXXX. You can't have null here: >>>>>> >>>>>> UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapLong(JNIEnv *env, jobject >>>>>> unsafe, jobject obj, jlong offset, jlong e, jlong x)) >>>>>> UnsafeWrapper("Unsafe_CompareAndSwapLong"); >>>>>> Handle p (THREAD, JNIHandles::resolve(obj)); >>>>>> jlong* addr = (jlong*)(index_oop_from_field_offset_long(p(), >>>>>> offset)); >>>>>> if (VM_Version::supports_cx8()) >>>>>> return (jlong)(Atomic::cmpxchg(x, addr, e)) == e; >>>>>> else { >>>>>> jboolean success = false; >>>>>> ObjectLocker ol(p, THREAD); >>>>>> if (*addr == e) { *addr = x; success = true; } >>>>>> return success; >>>>>> } >>>>>> UNSAFE_END >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>> >>>>>>> Does anybody know the in-depth interpretation of the above? Is it >>>>>>> only >>>>>>> the particular Java/native type differences (for example, >>>>>>> endianess of >>>>>>> variables) that these two addressing modes might interpret >>>>>>> differently >>>>>>> or something else too? >>>>>>> >>>>>>> Regards, Peter >>>>>>> >>>>>>> >>>>>>> On 02/24/2013 12:39 AM, David Holmes wrote: >>>>>>>> Peter, >>>>>>>> >>>>>>>> In your use of Unsafe you pass "null" as the object. I'm pretty >>>>>>>> certain you can't pass null here. Unsafe operates on fields or >>>>>>>> array >>>>>>>> elements. >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> On 24/02/2013 5:39 AM, Peter Levart wrote: >>>>>>>>> Hi Nils, >>>>>>>>> >>>>>>>>> If the counters are updated frequently from multiple threads, >>>>>>>>> there >>>>>>>>> might be contention/scalability issues. Instead of >>>>>>>>> synchronization on >>>>>>>>> updates, you might consider using atomic updates provided by >>>>>>>>> sun.misc.Unsafe, like for example: >>>>>>>>> >>>>>>>>> >>>>>>>>> Index: jdk/src/share/classes/sun/misc/PerfCounter.java >>>>>>>>> =================================================================== >>>>>>>>> >>>>>>>>> --- jdk/src/share/classes/sun/misc/PerfCounter.java >>>>>>>>> +++ jdk/src/share/classes/sun/misc/PerfCounter.java >>>>>>>>> @@ -25,6 +25,8 @@ >>>>>>>>> >>>>>>>>> package sun.misc; >>>>>>>>> >>>>>>>>> +import sun.nio.ch.DirectBuffer; >>>>>>>>> + >>>>>>>>> import java.nio.ByteBuffer; >>>>>>>>> import java.nio.ByteOrder; >>>>>>>>> import java.nio.LongBuffer; >>>>>>>>> @@ -50,6 +52,8 @@ >>>>>>>>> public class PerfCounter { >>>>>>>>> private static final Perf perf = >>>>>>>>> AccessController.doPrivileged(new Perf.GetPerfAction()); >>>>>>>>> + private static final Unsafe unsafe = >>>>>>>>> + Unsafe.getUnsafe(); >>>>>>>>> >>>>>>>>> // Must match values defined in >>>>>>>>> hotspot/src/share/vm/runtime/perfdata.hpp >>>>>>>>> private final static int V_Constant = 1; >>>>>>>>> @@ -59,12 +63,14 @@ >>>>>>>>> >>>>>>>>> private final String name; >>>>>>>>> private final LongBuffer lb; >>>>>>>>> + private final DirectBuffer db; >>>>>>>>> >>>>>>>>> private PerfCounter(String name, int type) { >>>>>>>>> this.name = name; >>>>>>>>> ByteBuffer bb = perf.createLong(name, U_None, type, 0L); >>>>>>>>> bb.order(ByteOrder.nativeOrder()); >>>>>>>>> this.lb = bb.asLongBuffer(); >>>>>>>>> + this.db = bb instanceof DirectBuffer ? (DirectBuffer) >>>>>>>>> bb : >>>>>>>>> null; >>>>>>>>> } >>>>>>>>> >>>>>>>>> static PerfCounter newPerfCounter(String name) { >>>>>>>>> @@ -79,23 +85,44 @@ >>>>>>>>> /** >>>>>>>>> * Returns the current value of the perf counter. >>>>>>>>> */ >>>>>>>>> - public synchronized long get() { >>>>>>>>> + public long get() { >>>>>>>>> + if (db != null) { >>>>>>>>> + return unsafe.getLongVolatile(null, db.address()); >>>>>>>>> + } >>>>>>>>> + else { >>>>>>>>> + synchronized (this) { >>>>>>>>> - return lb.get(0); >>>>>>>>> - } >>>>>>>>> + return lb.get(0); >>>>>>>>> + } >>>>>>>>> + } >>>>>>>>> + } >>>>>>>>> >>>>>>>>> /** >>>>>>>>> * Sets the value of the perf counter to the given newValue. >>>>>>>>> */ >>>>>>>>> - public synchronized void set(long newValue) { >>>>>>>>> + public void set(long newValue) { >>>>>>>>> + if (db != null) { >>>>>>>>> + unsafe.putOrderedLong(null, db.address(), newValue); >>>>>>>>> + } >>>>>>>>> + else { >>>>>>>>> + synchronized (this) { >>>>>>>>> - lb.put(0, newValue); >>>>>>>>> - } >>>>>>>>> + lb.put(0, newValue); >>>>>>>>> + } >>>>>>>>> + } >>>>>>>>> + } >>>>>>>>> >>>>>>>>> /** >>>>>>>>> * Adds the given value to the perf counter. >>>>>>>>> */ >>>>>>>>> - public synchronized void add(long value) { >>>>>>>>> - long res = get() + value; >>>>>>>>> + public void add(long value) { >>>>>>>>> + if (db != null) { >>>>>>>>> + unsafe.getAndAddLong(null, db.address(), value); >>>>>>>>> + } >>>>>>>>> + else { >>>>>>>>> + synchronized (this) { >>>>>>>>> + long res = lb.get(0) + value; >>>>>>>>> - lb.put(0, res); >>>>>>>>> + lb.put(0, res); >>>>>>>>> + } >>>>>>>>> + } >>>>>>>>> } >>>>>>>>> >>>>>>>>> /** >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Testing the PerfCounter.increment() method in a loop on multiple >>>>>>>>> threads >>>>>>>>> sharing the same PerfCounter instance, for example, on a 4-core >>>>>>>>> Intel i7 >>>>>>>>> machine produces the following results: >>>>>>>>> >>>>>>>>> # >>>>>>>>> # PerfCounter_increment: run duration: 5,000 ms, #of logical >>>>>>>>> CPUS: 8 >>>>>>>>> # >>>>>>>>> 1 threads, Tavg = 19.02 ns/op (? = 0.00 ns/op) >>>>>>>>> 2 threads, Tavg = 109.93 ns/op (? = 6.17 ns/op) >>>>>>>>> 3 threads, Tavg = 136.64 ns/op (? = 2.99 ns/op) >>>>>>>>> 4 threads, Tavg = 293.26 ns/op (? = 5.30 ns/op) >>>>>>>>> 5 threads, Tavg = 316.94 ns/op (? = 6.28 ns/op) >>>>>>>>> 6 threads, Tavg = 686.96 ns/op (? = 7.09 ns/op) >>>>>>>>> 7 threads, Tavg = 793.28 ns/op (? = 10.57 ns/op) >>>>>>>>> 8 threads, Tavg = 898.15 ns/op (? = 14.63 ns/op) >>>>>>>>> >>>>>>>>> >>>>>>>>> With the presented patch, the results are a little better: >>>>>>>>> >>>>>>>>> # >>>>>>>>> # PerfCounter_increment: run duration: 5,000 ms, #of logical >>>>>>>>> CPUS: 8 >>>>>>>>> # >>>>>>>>> # Measure: >>>>>>>>> 1 threads, Tavg = 5.22 ns/op (? = 0.00 ns/op) >>>>>>>>> 2 threads, Tavg = 34.51 ns/op (? = 0.60 ns/op) >>>>>>>>> 3 threads, Tavg = 54.85 ns/op (? = 1.42 ns/op) >>>>>>>>> 4 threads, Tavg = 74.67 ns/op (? = 1.71 ns/op) >>>>>>>>> 5 threads, Tavg = 94.71 ns/op (? = 41.68 ns/op) >>>>>>>>> 6 threads, Tavg = 114.80 ns/op (? = 32.10 ns/op) >>>>>>>>> 7 threads, Tavg = 136.70 ns/op (? = 26.80 ns/op) >>>>>>>>> 8 threads, Tavg = 158.48 ns/op (? = 9.93 ns/op) >>>>>>>>> >>>>>>>>> >>>>>>>>> The scalability is not much better, but the raw speed is, so it >>>>>>>>> might >>>>>>>>> present less contention when used in real-world code. If you >>>>>>>>> wanted >>>>>>>>> even >>>>>>>>> better scalability, there is a new class in JDK8, the >>>>>>>>> java.util.concurrent.LongAdder. But that doesn't buy atomic >>>>>>>>> "set()" - >>>>>>>>> only "add()". And it can't update native-memory variables, so it >>>>>>>>> could >>>>>>>>> only be used for add-only counters and in conjunction with a >>>>>>>>> background >>>>>>>>> thread that would periodically flush the sum to the native >>>>>>>>> memory.... >>>>>>>>> >>>>>>>>> Regards, Peter >>>>>>>>> >>>>>>>>> >>>>>>>>> On 02/08/2013 06:10 PM, Nils Loodin wrote: >>>>>>>>>> It would be interesting to know the number of thrown >>>>>>>>>> throwables in >>>>>>>>>> the >>>>>>>>>> JVM, to be able to do some high level application diagnostics / >>>>>>>>>> statistics. A good way to put this number would be a performance >>>>>>>>>> counter, since it is accessible both from Java and from the VM. >>>>>>>>>> >>>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007806 >>>>>>>>>> http://cr.openjdk.java.net/~nloodin/8007806/webrev.00/ >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Nils Loodin >>>>>>>>> >>>>>>> >>>>> >>> > From david.holmes at oracle.com Sun Feb 24 23:03:07 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Feb 2013 09:03:07 +1000 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: References: <5115316A.8050109@oracle.com>, <51276E2A.40402@oracle.com> Message-ID: <512A9C2B.1000304@oracle.com> I'm getting very confused regarding the different threads on this. But this webrev: http://cr.openjdk.java.net/~nloodin/exception-tracing/webrev.01/ shows the intrusive event tracing that I'm sure we said we would grudgingly accept for 7u but not for JDK 8. David On 23/02/2013 2:16 AM, Jason Mehrens wrote: > From this webrev > http://cr.openjdk.java.net/~nloodin/exception-tracing/webrev.01/ you > are counting the number of throwables constructed. You might want to > change the name to reflect that. I don't think anyone would want to > write a spec for how many throwables are thrown given that a throwable > can be wrapped, suppressed, rethrown, etc. > Jason > > > Date: Fri, 22 Feb 2013 14:10:02 +0100 > > From: nils.loodin at oracle.com > > To: core-libs-dev at openjdk.java.net; serviceability-dev at openjdk.java.net > > Subject: Fwd: RFR: 8007806: Need a Throwables performance counter > > > > Does anyone have anything strongly against this? This is a small change > > just to add a performance counter, the code to increment it and read it > > will live in other parts of the code and be a part of a larger separate > > commit. > > > > Alan Bateman gave the response that the name was inappropriate, but I > > don't really have a better alternative, but neither do I have strong > > opinions, so feedback would be appreciated! > > > > How about > > "sun.throwables.thrownThrowables" ? > > > > Regards, > > Nils Loodin > > > > > > -------- Original Message -------- > > Subject: RFR: 8007806: Need a Throwables performance counter > > Date: Fri, 08 Feb 2013 18:10:02 +0100 > > From: Nils Loodin > > To: core-libs-dev at openjdk.java.net, serviceability_dev_ww_grp > > > > > > It would be interesting to know the number of thrown throwables in the > > JVM, to be able to do some high level application diagnostics / > > statistics. A good way to put this number would be a performance > > counter, since it is accessible both from Java and from the VM. > > > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007806 > > http://cr.openjdk.java.net/~nloodin/8007806/webrev.00/ > > > > Regards, > > Nils Loodin > > > > > From david.holmes at oracle.com Sun Feb 24 23:34:31 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Feb 2013 09:34:31 +1000 Subject: RFR: 8005545: Add System property to identify ARCH specific details such as ARM hard-float binaries In-Reply-To: <5D7CCEEA-EA5A-4D7C-833A-EB045ACF1AA9@oracle.com> References: <899E92AE-F8A0-4873-B8DC-EE642B615840@oracle.com> <51274F10.6020208@oracle.com> <5D7CCEEA-EA5A-4D7C-833A-EB045ACF1AA9@oracle.com> Message-ID: <512AA387.5020401@oracle.com> Adding back build-dev On 23/02/2013 7:33 AM, Vladimir Danushevsky wrote: > Thanks, webrev updated > http://cr.openjdk.java.net/~vladidan/8005545/webrev.01/ > What is missing from this is documentation on how this new variable should be set in a build. The proposed changes rely on two things happening: a) JDK_ARCH_ABI_PROP_NAME=foo is either passed as a make variable, or set in the environment; and b) --with-extra-cflags is used to pass -DJDK_ARCH_ABI_PROP_NAME=foo This would go into the top-level README-builds.html, if people think it needs to be documented. David > On Feb 22, 2013, at 5:57 AM, Alan Bateman wrote: > >> On 21/02/2013 22:02, Vladimir Danushevsky wrote: >>> : >>> >>> Webrev: >>> http://cr.openjdk.java.net/~vladidan/8005545/webrev.00/ >>> >>> >>> Separate change to the build script (e.g. in ARM Hard-Float ABI case): >>> setenv ARCHABIPROPNAME gnueabihf >>> -DARCHABIPROPNAME="\"$(ARCHABIPROPNAME)\"" is passed to the CFLAGS >>> >> I agree with Bob on the naming, otherwise it looks okay to me. >> >> On the release file and Images.gmk then jdk/tl was sync'ed up >> yesterday so you will probably need to re-base the patch. >> >> -Alan > From david.holmes at oracle.com Mon Feb 25 03:07:48 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Feb 2013 13:07:48 +1000 Subject: Code review request In-Reply-To: <51289F3D.1010609@univ-mlv.fr> References: <512672E6.1050708@oracle.com> <51289F3D.1010609@univ-mlv.fr> Message-ID: <512AD584.2080902@oracle.com> On 23/02/2013 8:51 PM, Remi Forax wrote: > On 02/21/2013 08:17 PM, Brian Goetz wrote: >> At >> http://cr.openjdk.java.net/~briangoetz/jdk-8008670/webrev/ >> >> I've posted a webrev for about half the classes in java.util.stream. >> None of these are public classes, so there are no public API issues >> here, but plenty of internal API issues, naming issues (ooh, a >> bikeshed), and code quality issues. >> > > Hi Brian, > > All protected fields should not be protected but package visible. > Classes are package private so there is no need to use a modifier which > offer a wider visibility. > The same is true for constructors. I believe some of these may end up being public (TBD), in which case better to define member accessibility as if they were already public as it greatly simplifies the changes needed later. David ----- > For default method, some of them are marked public, some of them are not, > what the coding convention said ? > > Code convention again, there is a lot of if/else with no curly braces, > or only curly braces > on the if part but not on the else part. > Also, when a if block ends with a return, there is no need to use 'else', > > if (result != null) { > foundResult(result); > return result; > } > else > return null; > > can be simply written: > > if (result != null) { > foundResult(result); > return result; > } > return null; > > > All inner class should not have private constructors, like by example > FindOp.FindTask, because > the compiler will have to generate a special accessor for them when they > are called from > the outer class. > > In AbstractShortCircuitTask: > It's not clear that cancel and sharedResult can be accessed directly > given that they both have methods that acts as getter and setter. > If they can be accessed directly, I think it's better to declare them > private and to use getters. > > Depending on the ops, some of them do nullcheks of arguments at creating > time (ForEachOp) , some of them don't (FindOp). > In ForEachUntilOp, the 'consumer' is checked but 'until' is not. > > in ForEachOp, most of the keyword protected are not needed, > ForEachUntilOp which inherits from ForEachOp is in the same package. > > In ForEachUntilOp, the constructor should be private (like for all the > other ops). > > In MatchOp, line 110, I think the compiler bug is fixed now ? > The enum MatchKind should not be public and all constructor of all inner > classes should not be private. > > In OpsUtils, some static methods are public and some are not, > > in Tripwire: > enabled should be in uppercase (ENABLED). > method trip() should be: > public static void trip(Class trippingClass, String msg) > > cheers, > R?mi > From mike.duigou at oracle.com Mon Feb 25 04:06:29 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Sun, 24 Feb 2013 20:06:29 -0800 Subject: hg: jdk8/tl/jdk: 8008167: IdentityHashMap.[keySet|values|entrySet].toArray speed-up In-Reply-To: <512A77C3.9070902@gmail.com> References: <20130214175538.236EC47A96@hg.openjdk.java.net> <512A149D.3030204@oracle.com> <512A3689.3000900@gmail.com> <512A609A.10002@oracle.com> <03FC4A5C-AF4D-45A2-908C-CFAC0AEA562B@oracle.com> <512A77C3.9070902@gmail.com> Message-ID: I have created an issue for fixing the introduced regression and created a regression test that would have caught the error (fix a bug, write a test...). 8008785: IdentityHashMap.values().toArray(V[]) broken by JDK-8008167 http://cr.openjdk.java.net/~mduigou/JDK-8008785/0/webrev Mike On Feb 24 2013, at 12:27 , Peter Levart wrote: > Hi Mike, > > I thought I saw that too when you commited the change, but then re-examinig the whole source in detail, I couldn't spot it again. I must have stared at the wrong third of change... > > Regards, Peter > > On 02/24/2013 07:53 PM, Mike Duigou wrote: >> Ouch, this would have been introduced by me. >> >> I will check to see how this could have passed the pre-commit regression testing. I suspect that a regression test needs to be improved. >> >> Mike >> >> On Feb 24 2013, at 10:48 , Alan Bateman wrote: >> >>> On 24/02/2013 15:49, Peter Levart wrote: >>>> Hi Alan, >>>> >>>> I checked and it seems all 3 IHM views [keySet|values|entrySet] have a fail-fast iterator implementation (IdentityHashMap.IdentityHashMapIterator) and all 3 are (were) using the iterator for .toArray implementations. So this patch tries to preserve the behavior when there is a concurrent modification (which is only possible from other thread and is illegal usage anyway since IHM is not thread-safe) while executing the toArray methods on the views... >>>> >>>> Do you see something I don't see? >>> My apologies, I see it does check the modification count in IdentityHashMapIterator.nextIndex. >>> >>> However, as this forced me to looks at the changes-set again then the copy loop in Values.toArray has caught by eye: >>> >>> for (int si = 0; si < tab.length; si += 2) { >>> if (tab[si++] != null) { // key present ? >>> // more elements than expected -> concurrent modification from other thread >>> if (ti >= size) { >>> throw new ConcurrentModificationException(); >>> } >>> a[ti++] = (T) tab[si]; // copy value >>> } >>> } >>> >>> Looks like si is incrementing by 3 rather than 2 (which ironically will cause a CME later because there will be fewer elements copied than expected). >>> >>> Do you concur? If so then we can create a bug to change this to test tab[si] and copy in tab[si+1]. >>> >>> -Alan > From forax at univ-mlv.fr Mon Feb 25 09:03:24 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 25 Feb 2013 10:03:24 +0100 Subject: Code review request In-Reply-To: <512AD584.2080902@oracle.com> References: <512672E6.1050708@oracle.com> <51289F3D.1010609@univ-mlv.fr> <512AD584.2080902@oracle.com> Message-ID: <512B28DC.7050101@univ-mlv.fr> On 02/25/2013 04:07 AM, David Holmes wrote: > On 23/02/2013 8:51 PM, Remi Forax wrote: >> On 02/21/2013 08:17 PM, Brian Goetz wrote: >>> At >>> http://cr.openjdk.java.net/~briangoetz/jdk-8008670/webrev/ >>> >>> I've posted a webrev for about half the classes in java.util.stream. >>> None of these are public classes, so there are no public API issues >>> here, but plenty of internal API issues, naming issues (ooh, a >>> bikeshed), and code quality issues. >>> >> >> Hi Brian, >> >> All protected fields should not be protected but package visible. >> Classes are package private so there is no need to use a modifier which >> offer a wider visibility. >> The same is true for constructors. > > I believe some of these may end up being public (TBD), in which case > better to define member accessibility as if they were already public > as it greatly simplifies the changes needed later. > > David > ----- Given that the release of jdk9 is at least two years from now, this API will change, one will come with a GPU pipeline (Sumatra?) or with a flattened bytecode pipeline (my pet project), so trying to figure out now what should be public or not is like predicting the future in a crystal ball. I think it's better to let all members package private and see later. BTW, I have no problem with protected methods, my main concern is protected fields or protected inner classes. R?mi > > >> For default method, some of them are marked public, some of them are >> not, >> what the coding convention said ? >> >> Code convention again, there is a lot of if/else with no curly braces, >> or only curly braces >> on the if part but not on the else part. >> Also, when a if block ends with a return, there is no need to use >> 'else', >> >> if (result != null) { >> foundResult(result); >> return result; >> } >> else >> return null; >> >> can be simply written: >> >> if (result != null) { >> foundResult(result); >> return result; >> } >> return null; >> >> >> All inner class should not have private constructors, like by example >> FindOp.FindTask, because >> the compiler will have to generate a special accessor for them when they >> are called from >> the outer class. >> >> In AbstractShortCircuitTask: >> It's not clear that cancel and sharedResult can be accessed directly >> given that they both have methods that acts as getter and setter. >> If they can be accessed directly, I think it's better to declare them >> private and to use getters. >> >> Depending on the ops, some of them do nullcheks of arguments at creating >> time (ForEachOp) , some of them don't (FindOp). >> In ForEachUntilOp, the 'consumer' is checked but 'until' is not. >> >> in ForEachOp, most of the keyword protected are not needed, >> ForEachUntilOp which inherits from ForEachOp is in the same package. >> >> In ForEachUntilOp, the constructor should be private (like for all the >> other ops). >> >> In MatchOp, line 110, I think the compiler bug is fixed now ? >> The enum MatchKind should not be public and all constructor of all inner >> classes should not be private. >> >> In OpsUtils, some static methods are public and some are not, >> >> in Tripwire: >> enabled should be in uppercase (ENABLED). >> method trip() should be: >> public static void trip(Class trippingClass, String msg) >> >> cheers, >> R?mi >> From dmitry.nadezhin at gmail.com Mon Feb 25 09:14:31 2013 From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin) Date: Mon, 25 Feb 2013 12:14:31 +0300 Subject: [PATCH] Sunbug 7131192: Optimize BigInteger.doubleValue(), floatValue() In-Reply-To: References: <511ED22B.8030800@oracle.com> <2867C9E8-F8FB-405A-8D00-7D4F90CA9628@oracle.com> <692B4DC6-88F3-4740-9B06-BDE56BB7B8B5@oracle.com> <370E52AA-385B-4117-B18E-71699243782F@oracle.com> Message-ID: Hi Louis, I looked at your fix of sunbug=6358355 "Fix Float.parseFloat to round correctly and preserve monotonicity". https://bugs.openjdk.java.net/show_bug.cgi?id=100208 I like how you separate String->double and String->float conversions. They both become more clear. However I found two issues. 1) The line in floatValue() method fValue = (float) doubleValue(); fValue can become Float.POSITIVE_INFINITY. It causes incorrect result on input like this String s = "340282356779733661637539395458142568447"; // 2^128 - 2^103 - 1 floatValue() returns Float.POSITIVE_INFINITY, the correct result is Float.MAX_VALUE . fValue can also become 0. It causes assertion error on input like this String s = "7.00649232162408535461864791644958065640130970938257885878534141944895541342930300743319094181060791015625E-46"; // 2^(-150) It can be fixed in such a way fValue = Math.max(Float.MIN_VALUE, Math.min(Float.MAX_VALUE, (float) doubleValue())); 2) The line in floatValue() method. // difference is exactly half an ULP // round to some other value maybe, then finish fValue += 0.5f*ulp( fValue, overvalue ); When fValue is subnormal, the right-hand sign evaluates to 0, fValue remains unchanged. This is similar to the bug 4396272 - Parsing doubles fails to follow IEEE for largest decimal that should yield 0. The result of String s = "7.00649232162408535461864791644958065640130970938257885878534141944895541342930300743319094181060791015625E-46"; // 2^(-150) is Float.MIN_VALUE, the correct result is 0. It can be fixed in such a way fValue = (float) (fValue + 0.5*ulp(fValue, overvalue)); Constant 0.5 instead of 0.5f causes double evaluation of right-hand side, so it doesn'nt underflow. Best Regards, -Dima From nils.loodin at oracle.com Mon Feb 25 09:23:24 2013 From: nils.loodin at oracle.com (Nils Loodin) Date: Mon, 25 Feb 2013 10:23:24 +0100 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <512A9C2B.1000304@oracle.com> References: <5115316A.8050109@oracle.com>, <51276E2A.40402@oracle.com> <512A9C2B.1000304@oracle.com> Message-ID: <512B2D8C.6010807@oracle.com> On 02/25/2013 12:03 AM, David Holmes wrote: > I'm getting very confused regarding the different threads on this. But > this webrev: > > http://cr.openjdk.java.net/~nloodin/exception-tracing/webrev.01/ > > shows the intrusive event tracing that I'm sure we said we would > grudgingly accept for 7u but not for JDK 8. > David et al: No! That showed the intrusive event tracing that we will not implement ever. It also has nothing to do with this code review, which is only to implement a performance counter. Regards, Nils Loodin From nils.loodin at oracle.com Mon Feb 25 09:29:16 2013 From: nils.loodin at oracle.com (Nils Loodin) Date: Mon, 25 Feb 2013 10:29:16 +0100 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <512A91A6.7090804@oracle.com> References: <5115316A.8050109@oracle.com> <51291AEB.3040005@gmail.com> <5129534A.8000500@oracle.com> <5129D45A.6010802@gmail.com> <5129EBE5.1030207@oracle.com> <512A7593.7040807@gmail.com> <512A7EB6.8090503@oracle.com> <512A8554.6080203@gmail.com> <512A8AC2.9020800@oracle.com> <512A8E95.9000902@gmail.com> <512A91A6.7090804@oracle.com> Message-ID: <512B2EEC.5050200@oracle.com> On 02/24/2013 11:18 PM, David Holmes wrote: > We've not-so-slightly hijacked Nils' thread here - apologies for that. David, Peter! Yes you did :) However, feel free to make it up to me by: 1. Suggest a good name for the counter 2. Plz to say yes to adding that counter 3. Profit! Regards, Nils Loodin From Alan.Bateman at oracle.com Mon Feb 25 09:51:07 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 25 Feb 2013 09:51:07 +0000 Subject: hg: jdk8/tl/jdk: 8008167: IdentityHashMap.[keySet|values|entrySet].toArray speed-up In-Reply-To: References: <20130214175538.236EC47A96@hg.openjdk.java.net> <512A149D.3030204@oracle.com> <512A3689.3000900@gmail.com> <512A609A.10002@oracle.com> <03FC4A5C-AF4D-45A2-908C-CFAC0AEA562B@oracle.com> <512A77C3.9070902@gmail.com> Message-ID: <512B340B.9020803@oracle.com> On 25/02/2013 04:06, Mike Duigou wrote: > I have created an issue for fixing the introduced regression and created a regression test that would have caught the error (fix a bug, write a test...). > > 8008785: IdentityHashMap.values().toArray(V[]) broken by JDK-8008167 > > http://cr.openjdk.java.net/~mduigou/JDK-8008785/0/webrev > > Mike The fix to IdentityHashMap looks good. It is surprising that it wasn't caught by tests in the jdk repository so a reminder that we always need to check that we have good test coverage when doing performance fixes. The webrev suggests you've replaced Map/Collisions.java and assume that is not the intention. Otherwise the new test looks okay, an alternative would have been to expand MOAT. -Alan. From Alan.Bateman at oracle.com Mon Feb 25 09:59:26 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 25 Feb 2013 09:59:26 +0000 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <512A7EB6.8090503@oracle.com> References: <5115316A.8050109@oracle.com> <51291AEB.3040005@gmail.com> <5129534A.8000500@oracle.com> <5129D45A.6010802@gmail.com> <5129EBE5.1030207@oracle.com> <512A7593.7040807@gmail.com> <512A7EB6.8090503@oracle.com> Message-ID: <512B35FE.6090407@oracle.com> On 24/02/2013 20:57, David Holmes wrote: > > Does jstat access these values directly or only via the synchronized > methods? If the latter then the value can't be "torn" that way. The > sync method will store the value in 2 32-bit registers, and the > variable load in jstat will take two instructions, but nothing can > touch those registers. The instrumentation/jvmstat buffer is a shared memory file so jstat (running in a different VM) just polls the counters so there isn't any Java-level synchronization. -Alan. From Alan.Bateman at oracle.com Mon Feb 25 10:15:41 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 25 Feb 2013 10:15:41 +0000 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <512B2D8C.6010807@oracle.com> References: <5115316A.8050109@oracle.com>, <51276E2A.40402@oracle.com> <512A9C2B.1000304@oracle.com> <512B2D8C.6010807@oracle.com> Message-ID: <512B39CD.40706@oracle.com> On 25/02/2013 09:23, Nils Loodin wrote: > > David et al: No! > > That showed the intrusive event tracing that we will not implement ever. > It also has nothing to do with this code review, which is only to > implement a performance counter. Just to confirm, this is the webrev that we should be reviewing: http://cr.openjdk.java.net/~nloodin/8007806/webrev.00/ and the only issue (I think) is the name of the counter where I think sun.* or jdk.* should be fine. -Alan. From nils.loodin at oracle.com Mon Feb 25 12:36:44 2013 From: nils.loodin at oracle.com (Nils Loodin) Date: Mon, 25 Feb 2013 13:36:44 +0100 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <512B39CD.40706@oracle.com> References: <5115316A.8050109@oracle.com>, <51276E2A.40402@oracle.com> <512A9C2B.1000304@oracle.com> <512B2D8C.6010807@oracle.com> <512B39CD.40706@oracle.com> Message-ID: <512B5ADC.9050400@oracle.com> On 02/25/2013 11:15 AM, Alan Bateman wrote: > On 25/02/2013 09:23, Nils Loodin wrote: >> >> David et al: No! >> >> That showed the intrusive event tracing that we will not implement ever. >> It also has nothing to do with this code review, which is only to >> implement a performance counter. > Just to confirm, this is the webrev that we should be reviewing: > > http://cr.openjdk.java.net/~nloodin/8007806/webrev.00/ > > and the only issue (I think) is the name of the counter where I think > sun.* or jdk.* should be fine. > > -Alan. Does this mean that you approve of http://cr.openjdk.java.net/~nloodin/8007806/webrev.01/ ? Regards, Nisse From peter.levart at gmail.com Mon Feb 25 13:30:02 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 25 Feb 2013 14:30:02 +0100 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <512B2EEC.5050200@oracle.com> References: <5115316A.8050109@oracle.com> <51291AEB.3040005@gmail.com> <5129534A.8000500@oracle.com> <5129D45A.6010802@gmail.com> <5129EBE5.1030207@oracle.com> <512A7593.7040807@gmail.com> <512A7EB6.8090503@oracle.com> <512A8554.6080203@gmail.com> <512A8AC2.9020800@oracle.com> <512A8E95.9000902@gmail.com> <512A91A6.7090804@oracle.com> <512B2EEC.5050200@oracle.com> Message-ID: <512B675A.7090207@gmail.com> On 02/25/2013 10:29 AM, Nils Loodin wrote: > On 02/24/2013 11:18 PM, David Holmes wrote: >> We've not-so-slightly hijacked Nils' thread here - apologies for that. > > David, Peter! > > Yes you did :) > However, feel free to make it up to me by: > 1. Suggest a good name for the counter As Jason Mehrens pointed out in this thread, the "thrownThrowables" might be misleading if the counter is incremented in the Throwable constructors (or are you going to instrument the throw sites?). So it might better be called what it is: "constructedThrowables". Yes, this is a common idiom: throw new ThrowableSubclass(...); ...but the number of thrown and constructed throwables may diverge considerably in situations like for example: - preallocated throwable instances used (and reused) as a form of "long return" (from lambdas). - deserialized throwables on RMI clients that are thrown on the server side, transfered over the wire and re-thrown on client side (de-seriailization does not call the constructor) > 2. Plz to say yes to adding that counter It's not my call but I would be concerned about performance. Current set of counters that are updated from Java is not that critical, but having a counter of constructed objects updated via synchronized method (or a CAS) can have a negative impact on application performance. See what happened with HashMap constructor. The same could happen in situations where Throwable subclass is (miss)used for example to "long return" a result from... say a lambda (again). This is perfectly performant and scalable now (just override the Throwable.fillInStackTrace with empty implementation and you get a "long return(value)"). I'm not saying that this is a good practice, but such usages will emerge with lambdas. So although this thread is only about counter name, I think care should be put also on it's implementation. Perhaps with an option to disable instrumentation if requested from user? On a per-Throwable-subclass basis (like Logger levels)? Using external configuration (system properties) or special @DontTrace annotation? > 3. Profit! :-) Regards, Peter > > Regards, > Nils Loodin From sundararajan.athijegannathan at oracle.com Mon Feb 25 13:46:47 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Mon, 25 Feb 2013 13:46:47 +0000 Subject: hg: jdk8/tl/nashorn: 119 new changesets Message-ID: <20130225134751.BFF1647E25@hg.openjdk.java.net> Changeset: b8a1b238c77c Author: duke Date: 2007-12-01 00:00 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b8a1b238c77c Initial load + .hgignore + .jcheck/conf Changeset: 6031a0bc0ae2 Author: jcoomes Date: 2012-12-20 14:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/6031a0bc0ae2 8005364: initial hg tags for nashorn repo Reviewed-by: amurillo + .hgtags Changeset: da1e581c933b Author: jlaskey Date: 2012-12-21 16:36 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/da1e581c933b 8005403: Open-source Nashorn Reviewed-by: attila, hannesw, lagergren, sundar Contributed-by: james.laskey at oracle.com, akhil.arora at oracle.com, andreas.woess at jku.at, attila.szegedi at oracle.com, hannes.wallnoefer at oracle.com, henry.jen at oracle.com, marcus.lagergren at oracle.com, pavel.semenov at oracle.com, pavel.stepanov at oracle.com, petr.hejl at oracle.com, petr.pisl at oracle.com, sundararajan.athijegannathan at oracle.com ! .hgignore + ASSEMBLY_EXCEPTION + LICENSE + README + RELEASE_README + THIRD_PARTY_README + bin/checkintest.sh + bin/fixorphantests.sh + bin/fixwhitespace.sh + bin/jjs + bin/jjs.bat + bin/jjssecure + bin/jjssecure.bat + bin/nashorn + bin/nashorn.bat + bin/rm-non-tracked.sh + bin/verbose_octane.bat + bin/verbose_octane.sh + buildtools/nasgen/README + buildtools/nasgen/build.xml + buildtools/nasgen/nasgen.iml + buildtools/nasgen/project.properties + buildtools/nasgen/src/META-INF/MANIFEST.MF + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/Main.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MemberInfo.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MethodGenerator.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/NullVisitor.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/PrototypeGenerator.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfo.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfoCollector.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInstrumentor.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java + docs/DEVELOPER_README + docs/genshelldoc.js + make/Makefile + make/build-benchmark.xml + make/build-nasgen.xml + make/build.xml + make/nbproject/ide-file-targets.xml + make/nbproject/ide-targets.xml + make/nbproject/jdk.xml + make/nbproject/nbjdk.properties + make/nbproject/nbjdk.xml + make/nbproject/project.xml + make/project.properties + samples/counters.js + samples/letter.js + samples/parser.js + samples/shell.js + samples/test.js + samples/uniq.js + src/META-INF/MANIFEST.MF + src/META-INF/services/javax.script.ScriptEngineFactory + src/jdk/nashorn/api/scripting/NashornException.java + src/jdk/nashorn/api/scripting/NashornScriptEngine.java + src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java + src/jdk/nashorn/api/scripting/ScriptObjectMirror.java + src/jdk/nashorn/api/scripting/package-info.java + src/jdk/nashorn/api/scripting/resources/engine.js + src/jdk/nashorn/internal/codegen/AccessSpecializer.java + src/jdk/nashorn/internal/codegen/BranchOptimizer.java + src/jdk/nashorn/internal/codegen/ClassEmitter.java + src/jdk/nashorn/internal/codegen/CodeGenerator.java + src/jdk/nashorn/internal/codegen/CompileUnit.java + src/jdk/nashorn/internal/codegen/Compiler.java + src/jdk/nashorn/internal/codegen/CompilerConstants.java + src/jdk/nashorn/internal/codegen/ConstantData.java + src/jdk/nashorn/internal/codegen/Emitter.java + src/jdk/nashorn/internal/codegen/Frame.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/Namespace.java + src/jdk/nashorn/internal/codegen/RuntimeCallSite.java + src/jdk/nashorn/internal/codegen/SharedScopeCall.java + src/jdk/nashorn/internal/codegen/Splitter.java + src/jdk/nashorn/internal/codegen/Transform.java + src/jdk/nashorn/internal/codegen/WeighNodes.java + src/jdk/nashorn/internal/codegen/objects/FieldObjectCreator.java + src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java + src/jdk/nashorn/internal/codegen/objects/MapCreator.java + src/jdk/nashorn/internal/codegen/objects/ObjectClassGenerator.java + src/jdk/nashorn/internal/codegen/objects/ObjectCreator.java + src/jdk/nashorn/internal/codegen/objects/ObjectMapCreator.java + src/jdk/nashorn/internal/codegen/types/ArrayType.java + src/jdk/nashorn/internal/codegen/types/BitwiseType.java + src/jdk/nashorn/internal/codegen/types/BooleanType.java + src/jdk/nashorn/internal/codegen/types/BytecodeArrayOps.java + src/jdk/nashorn/internal/codegen/types/BytecodeBitwiseOps.java + src/jdk/nashorn/internal/codegen/types/BytecodeNumericOps.java + src/jdk/nashorn/internal/codegen/types/BytecodeOps.java + src/jdk/nashorn/internal/codegen/types/IntType.java + src/jdk/nashorn/internal/codegen/types/LongType.java + src/jdk/nashorn/internal/codegen/types/NumberType.java + src/jdk/nashorn/internal/codegen/types/NumericType.java + src/jdk/nashorn/internal/codegen/types/ObjectType.java + src/jdk/nashorn/internal/codegen/types/Type.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/BreakableNode.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/FunctionCall.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/LabeledNode.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/PropertyKey.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/annotations/ChildNode.java + src/jdk/nashorn/internal/ir/annotations/Ignore.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/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/objects/AccessorPropertyDescriptor.java + src/jdk/nashorn/internal/objects/ArrayBufferView.java + src/jdk/nashorn/internal/objects/DataPropertyDescriptor.java + src/jdk/nashorn/internal/objects/DateParser.java + src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java + src/jdk/nashorn/internal/objects/Global.java + src/jdk/nashorn/internal/objects/NativeArguments.java + src/jdk/nashorn/internal/objects/NativeArray.java + src/jdk/nashorn/internal/objects/NativeArrayBuffer.java + src/jdk/nashorn/internal/objects/NativeBoolean.java + src/jdk/nashorn/internal/objects/NativeDate.java + src/jdk/nashorn/internal/objects/NativeDebug.java + src/jdk/nashorn/internal/objects/NativeError.java + src/jdk/nashorn/internal/objects/NativeEvalError.java + src/jdk/nashorn/internal/objects/NativeFloat32Array.java + src/jdk/nashorn/internal/objects/NativeFloat64Array.java + src/jdk/nashorn/internal/objects/NativeFunction.java + src/jdk/nashorn/internal/objects/NativeInt16Array.java + src/jdk/nashorn/internal/objects/NativeInt32Array.java + src/jdk/nashorn/internal/objects/NativeInt8Array.java + src/jdk/nashorn/internal/objects/NativeJSAdapter.java + src/jdk/nashorn/internal/objects/NativeJSON.java + src/jdk/nashorn/internal/objects/NativeJava.java + src/jdk/nashorn/internal/objects/NativeJavaImporter.java + src/jdk/nashorn/internal/objects/NativeMath.java + src/jdk/nashorn/internal/objects/NativeNumber.java + src/jdk/nashorn/internal/objects/NativeObject.java + src/jdk/nashorn/internal/objects/NativeRangeError.java + src/jdk/nashorn/internal/objects/NativeReferenceError.java + src/jdk/nashorn/internal/objects/NativeRegExp.java + src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java + src/jdk/nashorn/internal/objects/NativeStrictArguments.java + src/jdk/nashorn/internal/objects/NativeString.java + src/jdk/nashorn/internal/objects/NativeSyntaxError.java + src/jdk/nashorn/internal/objects/NativeTypeError.java + src/jdk/nashorn/internal/objects/NativeURIError.java + src/jdk/nashorn/internal/objects/NativeUint16Array.java + src/jdk/nashorn/internal/objects/NativeUint32Array.java + src/jdk/nashorn/internal/objects/NativeUint8Array.java + src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java + src/jdk/nashorn/internal/objects/PrototypeObject.java + src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java + src/jdk/nashorn/internal/objects/annotations/Attribute.java + src/jdk/nashorn/internal/objects/annotations/Constructor.java + src/jdk/nashorn/internal/objects/annotations/Function.java + src/jdk/nashorn/internal/objects/annotations/Getter.java + src/jdk/nashorn/internal/objects/annotations/Property.java + src/jdk/nashorn/internal/objects/annotations/ScriptClass.java + src/jdk/nashorn/internal/objects/annotations/Setter.java + src/jdk/nashorn/internal/objects/annotations/SpecializedConstructor.java + src/jdk/nashorn/internal/objects/annotations/SpecializedFunction.java + src/jdk/nashorn/internal/objects/annotations/Where.java + src/jdk/nashorn/internal/objects/package-info.java + src/jdk/nashorn/internal/parser/AbstractParser.java + src/jdk/nashorn/internal/parser/JSONParser.java + src/jdk/nashorn/internal/parser/Lexer.java + src/jdk/nashorn/internal/parser/Parser.java + src/jdk/nashorn/internal/parser/RegExp.java + src/jdk/nashorn/internal/parser/RegExpScanner.java + src/jdk/nashorn/internal/parser/Scanner.java + src/jdk/nashorn/internal/parser/Token.java + src/jdk/nashorn/internal/parser/TokenKind.java + src/jdk/nashorn/internal/parser/TokenLookup.java + src/jdk/nashorn/internal/parser/TokenStream.java + src/jdk/nashorn/internal/parser/TokenType.java + src/jdk/nashorn/internal/runtime/AccessorProperty.java + src/jdk/nashorn/internal/runtime/BitVector.java + src/jdk/nashorn/internal/runtime/CodeInstaller.java + src/jdk/nashorn/internal/runtime/ConsString.java + src/jdk/nashorn/internal/runtime/Context.java + src/jdk/nashorn/internal/runtime/Debug.java + src/jdk/nashorn/internal/runtime/DebugLogger.java + src/jdk/nashorn/internal/runtime/DefaultPropertyAccess.java + src/jdk/nashorn/internal/runtime/ECMAErrors.java + src/jdk/nashorn/internal/runtime/ECMAException.java + src/jdk/nashorn/internal/runtime/ErrorManager.java + src/jdk/nashorn/internal/runtime/FindProperty.java + src/jdk/nashorn/internal/runtime/FunctionScope.java + src/jdk/nashorn/internal/runtime/GlobalFunctions.java + src/jdk/nashorn/internal/runtime/GlobalObject.java + src/jdk/nashorn/internal/runtime/JSErrorType.java + src/jdk/nashorn/internal/runtime/JSType.java + src/jdk/nashorn/internal/runtime/Logging.java + src/jdk/nashorn/internal/runtime/NashornLoader.java + src/jdk/nashorn/internal/runtime/NativeJavaPackage.java + src/jdk/nashorn/internal/runtime/NumberToString.java + src/jdk/nashorn/internal/runtime/ParserException.java + src/jdk/nashorn/internal/runtime/Property.java + src/jdk/nashorn/internal/runtime/PropertyAccess.java + src/jdk/nashorn/internal/runtime/PropertyDescriptor.java + src/jdk/nashorn/internal/runtime/PropertyHashMap.java + src/jdk/nashorn/internal/runtime/PropertyListener.java + src/jdk/nashorn/internal/runtime/PropertyListenerManager.java + src/jdk/nashorn/internal/runtime/PropertyMap.java + src/jdk/nashorn/internal/runtime/QuotedStringTokenizer.java + src/jdk/nashorn/internal/runtime/RegExpMatch.java + src/jdk/nashorn/internal/runtime/Scope.java + src/jdk/nashorn/internal/runtime/ScriptFunction.java + src/jdk/nashorn/internal/runtime/ScriptLoader.java + src/jdk/nashorn/internal/runtime/ScriptObject.java + src/jdk/nashorn/internal/runtime/ScriptRuntime.java + src/jdk/nashorn/internal/runtime/ScriptingFunctions.java + src/jdk/nashorn/internal/runtime/Source.java + src/jdk/nashorn/internal/runtime/SpillProperty.java + src/jdk/nashorn/internal/runtime/StructureLoader.java + src/jdk/nashorn/internal/runtime/URIUtils.java + src/jdk/nashorn/internal/runtime/Undefined.java + src/jdk/nashorn/internal/runtime/UserAccessorProperty.java + src/jdk/nashorn/internal/runtime/Version.java + src/jdk/nashorn/internal/runtime/WithObject.java + src/jdk/nashorn/internal/runtime/arrays/ArrayData.java + src/jdk/nashorn/internal/runtime/arrays/ArrayFilter.java + src/jdk/nashorn/internal/runtime/arrays/ArrayIndex.java + src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java + src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java + src/jdk/nashorn/internal/runtime/arrays/DeletedArrayFilter.java + src/jdk/nashorn/internal/runtime/arrays/DeletedRangeArrayFilter.java + src/jdk/nashorn/internal/runtime/arrays/EmptyArrayLikeIterator.java + src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java + src/jdk/nashorn/internal/runtime/arrays/IntArrayData.java + src/jdk/nashorn/internal/runtime/arrays/InvalidArrayIndexException.java + src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java + src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java + src/jdk/nashorn/internal/runtime/arrays/MapIterator.java + src/jdk/nashorn/internal/runtime/arrays/NoTypeArrayData.java + src/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java + src/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java + src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java + src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java + src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java + src/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java + src/jdk/nashorn/internal/runtime/arrays/UndefinedArrayFilter.java + src/jdk/nashorn/internal/runtime/linker/Bootstrap.java + src/jdk/nashorn/internal/runtime/linker/InvokeByName.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/Mangler.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/NashornCallSiteDescriptor.java + src/jdk/nashorn/internal/runtime/linker/NashornGuardedInvocation.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/PrimitiveLookup.java + src/jdk/nashorn/internal/runtime/options/KeyValueOption.java + src/jdk/nashorn/internal/runtime/options/Option.java + src/jdk/nashorn/internal/runtime/options/OptionTemplate.java + src/jdk/nashorn/internal/runtime/options/Options.java + src/jdk/nashorn/internal/runtime/options/ValueOption.java + src/jdk/nashorn/internal/runtime/resources/Messages.properties + src/jdk/nashorn/internal/runtime/resources/Options.properties + src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js + src/jdk/nashorn/internal/runtime/resources/parser.js + src/jdk/nashorn/internal/runtime/resources/version.properties-template + src/jdk/nashorn/internal/scripts/JO$.java + src/jdk/nashorn/internal/scripts/JS$.java + src/jdk/nashorn/tools/Shell.java + src/jdk/nashorn/tools/resources/Shell.properties + src/jdk/nashorn/tools/resources/shell.js + src/netscape/javascript/JSObject.java + src/overview.html + test/README + test/examples/dual-fields-micro.js + test/examples/innerbench.js + test/examples/typechain.js + test/lib/benchmark.js + test/opt/add.js + test/opt/add_constant.js + test/opt/add_reuse_callsite.js + test/opt/add_revert2.js + test/opt/cascade_specialize.js + test/script/assert.js + test/script/basic/NASHORN-100.js + test/script/basic/NASHORN-100.js.EXPECTED + test/script/basic/NASHORN-101.js + test/script/basic/NASHORN-101.js.EXPECTED + test/script/basic/NASHORN-102.js + test/script/basic/NASHORN-102.js.EXPECTED + test/script/basic/NASHORN-103.js + test/script/basic/NASHORN-104.js + test/script/basic/NASHORN-104.js.EXPECTED + test/script/basic/NASHORN-105.js + test/script/basic/NASHORN-105.js.EXPECTED + test/script/basic/NASHORN-106.js + test/script/basic/NASHORN-106.js.EXPECTED + test/script/basic/NASHORN-107.js + test/script/basic/NASHORN-108.js + test/script/basic/NASHORN-108.js.EXPECTED + test/script/basic/NASHORN-109.js + test/script/basic/NASHORN-109.js.EXPECTED + test/script/basic/NASHORN-11.js + test/script/basic/NASHORN-11.js.EXPECTED + test/script/basic/NASHORN-111.js + test/script/basic/NASHORN-111.js.EXPECTED + test/script/basic/NASHORN-113.js + test/script/basic/NASHORN-113.js.EXPECTED + test/script/basic/NASHORN-114.js + test/script/basic/NASHORN-115.js + test/script/basic/NASHORN-115.js.EXPECTED + test/script/basic/NASHORN-117.js + test/script/basic/NASHORN-118.js + test/script/basic/NASHORN-118.js.EXPECTED + test/script/basic/NASHORN-119.js + test/script/basic/NASHORN-119.js.EXPECTED + test/script/basic/NASHORN-12.js + test/script/basic/NASHORN-120.js + test/script/basic/NASHORN-122.js + test/script/basic/NASHORN-122.js.EXPECTED + test/script/basic/NASHORN-126.js + test/script/basic/NASHORN-126.js.EXPECTED + test/script/basic/NASHORN-127.js + test/script/basic/NASHORN-127.js.EXPECTED + test/script/basic/NASHORN-130.js + test/script/basic/NASHORN-132.js + test/script/basic/NASHORN-132.js.EXPECTED + test/script/basic/NASHORN-133.js + test/script/basic/NASHORN-133.js.EXPECTED + test/script/basic/NASHORN-135.js + test/script/basic/NASHORN-136.js + test/script/basic/NASHORN-136.js.EXPECTED + test/script/basic/NASHORN-14.js + test/script/basic/NASHORN-14.js.EXPECTED + test/script/basic/NASHORN-148.js + test/script/basic/NASHORN-148.js.EXPECTED + test/script/basic/NASHORN-15.js + test/script/basic/NASHORN-15.js.EXPECTED + test/script/basic/NASHORN-153.js + test/script/basic/NASHORN-156.js + test/script/basic/NASHORN-157.js + test/script/basic/NASHORN-163.js + test/script/basic/NASHORN-163.js.EXPECTED + test/script/basic/NASHORN-164.js + test/script/basic/NASHORN-165.js + test/script/basic/NASHORN-166.js + test/script/basic/NASHORN-168.js + test/script/basic/NASHORN-168.js.EXPECTED + test/script/basic/NASHORN-169.js + test/script/basic/NASHORN-172.js + test/script/basic/NASHORN-173.js + test/script/basic/NASHORN-173.js.EXPECTED + test/script/basic/NASHORN-174.js + test/script/basic/NASHORN-175.js + test/script/basic/NASHORN-176.js + test/script/basic/NASHORN-177.js + test/script/basic/NASHORN-177.js.EXPECTED + test/script/basic/NASHORN-178.js + test/script/basic/NASHORN-178.js.EXPECTED + test/script/basic/NASHORN-179.js + test/script/basic/NASHORN-18.js + test/script/basic/NASHORN-18.js.EXPECTED + test/script/basic/NASHORN-181.js + test/script/basic/NASHORN-182.js + test/script/basic/NASHORN-183.js + test/script/basic/NASHORN-184.js + test/script/basic/NASHORN-184.js.EXPECTED + test/script/basic/NASHORN-185.js + test/script/basic/NASHORN-185.js.EXPECTED + test/script/basic/NASHORN-187.js + test/script/basic/NASHORN-188.js + test/script/basic/NASHORN-188.js.EXPECTED + test/script/basic/NASHORN-19.js + test/script/basic/NASHORN-19.js.EXPECTED + test/script/basic/NASHORN-190.js + test/script/basic/NASHORN-192.js + test/script/basic/NASHORN-194.js + test/script/basic/NASHORN-196.js + test/script/basic/NASHORN-198.js + test/script/basic/NASHORN-20.js + test/script/basic/NASHORN-20.js.EXPECTED + test/script/basic/NASHORN-201.js + test/script/basic/NASHORN-202.js + test/script/basic/NASHORN-203.js + test/script/basic/NASHORN-204.js + test/script/basic/NASHORN-205.js + test/script/basic/NASHORN-206.js + test/script/basic/NASHORN-207.js + test/script/basic/NASHORN-207_2.js + test/script/basic/NASHORN-208.js + test/script/basic/NASHORN-208.js.EXPECTED + test/script/basic/NASHORN-209.js + test/script/basic/NASHORN-209.js.EXPECTED + test/script/basic/NASHORN-21.js + test/script/basic/NASHORN-21.js.EXPECTED + test/script/basic/NASHORN-211.js + test/script/basic/NASHORN-212.js + test/script/basic/NASHORN-213.js + test/script/basic/NASHORN-215.js + test/script/basic/NASHORN-215.js.EXPECTED + test/script/basic/NASHORN-216.js + test/script/basic/NASHORN-217.js + test/script/basic/NASHORN-217.js.EXPECTED + test/script/basic/NASHORN-219.js + test/script/basic/NASHORN-219.js.EXPECTED + test/script/basic/NASHORN-22.js + test/script/basic/NASHORN-22.js.EXPECTED + test/script/basic/NASHORN-221.js + test/script/basic/NASHORN-222.js + test/script/basic/NASHORN-223.js + test/script/basic/NASHORN-225.js + test/script/basic/NASHORN-226.js + test/script/basic/NASHORN-227.js + test/script/basic/NASHORN-228.js + test/script/basic/NASHORN-229.js + test/script/basic/NASHORN-229_subtest.js + test/script/basic/NASHORN-23.js + test/script/basic/NASHORN-23.js.EXPECTED + test/script/basic/NASHORN-232.js + test/script/basic/NASHORN-234.js + test/script/basic/NASHORN-235.js + test/script/basic/NASHORN-236.js + test/script/basic/NASHORN-237.js + test/script/basic/NASHORN-239.js + test/script/basic/NASHORN-24.js + test/script/basic/NASHORN-24.js.EXPECTED + test/script/basic/NASHORN-241.js + test/script/basic/NASHORN-242.js + test/script/basic/NASHORN-245.js + test/script/basic/NASHORN-247.js + test/script/basic/NASHORN-25.js + test/script/basic/NASHORN-25.js.EXPECTED + test/script/basic/NASHORN-251.js + test/script/basic/NASHORN-252.js + test/script/basic/NASHORN-253.js + test/script/basic/NASHORN-256.js + test/script/basic/NASHORN-258.js + test/script/basic/NASHORN-258.js.EXPECTED + test/script/basic/NASHORN-26.js + test/script/basic/NASHORN-26.js.EXPECTED + test/script/basic/NASHORN-260.js + test/script/basic/NASHORN-261.js + test/script/basic/NASHORN-262.js + test/script/basic/NASHORN-263.js + test/script/basic/NASHORN-264.js + test/script/basic/NASHORN-265.js + test/script/basic/NASHORN-265.js.EXPECTED + test/script/basic/NASHORN-266.js + test/script/basic/NASHORN-269.js + test/script/basic/NASHORN-27.js + test/script/basic/NASHORN-27.js.EXPECTED + test/script/basic/NASHORN-270.js + test/script/basic/NASHORN-271.js + test/script/basic/NASHORN-275.js + test/script/basic/NASHORN-276.js + test/script/basic/NASHORN-277.js + test/script/basic/NASHORN-278.js + test/script/basic/NASHORN-28.js + test/script/basic/NASHORN-28.js.EXPECTED + test/script/basic/NASHORN-281.js + test/script/basic/NASHORN-284.js + test/script/basic/NASHORN-284.js.EXPECTED + test/script/basic/NASHORN-285.js + test/script/basic/NASHORN-285.js.EXPECTED + test/script/basic/NASHORN-288.js + test/script/basic/NASHORN-29.js + test/script/basic/NASHORN-29.js.EXPECTED + test/script/basic/NASHORN-293.js + test/script/basic/NASHORN-293.js.EXPECTED + test/script/basic/NASHORN-294.js + test/script/basic/NASHORN-296.js + test/script/basic/NASHORN-297.js + test/script/basic/NASHORN-30.js + test/script/basic/NASHORN-30.js.EXPECTED + test/script/basic/NASHORN-300.js + test/script/basic/NASHORN-301.js + test/script/basic/NASHORN-301.js.EXPECTED + test/script/basic/NASHORN-304.js + test/script/basic/NASHORN-310.js + test/script/basic/NASHORN-310.js.EXPECTED + test/script/basic/NASHORN-318.js + test/script/basic/NASHORN-318.js.EXPECTED + test/script/basic/NASHORN-32.js + test/script/basic/NASHORN-32.js.EXPECTED + test/script/basic/NASHORN-321.js + test/script/basic/NASHORN-321.js.EXPECTED + test/script/basic/NASHORN-323.js + test/script/basic/NASHORN-323.js.EXPECTED + test/script/basic/NASHORN-324.js + test/script/basic/NASHORN-33.js + test/script/basic/NASHORN-33.js.EXPECTED + test/script/basic/NASHORN-331.js + test/script/basic/NASHORN-331.js.EXPECTED + test/script/basic/NASHORN-337.js + test/script/basic/NASHORN-337.js.EXPECTED + test/script/basic/NASHORN-34.js + test/script/basic/NASHORN-34.js.EXPECTED + test/script/basic/NASHORN-340.js + test/script/basic/NASHORN-340.js.EXPECTED + test/script/basic/NASHORN-349.js + test/script/basic/NASHORN-354.js + test/script/basic/NASHORN-354.js.EXPECTED + test/script/basic/NASHORN-355.js + test/script/basic/NASHORN-355.js.EXPECTED + test/script/basic/NASHORN-36.js + test/script/basic/NASHORN-36.js.EXPECTED + test/script/basic/NASHORN-365.js + test/script/basic/NASHORN-366.js + test/script/basic/NASHORN-366.js.EXPECTED + test/script/basic/NASHORN-368.js + test/script/basic/NASHORN-368.js.EXPECTED + test/script/basic/NASHORN-37.js + test/script/basic/NASHORN-37.js.EXPECTED + test/script/basic/NASHORN-375.js + test/script/basic/NASHORN-376.js + test/script/basic/NASHORN-377.js + test/script/basic/NASHORN-377.js.EXPECTED + test/script/basic/NASHORN-378.js + test/script/basic/NASHORN-38.js + test/script/basic/NASHORN-38.js.EXPECTED + test/script/basic/NASHORN-380.js + test/script/basic/NASHORN-380.js.EXPECTED + test/script/basic/NASHORN-381.js + test/script/basic/NASHORN-382.js + test/script/basic/NASHORN-383.js + test/script/basic/NASHORN-384.js + test/script/basic/NASHORN-384.js.EXPECTED + test/script/basic/NASHORN-385.js + test/script/basic/NASHORN-385.js.EXPECTED + test/script/basic/NASHORN-389.js + test/script/basic/NASHORN-389.js.EXPECTED + test/script/basic/NASHORN-393.js + test/script/basic/NASHORN-393.js.EXPECTED + test/script/basic/NASHORN-394.js + test/script/basic/NASHORN-394.js.EXPECTED + test/script/basic/NASHORN-396.js + test/script/basic/NASHORN-397.js + test/script/basic/NASHORN-398.js + test/script/basic/NASHORN-40.js + test/script/basic/NASHORN-40.js.EXPECTED + test/script/basic/NASHORN-400.js + test/script/basic/NASHORN-400.js.EXPECTED + test/script/basic/NASHORN-401.js + test/script/basic/NASHORN-401.js.EXPECTED + test/script/basic/NASHORN-402.js + test/script/basic/NASHORN-402.js.EXPECTED + test/script/basic/NASHORN-404.js + test/script/basic/NASHORN-405.js + test/script/basic/NASHORN-405.js.EXPECTED + test/script/basic/NASHORN-406.js + test/script/basic/NASHORN-408.js + test/script/basic/NASHORN-408.js.EXPECTED + test/script/basic/NASHORN-415.js + test/script/basic/NASHORN-415.js.EXPECTED + test/script/basic/NASHORN-416.js + test/script/basic/NASHORN-417.js + test/script/basic/NASHORN-418.js + test/script/basic/NASHORN-420.js + test/script/basic/NASHORN-421.js + test/script/basic/NASHORN-423.js + test/script/basic/NASHORN-423.js.EXPECTED + test/script/basic/NASHORN-423a.js + test/script/basic/NASHORN-424.js + test/script/basic/NASHORN-424.js.EXPECTED + test/script/basic/NASHORN-425.js + test/script/basic/NASHORN-425.js.EXPECTED + test/script/basic/NASHORN-426.js + test/script/basic/NASHORN-427.js + test/script/basic/NASHORN-428.js + test/script/basic/NASHORN-429.js + test/script/basic/NASHORN-432.js + test/script/basic/NASHORN-433.js + test/script/basic/NASHORN-434.js + test/script/basic/NASHORN-435.js + test/script/basic/NASHORN-437.js + test/script/basic/NASHORN-44.js + test/script/basic/NASHORN-44.js.EXPECTED + test/script/basic/NASHORN-441.js + test/script/basic/NASHORN-441.js.EXPECTED + test/script/basic/NASHORN-442.js + test/script/basic/NASHORN-443.js + test/script/basic/NASHORN-444.js + test/script/basic/NASHORN-444.js.EXPECTED + test/script/basic/NASHORN-445.js + test/script/basic/NASHORN-446.js + test/script/basic/NASHORN-447.js + test/script/basic/NASHORN-448.js + test/script/basic/NASHORN-449.js + test/script/basic/NASHORN-449.js.EXPECTED + test/script/basic/NASHORN-45.js + test/script/basic/NASHORN-45.js.EXPECTED + test/script/basic/NASHORN-450.js + test/script/basic/NASHORN-452.js + test/script/basic/NASHORN-459.js + test/script/basic/NASHORN-46.js + test/script/basic/NASHORN-46.js.EXPECTED + test/script/basic/NASHORN-462.js + test/script/basic/NASHORN-463.js + test/script/basic/NASHORN-468.js + test/script/basic/NASHORN-47.js + test/script/basic/NASHORN-473.js + test/script/basic/NASHORN-473.js.EXPECTED + test/script/basic/NASHORN-474.js + test/script/basic/NASHORN-474.js.EXPECTED + test/script/basic/NASHORN-478.js + test/script/basic/NASHORN-48.js + test/script/basic/NASHORN-48.js.EXPECTED + test/script/basic/NASHORN-481.js + test/script/basic/NASHORN-481.js.EXPECTED + test/script/basic/NASHORN-482.js + test/script/basic/NASHORN-484.js + test/script/basic/NASHORN-484.js.EXPECTED + test/script/basic/NASHORN-486.js + test/script/basic/NASHORN-487.js + test/script/basic/NASHORN-488.js + test/script/basic/NASHORN-49.js + test/script/basic/NASHORN-49.js.EXPECTED + test/script/basic/NASHORN-490.js + test/script/basic/NASHORN-494.js + test/script/basic/NASHORN-497.js + test/script/basic/NASHORN-498.js + test/script/basic/NASHORN-499.js + test/script/basic/NASHORN-50.js + test/script/basic/NASHORN-50.js.EXPECTED + test/script/basic/NASHORN-500.js + test/script/basic/NASHORN-503.js + test/script/basic/NASHORN-503.js.EXPECTED + test/script/basic/NASHORN-51.js + test/script/basic/NASHORN-51.js.EXPECTED + test/script/basic/NASHORN-511.js + test/script/basic/NASHORN-515.js + test/script/basic/NASHORN-515.js.EXPECTED + test/script/basic/NASHORN-516.js + test/script/basic/NASHORN-52.js + test/script/basic/NASHORN-534.js + test/script/basic/NASHORN-534.js.EXPECTED + test/script/basic/NASHORN-535.js + test/script/basic/NASHORN-535.js.EXPECTED + test/script/basic/NASHORN-544.js + test/script/basic/NASHORN-55.js + test/script/basic/NASHORN-554.js + test/script/basic/NASHORN-554.js.EXPECTED + test/script/basic/NASHORN-556.js + test/script/basic/NASHORN-556.js.EXPECTED + test/script/basic/NASHORN-56.js + test/script/basic/NASHORN-56.js.EXPECTED + test/script/basic/NASHORN-562.js + test/script/basic/NASHORN-565.js + test/script/basic/NASHORN-565.js.EXPECTED + test/script/basic/NASHORN-575.js + test/script/basic/NASHORN-575.js.EXPECTED + test/script/basic/NASHORN-58.js + test/script/basic/NASHORN-58.js.EXPECTED + test/script/basic/NASHORN-59.js + test/script/basic/NASHORN-59.js.EXPECTED + test/script/basic/NASHORN-592.js + test/script/basic/NASHORN-592.js.EXPECTED + test/script/basic/NASHORN-597.js + test/script/basic/NASHORN-597.js.EXPECTED + test/script/basic/NASHORN-60.js + test/script/basic/NASHORN-60.js.EXPECTED + test/script/basic/NASHORN-609.js + test/script/basic/NASHORN-609.js.EXPECTED + test/script/basic/NASHORN-61.js + test/script/basic/NASHORN-61.js.EXPECTED + test/script/basic/NASHORN-62.js + test/script/basic/NASHORN-62.js.EXPECTED + test/script/basic/NASHORN-620.js + test/script/basic/NASHORN-620.js.EXPECTED + test/script/basic/NASHORN-623.js + test/script/basic/NASHORN-623.js.EXPECTED + test/script/basic/NASHORN-627.js + test/script/basic/NASHORN-627.js.EXPECTED + test/script/basic/NASHORN-63.js + test/script/basic/NASHORN-631.js.EXPECTED + test/script/basic/NASHORN-637.js + test/script/basic/NASHORN-637.js.EXPECTED + test/script/basic/NASHORN-638.js + test/script/basic/NASHORN-638.js.EXPECTED + test/script/basic/NASHORN-639.js + test/script/basic/NASHORN-64.js + test/script/basic/NASHORN-642.js + test/script/basic/NASHORN-642.js.EXPECTED + test/script/basic/NASHORN-646.js + test/script/basic/NASHORN-653.js + test/script/basic/NASHORN-658.js + test/script/basic/NASHORN-659.js + test/script/basic/NASHORN-66.js + test/script/basic/NASHORN-66.js.EXPECTED + test/script/basic/NASHORN-664.js + test/script/basic/NASHORN-665.js + test/script/basic/NASHORN-67.js + test/script/basic/NASHORN-67.js.EXPECTED + test/script/basic/NASHORN-678.js + test/script/basic/NASHORN-68.js + test/script/basic/NASHORN-68.js.EXPECTED + test/script/basic/NASHORN-689.js + test/script/basic/NASHORN-689.js.EXPECTED + test/script/basic/NASHORN-69.js + test/script/basic/NASHORN-69.js.EXPECTED + test/script/basic/NASHORN-691.js + test/script/basic/NASHORN-691.js.EXPECTED + test/script/basic/NASHORN-694.js + test/script/basic/NASHORN-694.js.EXPECTED + test/script/basic/NASHORN-697.js + test/script/basic/NASHORN-703.js + test/script/basic/NASHORN-703.js.EXPECTED + test/script/basic/NASHORN-703a.js + test/script/basic/NASHORN-703a.js.EXPECTED + test/script/basic/NASHORN-705.js + test/script/basic/NASHORN-71.js + test/script/basic/NASHORN-71.js.EXPECTED + test/script/basic/NASHORN-710.js + test/script/basic/NASHORN-711.js + test/script/basic/NASHORN-711.js.EXPECTED + test/script/basic/NASHORN-72.js + test/script/basic/NASHORN-72.js.EXPECTED + test/script/basic/NASHORN-722.js + test/script/basic/NASHORN-73.js + test/script/basic/NASHORN-73.js.EXPECTED + test/script/basic/NASHORN-737.js + test/script/basic/NASHORN-737.js.EXPECTED + test/script/basic/NASHORN-74.js + test/script/basic/NASHORN-74.js.EXPECTED + test/script/basic/NASHORN-740.js + test/script/basic/NASHORN-740.js.EXPECTED + test/script/basic/NASHORN-75.js + test/script/basic/NASHORN-75.js.EXPECTED + test/script/basic/NASHORN-758.js + test/script/basic/NASHORN-759.js + test/script/basic/NASHORN-759.js.EXPECTED + test/script/basic/NASHORN-760.js + test/script/basic/NASHORN-768.js + test/script/basic/NASHORN-778.js + test/script/basic/NASHORN-78.js + test/script/basic/NASHORN-79.js + test/script/basic/NASHORN-79.js.EXPECTED + test/script/basic/NASHORN-792.js + test/script/basic/NASHORN-792.js.EXPECTED + test/script/basic/NASHORN-80.js + test/script/basic/NASHORN-80.js.EXPECTED + test/script/basic/NASHORN-81.js + test/script/basic/NASHORN-833.js + test/script/basic/NASHORN-833.js.EXPECTED + test/script/basic/NASHORN-85.js + test/script/basic/NASHORN-85.js.EXPECTED + test/script/basic/NASHORN-86.js + test/script/basic/NASHORN-87.js + test/script/basic/NASHORN-89.js + test/script/basic/NASHORN-90.js + test/script/basic/NASHORN-90.js.EXPECTED + test/script/basic/NASHORN-91.js + test/script/basic/NASHORN-91.js.EXPECTED + test/script/basic/NASHORN-92.js + test/script/basic/NASHORN-92.js.EXPECTED + test/script/basic/NASHORN-93.js + test/script/basic/NASHORN-95.js + test/script/basic/NASHORN-95.js.EXPECTED + test/script/basic/NASHORN-96.js + test/script/basic/NASHORN-96.js.EXPECTED + test/script/basic/NASHORN-97.js + test/script/basic/NASHORN-98.js + test/script/basic/NASHORN-98.js.EXPECTED + test/script/basic/NASHORN-99.js + test/script/basic/addition.js + test/script/basic/addition.js.EXPECTED + test/script/basic/allgettersetters.js + test/script/basic/andor.js + test/script/basic/andor.js.EXPECTED + test/script/basic/anonrecur.js + test/script/basic/anonrecur.js.EXPECTED + test/script/basic/applycall.js + test/script/basic/applycall.js.EXPECTED + test/script/basic/args.js + test/script/basic/args.js.EXPECTED + test/script/basic/arity.js + test/script/basic/arity.js.EXPECTED + test/script/basic/arrayprotoclass.js + test/script/basic/arrayprotoclass.js.EXPECTED + test/script/basic/arrays.js + test/script/basic/arrays.js.EXPECTED + test/script/basic/arrays2.js + test/script/basic/arrays2.js.EXPECTED + test/script/basic/arraysIntKey.js + test/script/basic/arraysIntKey.js.EXPECTED + test/script/basic/arrayset.js + test/script/basic/arrayset.js.EXPECTED + test/script/basic/arrayundefined.js + test/script/basic/arrayundefined.js.EXPECTED + test/script/basic/assign.js + test/script/basic/assign.js.EXPECTED + test/script/basic/bitwise_and.js + test/script/basic/bitwise_and.js.EXPECTED + test/script/basic/booleangetter.js + test/script/basic/booleangetter.js.EXPECTED + test/script/basic/builtin.js + test/script/basic/builtin.js.EXPECTED + test/script/basic/builtin_assign.js + test/script/basic/builtin_assign.js.EXPECTED + test/script/basic/builtinchain.js + test/script/basic/builtinchain.js.EXPECTED + test/script/basic/calllink.js + test/script/basic/calllink.js.EXPECTED + test/script/basic/closure.js + test/script/basic/closure.js.EXPECTED + test/script/basic/commandargs.js + test/script/basic/commandargs.js.EXPECTED + test/script/basic/compile-octane.js + test/script/basic/compile-octane.js.EXPECTED + test/script/basic/condassign.js + test/script/basic/condassign.js.EXPECTED + test/script/basic/construct.js + test/script/basic/construct.js.EXPECTED + test/script/basic/constructorname.js + test/script/basic/constructorname.js.EXPECTED + test/script/basic/date.js + test/script/basic/date.js.EXPECTED + test/script/basic/dateparse.js + test/script/basic/dateparse.js.EXPECTED + test/script/basic/decinc.js + test/script/basic/decinc.js.EXPECTED + test/script/basic/delete.js + test/script/basic/delete.js.EXPECTED + test/script/basic/delete2.js + test/script/basic/delete2.js.EXPECTED + test/script/basic/dotpropname.js + test/script/basic/dotpropname.js.EXPECTED + test/script/basic/doublecache.js + test/script/basic/doublecache.js.EXPECTED + test/script/basic/enumeration.js + test/script/basic/enumeration.js.EXPECTED + test/script/basic/errors.js + test/script/basic/errors.js.EXPECTED + test/script/basic/errorstack.js + test/script/basic/errorstack.js.EXPECTED + test/script/basic/eval.js + test/script/basic/eval.js.EXPECTED + test/script/basic/evalreturn.js + test/script/basic/evalreturn.js.EXPECTED + test/script/basic/exprclosure.js + test/script/basic/exprclosure.js.EXPECTED + test/script/basic/extensibility.js + test/script/basic/extensibility.js.EXPECTED + test/script/basic/fileline.js + test/script/basic/fileline.js.EXPECTED + test/script/basic/finally-catchalls.js + test/script/basic/finally-catchalls.js.EXPECTED + test/script/basic/finallyreturn.js + test/script/basic/finallyreturn.js.EXPECTED + test/script/basic/forin.js + test/script/basic/forin.js.EXPECTED + test/script/basic/forin2.js + test/script/basic/forin2.js.EXPECTED + test/script/basic/funcarray.js + test/script/basic/funcarray.js.EXPECTED + test/script/basic/funcbind.js + test/script/basic/funcbind.js.EXPECTED + test/script/basic/funcconstructor.js + test/script/basic/funcconstructor.js.EXPECTED + test/script/basic/getclassname.js + test/script/basic/getenv.js + test/script/basic/getenv.js.EXPECTED + test/script/basic/getter_callsite.js + test/script/basic/getter_callsite.js.EXPECTED + test/script/basic/gettercalls.js + test/script/basic/gettercalls.js.EXPECTED + test/script/basic/getterfunc.js + test/script/basic/getterfunc.js.EXPECTED + test/script/basic/gettersetter.js + test/script/basic/gettersetter.js.EXPECTED + test/script/basic/globalaccess.js + test/script/basic/globalaccess.js.EXPECTED + test/script/basic/globals.js + test/script/basic/globals.js.EXPECTED + test/script/basic/globalscope.js + test/script/basic/globalscope.js.EXPECTED + test/script/basic/hello.js + test/script/basic/hello.js.EXPECTED + test/script/basic/herestr_operator.js + test/script/basic/herestr_operator.js.EXPECTED + test/script/basic/illegaljavaname.js + test/script/basic/illegaljavaname.js.EXPECTED + test/script/basic/incheck.js + test/script/basic/incheck.js.EXPECTED + test/script/basic/indexedcall.js + test/script/basic/indexedcall.js.EXPECTED + test/script/basic/info.js + test/script/basic/info.js.EXPECTED + test/script/basic/inherited_nonwritable.js + test/script/basic/instanceof.js + test/script/basic/instanceof.js.EXPECTED + test/script/basic/instanceof2.js + test/script/basic/instanceof2.js.EXPECTED + test/script/basic/interfaces.js + test/script/basic/interfaces.js.EXPECTED + test/script/basic/iterator.js + test/script/basic/iterator.js.EXPECTED + test/script/basic/java.js + test/script/basic/java.js.EXPECTED + test/script/basic/javaarray.js + test/script/basic/javaarray.js.EXPECTED + test/script/basic/javaarrayconversion.js + test/script/basic/javaarrayconversion.js.EXPECTED + test/script/basic/javaexceptions.js + test/script/basic/javaexceptions.js.EXPECTED + test/script/basic/javaimporter.js + test/script/basic/javaimporter.js.EXPECTED + test/script/basic/javainnerclasses.js + test/script/basic/javainnerclasses.js.EXPECTED + test/script/basic/javasigcall.js + test/script/basic/javasigcall.js.EXPECTED + test/script/basic/jquery.js + test/script/basic/jquery.js.EXPECTED + test/script/basic/jsadapter.js + test/script/basic/jsadapter.js.EXPECTED + test/script/basic/jsadapterlink.js + test/script/basic/jsadapterlink.js.EXPECTED + test/script/basic/json.js + test/script/basic/json.js.EXPECTED + test/script/basic/list.js + test/script/basic/list.js.EXPECTED + test/script/basic/literal.js + test/script/basic/literal.js.EXPECTED + test/script/basic/load.js + test/script/basic/load.js.EXPECTED + test/script/basic/loadedfile.js + test/script/basic/localundef.js + test/script/basic/localundef.js.EXPECTED + test/script/basic/map.js + test/script/basic/map.js.EXPECTED + test/script/basic/math.js + test/script/basic/math.js.EXPECTED + test/script/basic/minuszero.js + test/script/basic/minuszero.js.EXPECTED + test/script/basic/module.js + test/script/basic/moduleload.js + test/script/basic/moduleload.js.EXPECTED + test/script/basic/nashorn2.js + test/script/basic/nashorn2.js.EXPECTED + test/script/basic/natives.js + test/script/basic/natives.js.EXPECTED + test/script/basic/new.js + test/script/basic/new.js.EXPECTED + test/script/basic/newexpr.js + test/script/basic/newexpr.js.EXPECTED + test/script/basic/newnew.js + test/script/basic/newnew.js.EXPECTED + test/script/basic/nonconstructors.js + test/script/basic/nonconstructors.js.EXPECTED + test/script/basic/nosuchmethod.js + test/script/basic/nosuchmethod.js.EXPECTED + test/script/basic/nosuchproperty.js + test/script/basic/nosuchproperty.js.EXPECTED + test/script/basic/number.js + test/script/basic/number.js.EXPECTED + test/script/basic/numberstring.js + test/script/basic/numberstring.js.EXPECTED + test/script/basic/objectprops.js + test/script/basic/objectprops.js.EXPECTED + test/script/basic/objects.js + test/script/basic/objects.js.EXPECTED + test/script/basic/options.js + test/script/basic/options.js.EXPECTED + test/script/basic/propchange.js + test/script/basic/propchange.js.EXPECTED + test/script/basic/propertycheck.js + test/script/basic/propertycheck.js.EXPECTED + test/script/basic/proto.js.EXPECTED + test/script/basic/prototype.js + test/script/basic/prototype.js.EXPECTED + test/script/basic/pushpull.js + test/script/basic/pushpull.js.EXPECTED + test/script/basic/regex.js + test/script/basic/regex.js.EXPECTED + test/script/basic/regexp_flags.js + test/script/basic/run-octane.js + test/script/basic/runsunspider.js + test/script/basic/runsunspider.js.EXPECTED + test/script/basic/samfunc.js + test/script/basic/samfunc.js.EXPECTED + test/script/basic/scripting.js + test/script/basic/scripting.js.EXPECTED + test/script/basic/sealfreeze.js + test/script/basic/sealfreeze.js.EXPECTED + test/script/basic/setlength.js + test/script/basic/setlength.js.EXPECTED + test/script/basic/stdin.js + test/script/basic/stdin.js.EXPECTED + test/script/basic/strings.js + test/script/basic/strings.js.EXPECTED + test/script/basic/throws.js + test/script/basic/throws.js.EXPECTED + test/script/basic/tosource.js + test/script/basic/tosource.js.EXPECTED + test/script/basic/tostring.js + test/script/basic/tostring.js.EXPECTED + test/script/basic/try.js + test/script/basic/try.js.EXPECTED + test/script/basic/trybreakcont.js + test/script/basic/trybreakcont.js.EXPECTED + test/script/basic/trycatch.js + test/script/basic/trycatch.js.EXPECTED + test/script/basic/trycatchfor.js + test/script/basic/trycatchfor.js.EXPECTED + test/script/basic/tryfinallyreturn.js + test/script/basic/tryfinallyreturn.js.EXPECTED + test/script/basic/tryforbreak.js + test/script/basic/tryforbreak.js.EXPECTED + test/script/basic/typechange.js + test/script/basic/typechange.js.EXPECTED + test/script/basic/typeof.js + test/script/basic/typeof.js.EXPECTED + test/script/basic/typeof2.js + test/script/basic/typeof2.js.EXPECTED + test/script/basic/undefined.js + test/script/basic/undefined.js.EXPECTED + test/script/basic/underscore.js + test/script/basic/underscore.js.EXPECTED + test/script/basic/varargs.js + test/script/basic/varargs.js.EXPECTED + test/script/basic/void.js + test/script/basic/void.js.EXPECTED + test/script/basic/with.js + test/script/basic/with.js.EXPECTED + test/script/basic/withprimitive.js + test/script/basic/withprimitive.js.EXPECTED + test/script/basic/writable_relink.js + test/script/basic/writable_relink.js.EXPECTED + test/script/basic/xmlStrings.js.EXPECTED + test/script/basic/xorassign.js + test/script/basic/xorassign.js.EXPECTED + test/script/basic/yui.js + test/script/basic/yui.js.EXPECTED + test/script/error/NASHORN-154/README + test/script/error/NASHORN-154/function_mult_params_in_strict.js + test/script/error/NASHORN-154/function_mult_params_in_strict.js.EXPECTED + test/script/error/NASHORN-154/improper_return_break_continue.js + test/script/error/NASHORN-154/improper_return_break_continue.js.EXPECTED + test/script/error/NASHORN-154/invalid_lvalue.js + test/script/error/NASHORN-154/invalid_lvalue.js.EXPECTED + test/script/error/NASHORN-154/literal_data_and_accessor.js + test/script/error/NASHORN-154/literal_data_and_accessor.js.EXPECTED + test/script/error/NASHORN-154/literal_mult_getters.js + test/script/error/NASHORN-154/literal_mult_getters.js.EXPECTED + test/script/error/NASHORN-154/literal_mult_prop_in_strict.js + test/script/error/NASHORN-154/literal_mult_prop_in_strict.js.EXPECTED + test/script/error/NASHORN-154/with_in_strict.js + test/script/error/NASHORN-154/with_in_strict.js.EXPECTED + test/script/error/NASHORN-214.js + test/script/error/NASHORN-214.js.EXPECTED + test/script/error/NASHORN-35.js + test/script/error/NASHORN-35.js.EXPECTED + test/script/error/NASHORN-39.js + test/script/error/NASHORN-39.js.EXPECTED + test/script/error/NASHORN-568.js + test/script/error/NASHORN-568.js.EXPECTED + test/script/error/NASHORN-57.js + test/script/error/NASHORN-57.js.EXPECTED + test/script/error/NASHORN-668.js + test/script/error/NASHORN-668.js.EXPECTED + test/script/error/quotemissing.js + test/script/error/quotemissing.js.EXPECTED + test/script/error/strictmode.js + test/script/error/strictmode.js.EXPECTED + test/script/representations/NASHORN-592a.js + test/script/sandbox/NASHORN-525.js + test/script/sandbox/README + test/script/sandbox/classloader.js + test/script/sandbox/classloader.js.EXPECTED + test/script/sandbox/doprivileged.js + test/script/sandbox/doprivileged.js.EXPECTED + test/script/sandbox/exit.js + test/script/sandbox/exit.js.EXPECTED + test/script/sandbox/file.js + test/script/sandbox/file.js.EXPECTED + test/script/sandbox/javaextend.js + test/script/sandbox/javaextend.js.EXPECTED + test/script/sandbox/loadLibrary.js + test/script/sandbox/net.js + test/script/sandbox/net.js.EXPECTED + test/script/sandbox/property.js + test/script/sandbox/property.js.EXPECTED + test/script/sandbox/reflection.js + test/script/sandbox/reflection.js.EXPECTED + test/script/sandbox/runnable.js + test/script/sandbox/runnable.js.EXPECTED + test/script/sandbox/unsafe.js + test/script/sandbox/unsafe.js.EXPECTED + test/script/test262.js + test/script/test262_single.js + test/src/UnnamedPackageTestCallback.java + test/src/jdk/nashorn/api/scripting/MultipleEngineTest.java + test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java + test/src/jdk/nashorn/api/scripting/Window.java + test/src/jdk/nashorn/api/scripting/WindowEventHandler.java + test/src/jdk/nashorn/internal/access/BooleanAccessTest.java + test/src/jdk/nashorn/internal/access/MethodAccessTest.java + test/src/jdk/nashorn/internal/access/NumberAccessTest.java + test/src/jdk/nashorn/internal/access/NumberBoxingTest.java + test/src/jdk/nashorn/internal/access/ObjectAccessTest.java + test/src/jdk/nashorn/internal/access/Person.java + test/src/jdk/nashorn/internal/access/SharedObject.java + test/src/jdk/nashorn/internal/access/StringAccessTest.java + test/src/jdk/nashorn/internal/codegen/CompilerTest.java + test/src/jdk/nashorn/internal/parser/ParserTest.java + test/src/jdk/nashorn/internal/performance/AuroraWrapper.java + test/src/jdk/nashorn/internal/performance/OctaneTest.java + test/src/jdk/nashorn/internal/performance/PerformanceWrapper.java + test/src/jdk/nashorn/internal/performance/SplayTest.java + test/src/jdk/nashorn/internal/runtime/ContextTest.java + test/src/jdk/nashorn/internal/runtime/JSTypeTest.java + test/src/jdk/nashorn/internal/runtime/Nashorn401TestSubject.java + test/src/jdk/nashorn/internal/test/framework/AbstractScriptRunnable.java + test/src/jdk/nashorn/internal/test/framework/JSJUnitReportReporter.java + test/src/jdk/nashorn/internal/test/framework/OrphanTestFinder.java + test/src/jdk/nashorn/internal/test/framework/ParallelTestRunner.java + test/src/jdk/nashorn/internal/test/framework/ScriptEvaluator.java + test/src/jdk/nashorn/internal/test/framework/ScriptRunnable.java + test/src/jdk/nashorn/internal/test/framework/ScriptTest.java + test/src/jdk/nashorn/internal/test/framework/SeparateContextEvaluator.java + test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java + test/src/jdk/nashorn/internal/test/framework/TestConfig.java + test/src/jdk/nashorn/internal/test/framework/TestFinder.java + test/src/jdk/nashorn/internal/test/framework/TestHelper.java + test/src/jdk/nashorn/internal/test/framework/TestReorderInterceptor.java + test/src/jdk/nashorn/internal/test/models/ConstructorWithArgument.java + test/src/jdk/nashorn/internal/test/models/FinalClass.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 Changeset: b4b05457b8b2 Author: jlaskey Date: 2012-12-22 08:49 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b4b05457b8b2 8005440: Improve .hgignore filtering for Nashorn repo Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! .hgignore Changeset: 3a7e1580bc0a Author: jlaskey Date: 2013-01-04 09:58 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/3a7e1580bc0a 8005666: Add webrev to .hgignore Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! .hgignore Changeset: c6e194450af7 Author: jlaskey Date: 2013-01-04 09:58 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c6e194450af7 8005665: JavaDoc should only display public interfaces Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! make/build.xml Changeset: 5a1b0714df0e Author: jlaskey Date: 2013-01-04 09:58 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/5a1b0714df0e 8005663: Update copyright year to 2013 Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! bin/checkintest.sh ! bin/fixorphantests.sh ! bin/fixwhitespace.sh ! bin/jjs ! bin/jjs.bat ! bin/jjssecure ! bin/jjssecure.bat ! bin/nashorn ! bin/nashorn.bat ! bin/rm-non-tracked.sh ! bin/verbose_octane.bat ! bin/verbose_octane.sh ! buildtools/nasgen/build.xml ! buildtools/nasgen/nasgen.iml ! buildtools/nasgen/project.properties ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/Main.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MemberInfo.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MethodGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/NullVisitor.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/PrototypeGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfo.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfoCollector.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInstrumentor.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java ! docs/genshelldoc.js ! make/Makefile ! make/build-benchmark.xml ! make/build-nasgen.xml ! make/build.xml ! make/nbproject/ide-file-targets.xml ! make/nbproject/ide-targets.xml ! make/nbproject/jdk.xml ! make/nbproject/nbjdk.properties ! make/nbproject/nbjdk.xml ! make/nbproject/project.xml ! make/project.properties ! samples/counters.js ! samples/letter.js ! samples/parser.js ! samples/shell.js ! samples/test.js ! samples/uniq.js ! src/META-INF/services/javax.script.ScriptEngineFactory ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/api/scripting/package-info.java ! src/jdk/nashorn/api/scripting/resources/engine.js ! src/jdk/nashorn/internal/codegen/AccessSpecializer.java ! src/jdk/nashorn/internal/codegen/BranchOptimizer.java ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompileUnit.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/ConstantData.java ! src/jdk/nashorn/internal/codegen/Emitter.java ! src/jdk/nashorn/internal/codegen/Frame.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/Namespace.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java ! src/jdk/nashorn/internal/codegen/SharedScopeCall.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/codegen/Transform.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/codegen/objects/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/MapCreator.java ! src/jdk/nashorn/internal/codegen/objects/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/objects/ObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/ObjectMapCreator.java ! src/jdk/nashorn/internal/codegen/types/ArrayType.java ! src/jdk/nashorn/internal/codegen/types/BitwiseType.java ! src/jdk/nashorn/internal/codegen/types/BooleanType.java ! src/jdk/nashorn/internal/codegen/types/BytecodeArrayOps.java ! src/jdk/nashorn/internal/codegen/types/BytecodeBitwiseOps.java ! src/jdk/nashorn/internal/codegen/types/BytecodeNumericOps.java ! src/jdk/nashorn/internal/codegen/types/BytecodeOps.java ! src/jdk/nashorn/internal/codegen/types/IntType.java ! src/jdk/nashorn/internal/codegen/types/LongType.java ! src/jdk/nashorn/internal/codegen/types/NumberType.java ! src/jdk/nashorn/internal/codegen/types/NumericType.java ! src/jdk/nashorn/internal/codegen/types/ObjectType.java ! src/jdk/nashorn/internal/codegen/types/Type.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/BreakableNode.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/FunctionCall.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/LabeledNode.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/PropertyKey.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/annotations/ChildNode.java ! src/jdk/nashorn/internal/ir/annotations/Ignore.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/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/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/objects/DataPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/DateParser.java ! src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeArrayBuffer.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeEvalError.java ! src/jdk/nashorn/internal/objects/NativeFloat32Array.java ! src/jdk/nashorn/internal/objects/NativeFloat64Array.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeInt16Array.java ! src/jdk/nashorn/internal/objects/NativeInt32Array.java ! src/jdk/nashorn/internal/objects/NativeInt8Array.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeMath.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/objects/NativeRangeError.java ! src/jdk/nashorn/internal/objects/NativeReferenceError.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/NativeSyntaxError.java ! src/jdk/nashorn/internal/objects/NativeTypeError.java ! src/jdk/nashorn/internal/objects/NativeURIError.java ! src/jdk/nashorn/internal/objects/NativeUint16Array.java ! src/jdk/nashorn/internal/objects/NativeUint32Array.java ! src/jdk/nashorn/internal/objects/NativeUint8Array.java ! src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/objects/annotations/Attribute.java ! src/jdk/nashorn/internal/objects/annotations/Constructor.java ! src/jdk/nashorn/internal/objects/annotations/Function.java ! src/jdk/nashorn/internal/objects/annotations/Getter.java ! src/jdk/nashorn/internal/objects/annotations/Property.java ! src/jdk/nashorn/internal/objects/annotations/ScriptClass.java ! src/jdk/nashorn/internal/objects/annotations/Setter.java ! src/jdk/nashorn/internal/objects/annotations/SpecializedConstructor.java ! src/jdk/nashorn/internal/objects/annotations/SpecializedFunction.java ! src/jdk/nashorn/internal/objects/annotations/Where.java ! src/jdk/nashorn/internal/objects/package-info.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/JSONParser.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/parser/RegExp.java ! src/jdk/nashorn/internal/parser/RegExpScanner.java ! src/jdk/nashorn/internal/parser/Scanner.java ! src/jdk/nashorn/internal/parser/Token.java ! src/jdk/nashorn/internal/parser/TokenKind.java ! src/jdk/nashorn/internal/parser/TokenLookup.java ! src/jdk/nashorn/internal/parser/TokenStream.java ! src/jdk/nashorn/internal/parser/TokenType.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/BitVector.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk/nashorn/internal/runtime/ConsString.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/Debug.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/DefaultPropertyAccess.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/ErrorManager.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/FunctionScope.java ! src/jdk/nashorn/internal/runtime/GlobalFunctions.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/JSErrorType.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/Logging.java ! src/jdk/nashorn/internal/runtime/NashornLoader.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk/nashorn/internal/runtime/NumberToString.java ! src/jdk/nashorn/internal/runtime/ParserException.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/PropertyAccess.java ! src/jdk/nashorn/internal/runtime/PropertyDescriptor.java ! src/jdk/nashorn/internal/runtime/PropertyHashMap.java ! src/jdk/nashorn/internal/runtime/PropertyListener.java ! src/jdk/nashorn/internal/runtime/PropertyListenerManager.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/QuotedStringTokenizer.java ! src/jdk/nashorn/internal/runtime/RegExpMatch.java ! src/jdk/nashorn/internal/runtime/Scope.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/Source.java ! src/jdk/nashorn/internal/runtime/SpillProperty.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk/nashorn/internal/runtime/URIUtils.java ! src/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java ! src/jdk/nashorn/internal/runtime/Version.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIndex.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/DeletedArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/DeletedRangeArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/EmptyArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/IntArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/InvalidArrayIndexException.java ! src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java ! src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/MapIterator.java ! src/jdk/nashorn/internal/runtime/arrays/NoTypeArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java ! src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/UndefinedArrayFilter.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/InvokeByName.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/Mangler.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/NashornCallSiteDescriptor.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuardedInvocation.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/PrimitiveLookup.java ! src/jdk/nashorn/internal/runtime/options/KeyValueOption.java ! src/jdk/nashorn/internal/runtime/options/Option.java ! src/jdk/nashorn/internal/runtime/options/OptionTemplate.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! src/jdk/nashorn/internal/runtime/options/ValueOption.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties ! src/jdk/nashorn/internal/runtime/resources/Options.properties ! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js ! src/jdk/nashorn/internal/runtime/resources/parser.js ! src/jdk/nashorn/internal/runtime/resources/version.properties-template ! src/jdk/nashorn/internal/scripts/JO$.java ! src/jdk/nashorn/internal/scripts/JS$.java ! src/jdk/nashorn/tools/Shell.java ! src/jdk/nashorn/tools/resources/Shell.properties ! src/jdk/nashorn/tools/resources/shell.js ! src/netscape/javascript/JSObject.java ! src/overview.html ! test/examples/dual-fields-micro.js ! test/examples/innerbench.js ! test/examples/typechain.js ! test/lib/benchmark.js ! test/opt/add.js ! test/opt/add_constant.js ! test/opt/add_reuse_callsite.js ! test/opt/add_revert2.js ! test/opt/cascade_specialize.js ! test/script/assert.js ! test/script/basic/NASHORN-100.js ! test/script/basic/NASHORN-101.js ! test/script/basic/NASHORN-102.js ! test/script/basic/NASHORN-103.js ! test/script/basic/NASHORN-104.js ! test/script/basic/NASHORN-105.js ! test/script/basic/NASHORN-106.js ! test/script/basic/NASHORN-107.js ! test/script/basic/NASHORN-108.js ! test/script/basic/NASHORN-109.js ! test/script/basic/NASHORN-11.js ! test/script/basic/NASHORN-111.js ! test/script/basic/NASHORN-113.js ! test/script/basic/NASHORN-114.js ! test/script/basic/NASHORN-115.js ! test/script/basic/NASHORN-117.js ! test/script/basic/NASHORN-118.js ! test/script/basic/NASHORN-119.js ! test/script/basic/NASHORN-12.js ! test/script/basic/NASHORN-120.js ! test/script/basic/NASHORN-122.js ! test/script/basic/NASHORN-126.js ! test/script/basic/NASHORN-127.js ! test/script/basic/NASHORN-130.js ! test/script/basic/NASHORN-132.js ! test/script/basic/NASHORN-133.js ! test/script/basic/NASHORN-135.js ! test/script/basic/NASHORN-136.js ! test/script/basic/NASHORN-14.js ! test/script/basic/NASHORN-148.js ! test/script/basic/NASHORN-15.js ! test/script/basic/NASHORN-153.js ! test/script/basic/NASHORN-156.js ! test/script/basic/NASHORN-157.js ! test/script/basic/NASHORN-163.js ! test/script/basic/NASHORN-164.js ! test/script/basic/NASHORN-165.js ! test/script/basic/NASHORN-166.js ! test/script/basic/NASHORN-168.js ! test/script/basic/NASHORN-169.js ! test/script/basic/NASHORN-172.js ! test/script/basic/NASHORN-173.js ! test/script/basic/NASHORN-174.js ! test/script/basic/NASHORN-175.js ! test/script/basic/NASHORN-176.js ! test/script/basic/NASHORN-177.js ! test/script/basic/NASHORN-178.js ! test/script/basic/NASHORN-179.js ! test/script/basic/NASHORN-18.js ! test/script/basic/NASHORN-181.js ! test/script/basic/NASHORN-182.js ! test/script/basic/NASHORN-183.js ! test/script/basic/NASHORN-184.js ! test/script/basic/NASHORN-185.js ! test/script/basic/NASHORN-187.js ! test/script/basic/NASHORN-188.js ! test/script/basic/NASHORN-19.js ! test/script/basic/NASHORN-190.js ! test/script/basic/NASHORN-192.js ! test/script/basic/NASHORN-194.js ! test/script/basic/NASHORN-196.js ! test/script/basic/NASHORN-198.js ! test/script/basic/NASHORN-20.js ! test/script/basic/NASHORN-201.js ! test/script/basic/NASHORN-202.js ! test/script/basic/NASHORN-203.js ! test/script/basic/NASHORN-204.js ! test/script/basic/NASHORN-205.js ! test/script/basic/NASHORN-206.js ! test/script/basic/NASHORN-207.js ! test/script/basic/NASHORN-207_2.js ! test/script/basic/NASHORN-208.js ! test/script/basic/NASHORN-209.js ! test/script/basic/NASHORN-21.js ! test/script/basic/NASHORN-211.js ! test/script/basic/NASHORN-212.js ! test/script/basic/NASHORN-213.js ! test/script/basic/NASHORN-215.js ! test/script/basic/NASHORN-216.js ! test/script/basic/NASHORN-217.js ! test/script/basic/NASHORN-219.js ! test/script/basic/NASHORN-22.js ! test/script/basic/NASHORN-221.js ! test/script/basic/NASHORN-222.js ! test/script/basic/NASHORN-223.js ! test/script/basic/NASHORN-225.js ! test/script/basic/NASHORN-226.js ! test/script/basic/NASHORN-227.js ! test/script/basic/NASHORN-228.js ! test/script/basic/NASHORN-229.js ! test/script/basic/NASHORN-229_subtest.js ! test/script/basic/NASHORN-23.js ! test/script/basic/NASHORN-232.js ! test/script/basic/NASHORN-234.js ! test/script/basic/NASHORN-235.js ! test/script/basic/NASHORN-236.js ! test/script/basic/NASHORN-237.js ! test/script/basic/NASHORN-239.js ! test/script/basic/NASHORN-24.js ! test/script/basic/NASHORN-241.js ! test/script/basic/NASHORN-242.js ! test/script/basic/NASHORN-245.js ! test/script/basic/NASHORN-247.js ! test/script/basic/NASHORN-25.js ! test/script/basic/NASHORN-251.js ! test/script/basic/NASHORN-252.js ! test/script/basic/NASHORN-253.js ! test/script/basic/NASHORN-256.js ! test/script/basic/NASHORN-258.js ! test/script/basic/NASHORN-26.js ! test/script/basic/NASHORN-260.js ! test/script/basic/NASHORN-261.js ! test/script/basic/NASHORN-262.js ! test/script/basic/NASHORN-263.js ! test/script/basic/NASHORN-264.js ! test/script/basic/NASHORN-265.js ! test/script/basic/NASHORN-266.js ! test/script/basic/NASHORN-269.js ! test/script/basic/NASHORN-27.js ! test/script/basic/NASHORN-270.js ! test/script/basic/NASHORN-271.js ! test/script/basic/NASHORN-275.js ! test/script/basic/NASHORN-276.js ! test/script/basic/NASHORN-277.js ! test/script/basic/NASHORN-278.js ! test/script/basic/NASHORN-28.js ! test/script/basic/NASHORN-281.js ! test/script/basic/NASHORN-284.js ! test/script/basic/NASHORN-285.js ! test/script/basic/NASHORN-288.js ! test/script/basic/NASHORN-29.js ! test/script/basic/NASHORN-293.js ! test/script/basic/NASHORN-294.js ! test/script/basic/NASHORN-296.js ! test/script/basic/NASHORN-297.js ! test/script/basic/NASHORN-30.js ! test/script/basic/NASHORN-300.js ! test/script/basic/NASHORN-301.js ! test/script/basic/NASHORN-304.js ! test/script/basic/NASHORN-310.js ! test/script/basic/NASHORN-318.js ! test/script/basic/NASHORN-32.js ! test/script/basic/NASHORN-321.js ! test/script/basic/NASHORN-323.js ! test/script/basic/NASHORN-324.js ! test/script/basic/NASHORN-33.js ! test/script/basic/NASHORN-331.js ! test/script/basic/NASHORN-337.js ! test/script/basic/NASHORN-34.js ! test/script/basic/NASHORN-340.js ! test/script/basic/NASHORN-349.js ! test/script/basic/NASHORN-354.js ! test/script/basic/NASHORN-355.js ! test/script/basic/NASHORN-36.js ! test/script/basic/NASHORN-365.js ! test/script/basic/NASHORN-366.js ! test/script/basic/NASHORN-368.js ! test/script/basic/NASHORN-37.js ! test/script/basic/NASHORN-375.js ! test/script/basic/NASHORN-376.js ! test/script/basic/NASHORN-377.js ! test/script/basic/NASHORN-378.js ! test/script/basic/NASHORN-38.js ! test/script/basic/NASHORN-380.js ! test/script/basic/NASHORN-381.js ! test/script/basic/NASHORN-382.js ! test/script/basic/NASHORN-383.js ! test/script/basic/NASHORN-384.js ! test/script/basic/NASHORN-385.js ! test/script/basic/NASHORN-389.js ! test/script/basic/NASHORN-393.js ! test/script/basic/NASHORN-394.js ! test/script/basic/NASHORN-396.js ! test/script/basic/NASHORN-397.js ! test/script/basic/NASHORN-398.js ! test/script/basic/NASHORN-40.js ! test/script/basic/NASHORN-400.js ! test/script/basic/NASHORN-401.js ! test/script/basic/NASHORN-402.js ! test/script/basic/NASHORN-404.js ! test/script/basic/NASHORN-405.js ! test/script/basic/NASHORN-406.js ! test/script/basic/NASHORN-408.js ! test/script/basic/NASHORN-415.js ! test/script/basic/NASHORN-416.js ! test/script/basic/NASHORN-417.js ! test/script/basic/NASHORN-418.js ! test/script/basic/NASHORN-420.js ! test/script/basic/NASHORN-421.js ! test/script/basic/NASHORN-423.js ! test/script/basic/NASHORN-423a.js ! test/script/basic/NASHORN-424.js ! test/script/basic/NASHORN-425.js ! test/script/basic/NASHORN-426.js ! test/script/basic/NASHORN-427.js ! test/script/basic/NASHORN-428.js ! test/script/basic/NASHORN-429.js ! test/script/basic/NASHORN-432.js ! test/script/basic/NASHORN-433.js ! test/script/basic/NASHORN-434.js ! test/script/basic/NASHORN-435.js ! test/script/basic/NASHORN-437.js ! test/script/basic/NASHORN-44.js ! test/script/basic/NASHORN-441.js ! test/script/basic/NASHORN-442.js ! test/script/basic/NASHORN-443.js ! test/script/basic/NASHORN-444.js ! test/script/basic/NASHORN-445.js ! test/script/basic/NASHORN-446.js ! test/script/basic/NASHORN-447.js ! test/script/basic/NASHORN-448.js ! test/script/basic/NASHORN-449.js ! test/script/basic/NASHORN-45.js ! test/script/basic/NASHORN-450.js ! test/script/basic/NASHORN-452.js ! test/script/basic/NASHORN-459.js ! test/script/basic/NASHORN-46.js ! test/script/basic/NASHORN-462.js ! test/script/basic/NASHORN-463.js ! test/script/basic/NASHORN-468.js ! test/script/basic/NASHORN-47.js ! test/script/basic/NASHORN-473.js ! test/script/basic/NASHORN-474.js ! test/script/basic/NASHORN-478.js ! test/script/basic/NASHORN-48.js ! test/script/basic/NASHORN-481.js ! test/script/basic/NASHORN-482.js ! test/script/basic/NASHORN-484.js ! test/script/basic/NASHORN-486.js ! test/script/basic/NASHORN-487.js ! test/script/basic/NASHORN-488.js ! test/script/basic/NASHORN-49.js ! test/script/basic/NASHORN-490.js ! test/script/basic/NASHORN-494.js ! test/script/basic/NASHORN-497.js ! test/script/basic/NASHORN-498.js ! test/script/basic/NASHORN-499.js ! test/script/basic/NASHORN-50.js ! test/script/basic/NASHORN-500.js ! test/script/basic/NASHORN-503.js ! test/script/basic/NASHORN-51.js ! test/script/basic/NASHORN-511.js ! test/script/basic/NASHORN-515.js ! test/script/basic/NASHORN-516.js ! test/script/basic/NASHORN-52.js ! test/script/basic/NASHORN-534.js ! test/script/basic/NASHORN-535.js ! test/script/basic/NASHORN-544.js ! test/script/basic/NASHORN-55.js ! test/script/basic/NASHORN-554.js ! test/script/basic/NASHORN-556.js ! test/script/basic/NASHORN-56.js ! test/script/basic/NASHORN-562.js ! test/script/basic/NASHORN-565.js ! test/script/basic/NASHORN-575.js ! test/script/basic/NASHORN-58.js ! test/script/basic/NASHORN-59.js ! test/script/basic/NASHORN-592.js ! test/script/basic/NASHORN-597.js ! test/script/basic/NASHORN-60.js ! test/script/basic/NASHORN-609.js ! test/script/basic/NASHORN-61.js ! test/script/basic/NASHORN-62.js ! test/script/basic/NASHORN-620.js ! test/script/basic/NASHORN-623.js ! test/script/basic/NASHORN-627.js ! test/script/basic/NASHORN-63.js ! test/script/basic/NASHORN-637.js ! test/script/basic/NASHORN-638.js ! test/script/basic/NASHORN-639.js ! test/script/basic/NASHORN-64.js ! test/script/basic/NASHORN-642.js ! test/script/basic/NASHORN-646.js ! test/script/basic/NASHORN-653.js ! test/script/basic/NASHORN-658.js ! test/script/basic/NASHORN-659.js ! test/script/basic/NASHORN-66.js ! test/script/basic/NASHORN-664.js ! test/script/basic/NASHORN-665.js ! test/script/basic/NASHORN-67.js ! test/script/basic/NASHORN-678.js ! test/script/basic/NASHORN-68.js ! test/script/basic/NASHORN-689.js ! test/script/basic/NASHORN-69.js ! test/script/basic/NASHORN-691.js ! test/script/basic/NASHORN-694.js ! test/script/basic/NASHORN-697.js ! test/script/basic/NASHORN-703.js ! test/script/basic/NASHORN-703a.js ! test/script/basic/NASHORN-705.js ! test/script/basic/NASHORN-71.js ! test/script/basic/NASHORN-710.js ! test/script/basic/NASHORN-711.js ! test/script/basic/NASHORN-72.js ! test/script/basic/NASHORN-722.js ! test/script/basic/NASHORN-73.js ! test/script/basic/NASHORN-737.js ! test/script/basic/NASHORN-74.js ! test/script/basic/NASHORN-740.js ! test/script/basic/NASHORN-75.js ! test/script/basic/NASHORN-758.js ! test/script/basic/NASHORN-759.js ! test/script/basic/NASHORN-760.js ! test/script/basic/NASHORN-768.js ! test/script/basic/NASHORN-778.js ! test/script/basic/NASHORN-78.js ! test/script/basic/NASHORN-79.js ! test/script/basic/NASHORN-792.js ! test/script/basic/NASHORN-80.js ! test/script/basic/NASHORN-81.js ! test/script/basic/NASHORN-833.js ! test/script/basic/NASHORN-85.js ! test/script/basic/NASHORN-86.js ! test/script/basic/NASHORN-87.js ! test/script/basic/NASHORN-89.js ! test/script/basic/NASHORN-90.js ! test/script/basic/NASHORN-91.js ! test/script/basic/NASHORN-92.js ! test/script/basic/NASHORN-93.js ! test/script/basic/NASHORN-95.js ! test/script/basic/NASHORN-96.js ! test/script/basic/NASHORN-97.js ! test/script/basic/NASHORN-98.js ! test/script/basic/NASHORN-99.js ! test/script/basic/addition.js ! test/script/basic/allgettersetters.js ! test/script/basic/andor.js ! test/script/basic/anonrecur.js ! test/script/basic/applycall.js ! test/script/basic/args.js ! test/script/basic/arity.js ! test/script/basic/arrayprotoclass.js ! test/script/basic/arrays.js ! test/script/basic/arrays2.js ! test/script/basic/arraysIntKey.js ! test/script/basic/arrayset.js ! test/script/basic/arrayundefined.js ! test/script/basic/assign.js ! test/script/basic/bitwise_and.js ! test/script/basic/booleangetter.js ! test/script/basic/builtin.js ! test/script/basic/builtin_assign.js ! test/script/basic/builtinchain.js ! test/script/basic/calllink.js ! test/script/basic/closure.js ! test/script/basic/commandargs.js ! test/script/basic/compile-octane.js ! test/script/basic/condassign.js ! test/script/basic/construct.js ! test/script/basic/constructorname.js ! test/script/basic/date.js ! test/script/basic/dateparse.js ! test/script/basic/decinc.js ! test/script/basic/delete.js ! test/script/basic/delete2.js ! test/script/basic/dotpropname.js ! test/script/basic/doublecache.js ! test/script/basic/enumeration.js ! test/script/basic/errors.js ! test/script/basic/errorstack.js ! test/script/basic/eval.js ! test/script/basic/evalreturn.js ! test/script/basic/exprclosure.js ! test/script/basic/extensibility.js ! test/script/basic/fileline.js ! test/script/basic/finally-catchalls.js ! test/script/basic/finallyreturn.js ! test/script/basic/forin.js ! test/script/basic/forin2.js ! test/script/basic/funcarray.js ! test/script/basic/funcbind.js ! test/script/basic/funcconstructor.js ! test/script/basic/getclassname.js ! test/script/basic/getenv.js ! test/script/basic/getter_callsite.js ! test/script/basic/gettercalls.js ! test/script/basic/getterfunc.js ! test/script/basic/gettersetter.js ! test/script/basic/globalaccess.js ! test/script/basic/globals.js ! test/script/basic/globalscope.js ! test/script/basic/hello.js ! test/script/basic/herestr_operator.js ! test/script/basic/illegaljavaname.js ! test/script/basic/incheck.js ! test/script/basic/indexedcall.js ! test/script/basic/info.js ! test/script/basic/inherited_nonwritable.js ! test/script/basic/instanceof.js ! test/script/basic/instanceof2.js ! test/script/basic/interfaces.js ! test/script/basic/iterator.js ! test/script/basic/java.js ! test/script/basic/javaarray.js ! test/script/basic/javaarrayconversion.js ! test/script/basic/javaexceptions.js ! test/script/basic/javaimporter.js ! test/script/basic/javainnerclasses.js ! test/script/basic/javasigcall.js ! test/script/basic/jquery.js ! test/script/basic/jsadapter.js ! test/script/basic/jsadapterlink.js ! test/script/basic/json.js ! test/script/basic/list.js ! test/script/basic/literal.js ! test/script/basic/load.js ! test/script/basic/loadedfile.js ! test/script/basic/localundef.js ! test/script/basic/map.js ! test/script/basic/math.js ! test/script/basic/minuszero.js ! test/script/basic/module.js ! test/script/basic/moduleload.js ! test/script/basic/nashorn2.js ! test/script/basic/natives.js ! test/script/basic/new.js ! test/script/basic/newexpr.js ! test/script/basic/newnew.js ! test/script/basic/nonconstructors.js ! test/script/basic/nosuchmethod.js ! test/script/basic/nosuchproperty.js ! test/script/basic/number.js ! test/script/basic/numberstring.js ! test/script/basic/objectprops.js ! test/script/basic/objects.js ! test/script/basic/options.js ! test/script/basic/propchange.js ! test/script/basic/propertycheck.js ! test/script/basic/prototype.js ! test/script/basic/pushpull.js ! test/script/basic/regex.js ! test/script/basic/regexp_flags.js ! test/script/basic/run-octane.js ! test/script/basic/runsunspider.js ! test/script/basic/samfunc.js ! test/script/basic/scripting.js ! test/script/basic/scripting.js.EXPECTED ! test/script/basic/sealfreeze.js ! test/script/basic/setlength.js ! test/script/basic/stdin.js ! test/script/basic/strings.js ! test/script/basic/throws.js ! test/script/basic/tosource.js ! test/script/basic/tostring.js ! test/script/basic/try.js ! test/script/basic/trybreakcont.js ! test/script/basic/trycatch.js ! test/script/basic/trycatchfor.js ! test/script/basic/tryfinallyreturn.js ! test/script/basic/tryforbreak.js ! test/script/basic/typechange.js ! test/script/basic/typeof.js ! test/script/basic/typeof2.js ! test/script/basic/undefined.js ! test/script/basic/underscore.js ! test/script/basic/varargs.js ! test/script/basic/void.js ! test/script/basic/with.js ! test/script/basic/withprimitive.js ! test/script/basic/writable_relink.js ! test/script/basic/xorassign.js ! test/script/basic/yui.js ! test/script/error/NASHORN-154/function_mult_params_in_strict.js ! test/script/error/NASHORN-154/improper_return_break_continue.js ! test/script/error/NASHORN-154/invalid_lvalue.js ! test/script/error/NASHORN-154/literal_data_and_accessor.js ! test/script/error/NASHORN-154/literal_mult_getters.js ! test/script/error/NASHORN-154/literal_mult_prop_in_strict.js ! test/script/error/NASHORN-154/with_in_strict.js ! test/script/error/NASHORN-214.js ! test/script/error/NASHORN-35.js ! test/script/error/NASHORN-39.js ! test/script/error/NASHORN-568.js ! test/script/error/NASHORN-57.js ! test/script/error/NASHORN-668.js ! test/script/error/quotemissing.js ! test/script/error/strictmode.js ! test/script/representations/NASHORN-592a.js ! test/script/sandbox/NASHORN-525.js ! test/script/sandbox/classloader.js ! test/script/sandbox/doprivileged.js ! test/script/sandbox/exit.js ! test/script/sandbox/file.js ! test/script/sandbox/javaextend.js ! test/script/sandbox/loadLibrary.js ! test/script/sandbox/net.js ! test/script/sandbox/property.js ! test/script/sandbox/reflection.js ! test/script/sandbox/runnable.js ! test/script/sandbox/unsafe.js ! test/script/test262.js ! test/script/test262_single.js ! test/src/UnnamedPackageTestCallback.java ! test/src/jdk/nashorn/api/scripting/MultipleEngineTest.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java ! test/src/jdk/nashorn/api/scripting/Window.java ! test/src/jdk/nashorn/api/scripting/WindowEventHandler.java ! test/src/jdk/nashorn/internal/access/BooleanAccessTest.java ! test/src/jdk/nashorn/internal/access/MethodAccessTest.java ! test/src/jdk/nashorn/internal/access/NumberAccessTest.java ! test/src/jdk/nashorn/internal/access/NumberBoxingTest.java ! test/src/jdk/nashorn/internal/access/ObjectAccessTest.java ! test/src/jdk/nashorn/internal/access/Person.java ! test/src/jdk/nashorn/internal/access/SharedObject.java ! test/src/jdk/nashorn/internal/access/StringAccessTest.java ! test/src/jdk/nashorn/internal/codegen/CompilerTest.java ! test/src/jdk/nashorn/internal/parser/ParserTest.java ! test/src/jdk/nashorn/internal/performance/AuroraWrapper.java ! test/src/jdk/nashorn/internal/performance/OctaneTest.java ! test/src/jdk/nashorn/internal/performance/PerformanceWrapper.java ! test/src/jdk/nashorn/internal/performance/SplayTest.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java ! test/src/jdk/nashorn/internal/runtime/JSTypeTest.java ! test/src/jdk/nashorn/internal/runtime/Nashorn401TestSubject.java ! test/src/jdk/nashorn/internal/test/framework/AbstractScriptRunnable.java ! test/src/jdk/nashorn/internal/test/framework/JSJUnitReportReporter.java ! test/src/jdk/nashorn/internal/test/framework/OrphanTestFinder.java ! test/src/jdk/nashorn/internal/test/framework/ParallelTestRunner.java ! test/src/jdk/nashorn/internal/test/framework/ScriptEvaluator.java ! test/src/jdk/nashorn/internal/test/framework/ScriptRunnable.java ! test/src/jdk/nashorn/internal/test/framework/ScriptTest.java ! test/src/jdk/nashorn/internal/test/framework/SeparateContextEvaluator.java ! test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java ! test/src/jdk/nashorn/internal/test/framework/TestConfig.java ! test/src/jdk/nashorn/internal/test/framework/TestFinder.java ! test/src/jdk/nashorn/internal/test/framework/TestHelper.java ! test/src/jdk/nashorn/internal/test/framework/TestReorderInterceptor.java ! test/src/jdk/nashorn/internal/test/models/ConstructorWithArgument.java ! test/src/jdk/nashorn/internal/test/models/FinalClass.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 Changeset: 1e3f411f47bf Author: lagergren Date: 2013-01-07 19:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1e3f411f47bf 8005789: Forgot to document -Dnashorn.unstable.relink.threshold Summary: Added documentation to DEVELOPER_README, fixed code convention warnings Reviewed-by: attila ! docs/DEVELOPER_README ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/options/Options.java Changeset: 41c7093477ae Author: jlaskey Date: 2013-01-07 14:41 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/41c7093477ae 8005703: Offsets miscalculated for blocks Reviewed-by: lagergren Contributed-by: petr.hejl at oracle.com ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Parser.java Changeset: d14da0d0c577 Author: sundar Date: 2013-01-08 08:51 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d14da0d0c577 8005782: get rid of javadoc errors, warnings in nashorn build Reviewed-by: lagergren ! make/build.xml ! make/project.properties ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java Changeset: 0e7da548ef6a Author: lagergren Date: 2013-01-08 09:59 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/0e7da548ef6a 8005788: Loggers and their corresponding system properties not working correctly Summary: 1-1 mapping now maintained. Used Context err instead of System.err in several places (after bootstrapping Context). Problematic closing of err stream replaced by @SuppressWarnings("resource") Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/ErrorManager.java ! src/jdk/nashorn/internal/runtime/Logging.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/internal/runtime/linker/MethodHandleFactory.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! src/jdk/nashorn/tools/Shell.java Changeset: 5f2db2d8a7fa Author: sundar Date: 2013-01-08 15:02 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/5f2db2d8a7fa 8005835: NASHORN-668 output fails to compare with the corresponding .EXPECTED file Reviewed-by: lagergren, hannesw ! test/script/error/NASHORN-668.js.EXPECTED Changeset: d8e4d66f1a06 Author: lagergren Date: 2013-01-08 10:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d8e4d66f1a06 8005843: refSymbols lookup of unbound variable could cause NullPointerException in Lower Reviewed-by: hannesw, attila ! src/jdk/nashorn/internal/codegen/Lower.java + test/script/basic/NASHORN-837.js Changeset: c5a321205f49 Author: attila Date: 2013-01-08 13:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c5a321205f49 8005846: Remove Mangler in favor of Dynalink's NameCodec Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/Compiler.java Changeset: 4620ac94e7dc Author: attila Date: 2013-01-08 14:14 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/4620ac94e7dc 8005801: Refactor findSetMethod Summary: findSetMethod() was a very large single method, very unreadable and unmaintainable. It was broken into easy-to-understand pieces. The refactoring required introduction of a comand-object like entity, SetMethodCreator, to contain the nontrivial transient state of the algorithm that made the original big method so resistant to refactoring in the first place. Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/runtime/ScriptObject.java + src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/SpillProperty.java - src/jdk/nashorn/internal/runtime/linker/Mangler.java Changeset: 69a4f0363d0f Author: lagergren Date: 2013-01-08 15:20 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/69a4f0363d0f 8005842: Loops in ASTWriter. Corrected @Reference and @Ignore node annotation for IR nodes Reviewed-by: hannesw, sundar ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/LabelNode.java ! src/jdk/nashorn/internal/ir/LabeledNode.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/ir/ReferenceNode.java ! src/jdk/nashorn/internal/ir/ReturnNode.java ! src/jdk/nashorn/internal/ir/SplitNode.java ! src/jdk/nashorn/internal/ir/SwitchNode.java ! src/jdk/nashorn/internal/ir/ThrowNode.java ! src/jdk/nashorn/internal/ir/TryNode.java ! src/jdk/nashorn/internal/ir/debug/ASTWriter.java Changeset: 548587cfb065 Author: sundar Date: 2013-01-08 21:16 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/548587cfb065 8005848: assigning to global toString variable affects Object.prototype.toString Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK_8005848.js Changeset: 812b9963b1c7 Author: attila Date: 2013-01-09 15:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/812b9963b1c7 8005777: Bug in the FacetIntrospector of Dynalink - non-public class should search super Reviewed-by: lagergren, sundar ! make/project.properties Changeset: 4cd65798ec70 Author: sundar Date: 2013-01-09 22:32 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/4cd65798ec70 8005940: provide ant targets to get and update external test scripts Reviewed-by: jlaskey, lagergren ! bin/verbose_octane.bat ! bin/verbose_octane.sh ! make/Makefile ! make/build-benchmark.xml ! make/build.xml ! make/project.properties ! test/script/basic/run-octane.js ! test/script/basic/runsunspider.js ! test/src/jdk/nashorn/internal/codegen/CompilerTest.java ! test/src/jdk/nashorn/internal/parser/ParserTest.java Changeset: 9f59ba5090f2 Author: lagergren Date: 2013-01-10 10:28 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/9f59ba5090f2 8005971: runsunspider.js should check results of benchmarks Reviewed-by: attila, hannesw ! test/script/basic/runsunspider.js Changeset: a7f177d6639c Author: sundar Date: 2013-01-10 19:03 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a7f177d6639c 8005987: ant octane tries to run non-benchmark scripts Reviewed-by: lagergren, attila, jlaskey ! make/build-benchmark.xml ! make/project.properties Changeset: 0362d36d3dd6 Author: sundar Date: 2013-01-10 19:55 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/0362d36d3dd6 8005982: NASHORN-71.js failing in nightlys Reviewed-by: attila, lagergren, jlaskey ! test/script/basic/NASHORN-71.js - test/script/basic/NASHORN-71.js.EXPECTED Changeset: 2a5c2258827b Author: attila Date: 2013-01-10 15:28 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/2a5c2258827b 8005983: JavaAdapterFactory generated proxy classes should take extra constructor arguments at the end Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! test/script/sandbox/javaextend.js ! test/script/sandbox/javaextend.js.EXPECTED Changeset: 2a4769fcd13f Author: lagergren Date: 2013-01-11 10:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/2a4769fcd13f 8005976: Break out AccessSpecializer into one pass before CodeGenerator instead of iterative applications from CodeGenerator Summary: Now scope and slot information is guaranteed to be fixed AND NOT CHANGE before CodeGeneration. We want to keep it that way to build future type specializations and bring all type work out of CodeGenerator. Reviewed-by: attila, hannesw + bin/dump_octane_code.sh ! bin/verbose_octane.sh ! docs/DEVELOPER_README ! src/jdk/nashorn/internal/codegen/AccessSpecializer.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/Splitter.java - src/jdk/nashorn/internal/codegen/Transform.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java Changeset: f67bf56495ca Author: sundar Date: 2013-01-11 18:26 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f67bf56495ca 8006082: Provide option to run octane benchmarks in separate processes Reviewed-by: lagergren, jlaskey ! make/build-benchmark.xml ! make/project.properties Changeset: 8a5922638ff0 Author: sundar Date: 2013-01-11 20:34 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/8a5922638ff0 8006093: Add a makefile target to run all tests (test, test262, perf tests) Reviewed-by: attila, hannesw ! make/Makefile ! make/build.xml Changeset: eda69555239a Author: attila Date: 2013-01-14 16:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/eda69555239a 8006168: ability to generate multi-type Java adapters Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties ! test/script/sandbox/javaextend.js ! test/script/sandbox/javaextend.js.EXPECTED + 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/FloorWax.java + test/src/jdk/nashorn/internal/test/models/Toothpaste.java Changeset: 3c6db5ea0ecc Author: sundar Date: 2013-01-14 21:30 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/3c6db5ea0ecc 8006181: nashorn script engine does not run jrunscript's initialization script Reviewed-by: lagergren, jlaskey Contributed-by: rieberandreas at gmail.com + src/jdk/nashorn/api/scripting/Formatter.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/resources/engine.js + src/jdk/nashorn/api/scripting/resources/init.js Changeset: 1d0307c2bb4c Author: attila Date: 2013-01-15 13:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1d0307c2bb4c 8006293: Reduce ScriptObject.findCallMethodMethod Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/MethodHandleFactory.java ! src/jdk/nashorn/internal/runtime/linker/MethodHandleFunctionality.java Changeset: ee73d7378e3e Author: attila Date: 2013-01-15 17:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ee73d7378e3e 8005958: invoking a function through INVOKESTATIC with more arguments than it declares resulted in malformed bytecode being generated Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8005958.js Changeset: 9088170e68df Author: attila Date: 2013-01-15 18:08 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/9088170e68df 8006337: Discarded arguments for INVOKESTATIC must still be evaluated for side effects Reviewed-by: hannesw, jlaskey, sundar ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8006337.js + test/script/basic/JDK-8006337.js.EXPECTED Changeset: 617313881c55 Author: jlaskey Date: 2013-01-16 07:06 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/617313881c55 8006304: Remove pre-population of maps for constructor produced maps Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! .hgignore ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java + test/script/basic/JDK-8006304.js + test/script/basic/JDK-8006304.js.EXPECTED Changeset: 80447df16322 Author: sundar Date: 2013-01-16 17:58 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/80447df16322 8006412: Improve toString method of ScriptObjectMirror class Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: cd5b684ce7b2 Author: sundar Date: 2013-01-16 21:26 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/cd5b684ce7b2 8006424: Passing null or undefined to adapter class constructors results in NPE or ClassCastException Reviewed-by: attila, hannesw, jlaskey ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java + test/script/basic/JDK-8006424.js Changeset: 4acebfe9e504 Author: jlaskey Date: 2013-01-17 10:33 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/4acebfe9e504 8006517: PropertyHashMap.Element.equals() compares to Property Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/PropertyHashMap.java Changeset: f8136c060914 Author: sundar Date: 2013-01-18 08:45 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f8136c060914 8006527: nashorn jsr223 engine does not work in sandbox Reviewed-by: jlaskey, attila, lagergren + bin/nashornsecure + bin/nashornsecure.bat ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/resources/init.js ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java + test/script/sandbox/engine.js + test/script/sandbox/engine.js.EXPECTED + test/script/sandbox/jsadapter.js Changeset: 4361e8cd6a02 Author: sundar Date: 2013-01-18 17:55 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/4361e8cd6a02 8006562: findOwnMH in nashorn "objects" package should be cleaned up Reviewed-by: jlaskey, lagergren ! make/project.properties ! 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 Changeset: c887baec012a Author: sundar Date: 2013-01-19 09:14 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c887baec012a 8006584: improve variable handling in NashornScriptEngine Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: a8966074d4e9 Author: sundar Date: 2013-01-19 22:35 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a8966074d4e9 8006557: JDK8/Lambda build clashes on Map.replace() Reviewed-by: jlaskey ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java Changeset: 0cee498b330d Author: attila Date: 2013-01-21 11:03 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/0cee498b330d 8006525: Give StaticClass objects their own linker Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java + src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java Changeset: 8b3cc4ad1810 Author: sundar Date: 2013-01-21 21:17 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/8b3cc4ad1810 8006635: Reduce access levels as much as possible Reviewed-by: jlaskey, lagergren, attila ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArray.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/DebugLogger.java ! src/jdk/nashorn/internal/runtime/ECMAException.java + src/jdk/nashorn/internal/runtime/OptionsObject.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/tools/Shell.java ! test/src/jdk/nashorn/internal/access/BooleanAccessTest.java ! test/src/jdk/nashorn/internal/codegen/CompilerTest.java ! test/src/jdk/nashorn/internal/parser/ParserTest.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java ! test/src/jdk/nashorn/internal/runtime/JSTypeTest.java ! test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java Changeset: 935dcec38e9a Author: hannesw Date: 2013-01-22 14:14 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/935dcec38e9a 8006570: This-value for non-strict functions should be converted to object Reviewed-by: jlaskey, lagergren, attila ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuardedInvocation.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java + test/script/basic/JDK-8006570.js + test/script/basic/JDK-8006570.js.EXPECTED Changeset: e43d1013d871 Author: attila Date: 2013-01-22 14:36 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e43d1013d871 8006677: Remove unused FunctionNode flags Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/parser/Parser.java Changeset: e62dba3ce52b Author: sundar Date: 2013-01-22 22:07 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e62dba3ce52b 8006678: Avoid too many Context.getGlobal() calls Reviewed-by: lagergren, jlaskey ! make/project.properties ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/ErrorManager.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/ParserException.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/URIUtils.java ! src/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java ! src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/Lookup.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java Changeset: 0dbcb7350595 Author: sundar Date: 2013-01-23 17:04 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/0dbcb7350595 8006736: nashorn script engine should support the usage multiple global objects with same engine instance Reviewed-by: lagergren, jlaskey, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: d4a968ca8953 Author: sundar Date: 2013-01-24 16:21 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d4a968ca8953 8006575: Error in codegen for element access on primitive value Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8006575.js Changeset: 3f528769aee1 Author: sundar Date: 2013-01-24 17:49 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/3f528769aee1 8006755: Functions inside with statements dont get correct scope Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8006755.js Changeset: edfa73d9fde7 Author: hannesw Date: 2013-01-24 14:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/edfa73d9fde7 8006408: Clean up and specialize NativeString Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/objects/NativeString.java + test/examples/string-micro.js Changeset: f336aee22e85 Author: jlaskey Date: 2013-01-24 12:15 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f336aee22e85 8006852: Move tests from JIRA for prepopulated map failures Reviewed-by: sundar Contributed-by: james.laskey at oracle.com + test/script/basic/JDK-8006852a.js + test/script/basic/JDK-8006852a.js.EXPECTED + test/script/basic/JDK-8006852b.js Changeset: bff7087396d7 Author: sundar Date: 2013-01-24 22:38 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/bff7087396d7 8006857: ClassCastException when interface implementing function uses arguments object Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8006857.js + test/script/basic/JDK-8006857.js.EXPECTED Changeset: f52d7294536f Author: hannesw Date: 2013-01-25 17:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f52d7294536f 8006766: Array-like access to characters of a string is slow Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java Changeset: 8f7a86f82376 Author: sundar Date: 2013-01-28 18:10 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/8f7a86f82376 8006983: Introduce a command line option to switch off syntactic extensions of nashorn Reviewed-by: lagergren, attila ! 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/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/resources/Options.properties + test/script/basic/JDK-8006983.js ! test/script/basic/scripting.js ! test/script/basic/scripting.js.EXPECTED Changeset: 265c46dbcf43 Author: sundar Date: 2013-01-28 21:29 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/265c46dbcf43 8007004: nashorn script engine should not use thread context class loader as script 'application loader' Reviewed-by: attila, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java Changeset: b6c69beebde6 Author: jlaskey Date: 2013-01-28 16:22 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b6c69beebde6 8006676: Integrate Nashorn into new build system Reviewed-by: jlaskey Contributed-by: james.laskey at oracle.com ! make/Makefile + makefiles/BuildNashorn.gmk + makefiles/Makefile Changeset: 333748665588 Author: sundar Date: 2013-01-29 19:57 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/333748665588 8007091: Provide private API to pass application class loader for nashorn script engine Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: 755404d7d189 Author: jlaskey Date: 2013-01-29 14:25 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/755404d7d189 8007094: Apply version to nashorn.jar manifest Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! makefiles/BuildNashorn.gmk Changeset: 59970b70ebb5 Author: lagergren Date: 2013-01-30 12:26 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/59970b70ebb5 8007062: Split Lower up into Lower/Attr/FinalizeTypes. Integrate AccessSpecalizer into FinalizeTypes. Summary: Lower suffered from being a "God class" trying to do everything at once. As Nashorn code generation has grown, so has Lower. It does several post processing passes, tries to do several things at once even though all type information isn't in place, adjusting state afterwards and so on. It also performs control flow analysis, type attribution and constant folding, and everything else code generation related before byte code emission. I have now separated the compilation process into Lower (create low level nodes from high level ones, copy code such as finally block inlining etc), Attr (assign types and symbols to all nodes - freeze slot and scope information) and FinalizeTypes (insert explicit casts, specialize invoke dynamic types for scope accesses). I've removed the kludgy AccessSpecializer, as this now integrates naturally with typing. Everything is now much easier to read and each module performs only one thing. I have added separate loggers for the separate ti ers. In the process I have also fixed: (1) problems with type coercion (see test/script/basic/typecoercion.js, basically our coercion was too late and our symbol inference was erroneous. This only manifested itself in very rare occasions where toNumber coercion has side effects, such as for example when valueOf is overridden) (2) copying literal nodes (literal copy did not use the superclass copy, which made all the Node specific fields not to be copied (3) erroneous literal tokenization (literals shouldn't always just inherit token information from whatever node that creates them) (4) splitter weighnodes - unary nodes were considered weightless (4) removed the hateful and kludgy "VarNode.shouldAppend", which really isn't needed when we have an attribution phase that determines self reference symbols (the only thing it was used for) (5) duplicate line number issues in the parser (6) convert bug in CodeGenerator for intermediate results of scope accesses (see test/script/b asic/access-specializer.js) ... Several of these things just stopped being problems with the new architecture "can't happen anymore" and are not bug fixes per se. All tests run. No performance regressions exist that I've been able to measure. Some increases in performance were measured, but in the statistical margin of error (which is very wide as HotSpot currently has warmup issues with LambdaForms/invoke dynamic). Compile speed has not measurably increased. Reviewed-by: jlaskey, attila ! docs/DEVELOPER_README ! src/jdk/nashorn/api/scripting/Formatter.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java - src/jdk/nashorn/internal/codegen/AccessSpecializer.java + src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.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/Lower.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/SharedScopeCall.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/CatchNode.java ! src/jdk/nashorn/internal/ir/ExecuteNode.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/ir/TryNode.java ! src/jdk/nashorn/internal/ir/VarNode.java ! src/jdk/nashorn/internal/ir/debug/ASTWriter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/parser/TokenType.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/OptionsObject.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! src/jdk/nashorn/tools/Shell.java + test/script/basic/access-specializer.js ! test/script/basic/compile-octane.js.EXPECTED ! test/script/basic/run-octane.js + test/script/basic/typecoerce.js + test/script/basic/typecoerce.js.EXPECTED Changeset: ca6d5e4b8170 Author: sundar Date: 2013-01-30 17:52 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ca6d5e4b8170 8007132: Java objects returned from constructor functions are lost Reviewed-by: hannesw, lagergren, attila ! src/jdk/nashorn/internal/runtime/ScriptFunction.java + test/script/basic/JDK-8007132.js Changeset: 9f913c1843c8 Author: hannesw Date: 2013-01-30 14:57 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/9f913c1843c8 8007109: Regression: String(ConsString) does not flatten argument to String Reviewed-by: sundar, lagergren ! src/jdk/nashorn/internal/objects/NativeString.java + test/script/basic/consstring.js + test/src/jdk/nashorn/internal/test/models/StringArgs.java Changeset: c04f54d5b672 Author: sundar Date: 2013-01-30 21:15 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c04f54d5b672 8007140: Java.extend crashes when attempting to extend java.lang.Object Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! test/script/basic/JDK-8006424.js + test/script/basic/JDK-8007140.js Changeset: 9c1e7ae975db Author: sundar Date: 2013-01-31 20:07 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/9c1e7ae975db 8007286: Add JavaAdapter and importPackage to compatibility script Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/resources/engine.js ! src/jdk/nashorn/internal/parser/TokenLookup.java ! src/jdk/nashorn/internal/parser/TokenType.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/PropertyHashMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js + test/script/basic/importpackage.js + test/script/basic/javaadapter.js Changeset: f7825c1a11d3 Author: attila Date: 2013-01-31 18:34 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f7825c1a11d3 8006529: Methods always get callee - it should be conditional Summary: This commit streamlines the bytecode function signatures, prologue, local variable use, scope creation, and invocation. It started out quite innocently when we noticed that we always emit __callee__ parameters for all functions even when they are not needed, but it turned out to be quite a deep rabbit hole. In the end, I identified exact conditions when functions need to have a callee parameter, when they need to receive parent scope, when they need to create their own scope, when they need to have variable arity signature, and when they need to have an "arguments" object, and made sure that callee parameters in signatures only show up when they are needed, that parent function's scope is only passed to a child function when it is needed, that the function only creates its own scope when it is needed. In crypto.js, the number of scopes dropped from 446 to 244, and the number of callees dropped from 315 to 145. Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/objects/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.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/Symbol.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/parser/Parser.java + src/jdk/nashorn/internal/runtime/ArgumentSetter.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/JDK-8006529-b.js + test/script/basic/JDK-8006529-b.js.EXPECTED + test/script/basic/JDK-8006529.js + test/src/jdk/nashorn/internal/codegen/CompilerAccess.java Changeset: 697f700d90c0 Author: hannesw Date: 2013-02-01 02:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/697f700d90c0 8007060: Primitive wrap filter throws ClassCastException in test262parallel Reviewed-by: sundar, jlaskey, lagergren ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java - src/jdk/nashorn/internal/runtime/linker/NashornGuardedInvocation.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuards.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java + test/script/basic/JDK-8007060.js + test/script/basic/JDK-8007060.js.EXPECTED Changeset: a704700470fb Author: jlaskey Date: 2013-02-04 08:13 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a704700470fb 8007455: Extraneous $(ECHO) in make/Makefile Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! make/Makefile Changeset: bb86bf840f9f Author: attila Date: 2013-02-04 15:59 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/bb86bf840f9f 8007460: var assignment to a parameter in a varargs method causes compilation error Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java + test/script/basic/JDK-8007460.js + test/script/basic/JDK-8007460.js.EXPECTED Changeset: bee7c8a45a04 Author: lagergren Date: 2013-02-04 16:20 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/bee7c8a45a04 8007215: Varargs broken for the case of passing more than the arg limit arguments. Reviewed-by: jlaskey, attila ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java ! src/jdk/nashorn/internal/codegen/SharedScopeCall.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8007215.js + test/script/basic/JDK-8007215.js.EXPECTED Changeset: 6f58c28c4faa Author: jlaskey Date: 2013-02-04 14:48 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/6f58c28c4faa 8006191: `cmd` -> exec("cmd") in script mode Reviewed-by: sundar, lagergren, hannesw Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/parser/TokenType.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/OptionsObject.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/script/basic/JDK-8006191.js + test/script/basic/JDK-8006191.js.EXPECTED Changeset: 5c2ed5d89524 Author: sundar Date: 2013-02-05 09:11 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/5c2ed5d89524 8007452: add scripting programmers doc changes for nashorn Reviewed-by: jlaskey, hannesw + docs/JavaScriptingProgrammersGuide.html + docs/source/EvalFile.java + docs/source/EvalScript.java + docs/source/InvokeScriptFunction.java + docs/source/InvokeScriptMethod.java + docs/source/MultiScopes.java + docs/source/RunnableImpl.java + docs/source/RunnableImplObject.java + docs/source/ScriptVars.java + docs/source/importpackageclass.js + docs/source/javaarray.js + docs/source/javaextend.js + docs/source/javaimporter.js + docs/source/javatypes.js + docs/source/overload.js + docs/source/runnable.js + docs/source/samfunc.js + docs/source/test.js ! src/jdk/nashorn/internal/objects/NativeJava.java Changeset: c48e8a28da90 Author: sundar Date: 2013-02-05 18:44 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c48e8a28da90 8007521: $ENV should be undefined when security manager is present Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java - test/script/basic/JDK-8006191.js - test/script/basic/JDK-8006191.js.EXPECTED + test/script/currently-failing/JDK-8006191.js + test/script/currently-failing/JDK-8006191.js.EXPECTED + test/script/sandbox/env.js + test/script/sandbox/exec.js Changeset: 819b5485949d Author: sundar Date: 2013-02-05 21:00 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/819b5485949d 8007522: IllegalStateException thrown from String.prototype.search function Reviewed-by: jlaskey ! src/jdk/nashorn/internal/objects/NativeRegExp.java + test/script/basic/JDK-8007522.js Changeset: f05d4dae30f7 Author: sundar Date: 2013-02-05 22:07 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f05d4dae30f7 8007523: VerifyError on script that uses regular expression literals with ternary operator Reviewed-by: lagergren ! src/jdk/nashorn/internal/ir/LiteralNode.java ! test/script/basic/JDK-8007522.js + test/script/basic/JDK-8007523.js Changeset: f6fae6de6f4f Author: hannesw Date: 2013-02-06 10:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f6fae6de6f4f 8007273: Creation of ScriptFunctions can be refactored Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/ObjectCreator.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java + src/jdk/nashorn/internal/runtime/ScriptFunctionData.java Changeset: fcf541418304 Author: sundar Date: 2013-02-06 17:56 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fcf541418304 8007619: Add support for deprecated properties of RegExp constructor Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8007619.js + test/script/basic/JDK-8007619.js.EXPECTED Changeset: ec4d59c9b8d2 Author: jlaskey Date: 2013-02-06 08:42 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ec4d59c9b8d2 8007545: jjs input evalinput need to be NOT_ENUMERABLE Reviewed-by: sundar, lagergren Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/tools/resources/shell.js Changeset: 2ca25bf25d0c Author: jlaskey Date: 2013-02-06 11:57 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/2ca25bf25d0c 8007629: Remove extraneous quit from shell.js Reviewed-by: sundar, hannesw Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/api/scripting/resources/init.js ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/tools/resources/shell.js Changeset: 02f810c26ff9 Author: jlaskey Date: 2013-02-06 12:51 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/02f810c26ff9 8007643: Add testing for quit and exit Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! test/script/sandbox/exit.js ! test/script/sandbox/exit.js.EXPECTED Changeset: d7e83be6e7aa Author: sundar Date: 2013-02-07 17:17 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d7e83be6e7aa 8007715: Make sure that not all tests run with AllPermission Reviewed-by: lagergren, attila ! make/build.xml ! make/project.properties ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java + test/script/README - test/script/basic/JDK-8006424.js - test/script/basic/JDK-8006529.js - test/script/basic/NASHORN-638.js - test/script/basic/NASHORN-638.js.EXPECTED - test/script/basic/NASHORN-653.js ! test/script/basic/NASHORN-758.js - test/script/basic/getenv.js - test/script/basic/getenv.js.EXPECTED ! test/script/basic/javaexceptions.js ! test/script/basic/newexpr.js + test/script/sandbox/interfaceimpl.js + test/script/sandbox/loadcompat.js + test/script/trusted/JDK-8006424.js + test/script/trusted/JDK-8006529.js + test/script/trusted/NASHORN-638.js + test/script/trusted/NASHORN-638.js.EXPECTED + test/script/trusted/NASHORN-653.js + test/script/trusted/README + test/script/trusted/getenv.js + test/script/trusted/getenv.js.EXPECTED ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java Changeset: bca3a64a4a82 Author: hannesw Date: 2013-02-07 14:58 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/bca3a64a4a82 8007627: Support @Getter annotation on constructor Reviewed-by: attila, lagergren ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/PrototypeGenerator.java Changeset: d5130a5803d1 Author: hannesw Date: 2013-02-07 15:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d5130a5803d1 8007718: Make static RegExp properties fully compatible to other engines Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/runtime/RegExpMatch.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8007718.js + test/script/basic/JDK-8007718.js.EXPECTED Changeset: 8742be332c8a Author: jlaskey Date: 2013-02-08 09:19 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/8742be332c8a 8006222: Move slot from SpillProperty to Property Reviewed-by: hannesw, lagergren Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/codegen/objects/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/MapCreator.java ! src/jdk/nashorn/internal/codegen/objects/ObjectCreator.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/SpillProperty.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java ! src/jdk/nashorn/internal/runtime/linker/Lookup.java Changeset: 5ead5333fa59 Author: attila Date: 2013-02-09 16:58 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/5ead5333fa59 8006943: Fix order of function method arguments to be (callee, thisObject) Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/objects/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/types/ObjectType.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java Changeset: abea4ba28901 Author: sundar Date: 2013-02-11 21:26 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/abea4ba28901 8007915: Nashorn IR, codegen, parser packages and Context instance should be inaccessible to user code Reviewed-by: lagergren, jlaskey, attila ! bin/jjssecure ! bin/jjssecure.bat ! bin/nashornsecure ! bin/nashornsecure.bat ! make/Makefile ! make/build.xml + make/java.security.override ! make/project.properties ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/DataPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeArrayBuffer.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeEvalError.java ! src/jdk/nashorn/internal/objects/NativeFloat32Array.java ! src/jdk/nashorn/internal/objects/NativeFloat64Array.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeInt16Array.java ! src/jdk/nashorn/internal/objects/NativeInt32Array.java ! src/jdk/nashorn/internal/objects/NativeInt8Array.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeRangeError.java ! src/jdk/nashorn/internal/objects/NativeReferenceError.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/NativeSyntaxError.java ! src/jdk/nashorn/internal/objects/NativeTypeError.java ! src/jdk/nashorn/internal/objects/NativeURIError.java ! src/jdk/nashorn/internal/objects/NativeUint16Array.java ! src/jdk/nashorn/internal/objects/NativeUint32Array.java ! src/jdk/nashorn/internal/objects/NativeUint8Array.java ! src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Lexer.java - src/jdk/nashorn/internal/parser/RegExp.java - src/jdk/nashorn/internal/parser/RegExpScanner.java ! src/jdk/nashorn/internal/runtime/ArgumentSetter.java ! src/jdk/nashorn/internal/runtime/BitVector.java ! src/jdk/nashorn/internal/runtime/ConsString.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/Debug.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/GlobalFunctions.java + src/jdk/nashorn/internal/runtime/JSONFunctions.java ! src/jdk/nashorn/internal/runtime/Logging.java ! src/jdk/nashorn/internal/runtime/NashornLoader.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java + src/jdk/nashorn/internal/runtime/RegExp.java + src/jdk/nashorn/internal/runtime/RegExpScanner.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/arrays/EmptyArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/MapIterator.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/resources/parser.js + test/script/sandbox/nashorninternals.js ! test/script/trusted/JDK-8006529.js + test/src/jdk/nashorn/api/javaaccess/BooleanAccessTest.java + test/src/jdk/nashorn/api/javaaccess/MethodAccessTest.java + test/src/jdk/nashorn/api/javaaccess/NumberAccessTest.java + test/src/jdk/nashorn/api/javaaccess/NumberBoxingTest.java + test/src/jdk/nashorn/api/javaaccess/ObjectAccessTest.java + test/src/jdk/nashorn/api/javaaccess/Person.java + test/src/jdk/nashorn/api/javaaccess/SharedObject.java + test/src/jdk/nashorn/api/javaaccess/StringAccessTest.java - test/src/jdk/nashorn/internal/access/BooleanAccessTest.java - test/src/jdk/nashorn/internal/access/MethodAccessTest.java - test/src/jdk/nashorn/internal/access/NumberAccessTest.java - test/src/jdk/nashorn/internal/access/NumberBoxingTest.java - test/src/jdk/nashorn/internal/access/ObjectAccessTest.java - test/src/jdk/nashorn/internal/access/Person.java - test/src/jdk/nashorn/internal/access/SharedObject.java - test/src/jdk/nashorn/internal/access/StringAccessTest.java - test/src/jdk/nashorn/internal/codegen/CompilerAccess.java Changeset: 774a0f349cc0 Author: hannesw Date: 2013-02-12 13:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/774a0f349cc0 8007956: Wrong or obsolete system properties in docs/DEVELOPER_README Reviewed-by: attila, jlaskey ! docs/DEVELOPER_README Changeset: d50e1752f59b Author: attila Date: 2013-02-12 12:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d50e1752f59b 8007900: Function binding is inefficient Reviewed-by: jlaskey, lagergren + src/jdk/nashorn/internal/objects/BoundScriptFunctionImpl.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/ArgumentSetter.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + src/jdk/nashorn/internal/runtime/SpecializedMethodChooser.java + test/script/basic/funcbind2.js + test/script/basic/funcbind2.js.EXPECTED + test/script/basic/funcbind3.js + test/script/basic/funcbind3.js.EXPECTED Changeset: a3dc1b180ce7 Author: hannesw Date: 2013-02-13 13:30 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a3dc1b180ce7 8008096: TokenStream buffer should grow exponentially Reviewed-by: attila, lagergren, sundar ! src/jdk/nashorn/internal/parser/TokenStream.java Changeset: 38c44687e4bd Author: sundar Date: 2013-02-13 19:59 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/38c44687e4bd 8008103: Source object should maintain URL of the script source as a private field Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/Source.java ! src/jdk/nashorn/tools/Shell.java ! test/src/jdk/nashorn/internal/codegen/CompilerTest.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java ! test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java Changeset: 222b9f32b674 Author: sundar Date: 2013-02-14 09:14 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/222b9f32b674 8008193: test262 tests should be run with security manager enabled Reviewed-by: jlaskey ! make/build.xml Changeset: 8c72a2bec1be Author: sundar Date: 2013-02-14 14:16 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/8c72a2bec1be 8008197: Cross script engine function calls do not work as expected Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/JDK-8008197.js ! test/script/basic/jquery.js Changeset: 43e32b36153c Author: lagergren Date: 2013-02-14 13:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/43e32b36153c 8008199: Lazy compilation and trampoline implementation Summary: The code pipeline now supports lazy compilation, which can be used to only compile certain FunctionNodes and leave others be, saving startup time. When these uncompiled nodes are hit, a trampoline will force them to be recompiled. This can also be used to specialize compilation fixing parameter types and return types to a callsite specific compilation. This will give performance. Reviewed-by: attila, sundar ! 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/CompileUnit.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/ConstantData.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/SharedScopeCall.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java - src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/ObjectClassGenerator.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/ir/visitor/NodeVisitor.java ! src/jdk/nashorn/internal/objects/BoundScriptFunctionImpl.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java + src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/tools/Shell.java ! test/script/trusted/JDK-8006529.js ! test/src/jdk/nashorn/internal/parser/ParserTest.java ! test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java Changeset: 5a820fb11814 Author: attila Date: 2013-02-14 13:22 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/5a820fb11814 8008085: Integrate Dynalink source code into Nashorn codebase Reviewed-by: jlaskey, lagergren, sundar ! THIRD_PARTY_README ! make/build.xml ! make/nbproject/project.xml ! make/project.properties + src/jdk/internal/dynalink/CallSiteDescriptor.java + src/jdk/internal/dynalink/ChainedCallSite.java + src/jdk/internal/dynalink/DefaultBootstrapper.java + src/jdk/internal/dynalink/DynamicLinker.java + src/jdk/internal/dynalink/DynamicLinkerFactory.java + src/jdk/internal/dynalink/MonomorphicCallSite.java + src/jdk/internal/dynalink/NoSuchDynamicMethodException.java + src/jdk/internal/dynalink/RelinkableCallSite.java + src/jdk/internal/dynalink/beans/AbstractJavaLinker.java + src/jdk/internal/dynalink/beans/AccessibleMembersLookup.java + src/jdk/internal/dynalink/beans/ApplicableOverloadedMethods.java + src/jdk/internal/dynalink/beans/BeanIntrospector.java + src/jdk/internal/dynalink/beans/BeanLinker.java + src/jdk/internal/dynalink/beans/BeansLinker.java + src/jdk/internal/dynalink/beans/CheckRestrictedPackage.java + src/jdk/internal/dynalink/beans/CheckRestrictedPackageInternal.java + src/jdk/internal/dynalink/beans/ClassLinker.java + src/jdk/internal/dynalink/beans/ClassString.java + src/jdk/internal/dynalink/beans/DynamicMethod.java + src/jdk/internal/dynalink/beans/DynamicMethodLinker.java + src/jdk/internal/dynalink/beans/FacetIntrospector.java + src/jdk/internal/dynalink/beans/GuardedInvocationComponent.java + src/jdk/internal/dynalink/beans/MaximallySpecific.java + src/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java + src/jdk/internal/dynalink/beans/OverloadedMethod.java + src/jdk/internal/dynalink/beans/RestrictedPackageTester.java + src/jdk/internal/dynalink/beans/SimpleDynamicMethod.java + src/jdk/internal/dynalink/beans/StaticClass.java + src/jdk/internal/dynalink/beans/StaticClassIntrospector.java + src/jdk/internal/dynalink/beans/StaticClassLinker.java + src/jdk/internal/dynalink/beans/messages.properties + src/jdk/internal/dynalink/beans/package.html + src/jdk/internal/dynalink/linker/ConversionComparator.java + src/jdk/internal/dynalink/linker/GuardedInvocation.java + src/jdk/internal/dynalink/linker/GuardingDynamicLinker.java + src/jdk/internal/dynalink/linker/GuardingTypeConverterFactory.java + src/jdk/internal/dynalink/linker/LinkRequest.java + src/jdk/internal/dynalink/linker/LinkerServices.java + src/jdk/internal/dynalink/linker/TypeBasedGuardingDynamicLinker.java + src/jdk/internal/dynalink/linker/package.html + src/jdk/internal/dynalink/package.html + src/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java + src/jdk/internal/dynalink/support/AbstractRelinkableCallSite.java + src/jdk/internal/dynalink/support/AutoDiscovery.java + src/jdk/internal/dynalink/support/Backport.java + src/jdk/internal/dynalink/support/BottomGuardingDynamicLinker.java + src/jdk/internal/dynalink/support/CallSiteDescriptorFactory.java + src/jdk/internal/dynalink/support/ClassMap.java + src/jdk/internal/dynalink/support/CompositeGuardingDynamicLinker.java + src/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java + src/jdk/internal/dynalink/support/DefaultCallSiteDescriptor.java + src/jdk/internal/dynalink/support/Guards.java + src/jdk/internal/dynalink/support/LinkRequestImpl.java + src/jdk/internal/dynalink/support/LinkerServicesImpl.java + src/jdk/internal/dynalink/support/Lookup.java + src/jdk/internal/dynalink/support/LookupCallSiteDescriptor.java + src/jdk/internal/dynalink/support/NameCodec.java + src/jdk/internal/dynalink/support/NamedDynCallSiteDescriptor.java + src/jdk/internal/dynalink/support/RuntimeContextLinkRequestImpl.java + src/jdk/internal/dynalink/support/TypeConverterFactory.java + src/jdk/internal/dynalink/support/TypeUtilities.java + src/jdk/internal/dynalink/support/UnnamedDynCallSiteDescriptor.java + src/jdk/internal/dynalink/support/messages.properties + src/jdk/internal/dynalink/support/package.html ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.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/NashornBottomLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.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 ! src/jdk/nashorn/internal/runtime/options/Options.java ! test/script/sandbox/nashorninternals.js ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java ! test/src/jdk/nashorn/internal/runtime/JSTypeTest.java Changeset: d086c3eead6b Author: lagergren Date: 2013-02-14 13:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d086c3eead6b 8008206: The allInteger case for SwitchNode generation in CodeGenerator assumes integer LITERALS only. Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8008206.js + test/script/basic/JDK-8008206.js.EXPECTED Changeset: 3df0a0d62d60 Author: attila Date: 2013-02-14 13:51 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/3df0a0d62d60 8007990: No access to interface methods on a restricted class Reviewed-by: jlaskey, lagergren, sundar ! make/build.xml + test/script/basic/JDK-8007990.js + test/script/basic/JDK-8007990.js.EXPECTED Changeset: d1ce4e09e4ba Author: hannesw Date: 2013-02-14 14:07 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d1ce4e09e4ba 8008198: java.lang.AssertionError: Invalid break target class jdk.nashorn.internal.ir.TryNode Reviewed-by: attila, jlaskey ! src/jdk/nashorn/internal/ir/LabelNode.java ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8008198.js + test/script/basic/JDK-8008198.js.EXPECTED Changeset: d41d7cf9ab8b Author: jlaskey Date: 2013-02-14 11:32 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d41d7cf9ab8b 8008231: Fix build system to accommodate integration of dynalink Reviewed-by: jlaskey Contributed-by: james.laskey at oracle.com ! makefiles/BuildNashorn.gmk Changeset: 36065e5ea3d1 Author: hannesw Date: 2013-02-15 09:18 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/36065e5ea3d1 8008215: break in catch clause causes java.lang.VerifyError: Inconsistent stackmap Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8008215.js + test/script/basic/JDK-8008215.js.EXPECTED Changeset: e478708faa22 Author: lagergren Date: 2013-02-15 09:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e478708faa22 8008239: Unpublicized parts of the code generator package that were only package internal. Reviewed-by: hannesw, attila ! src/jdk/nashorn/internal/codegen/BranchOptimizer.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/CompilerConstants.java + src/jdk/nashorn/internal/codegen/Condition.java + src/jdk/nashorn/internal/codegen/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java + src/jdk/nashorn/internal/codegen/Label.java + src/jdk/nashorn/internal/codegen/MapCreator.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java + src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java + src/jdk/nashorn/internal/codegen/ObjectCreator.java ! src/jdk/nashorn/internal/codegen/SharedScopeCall.java ! src/jdk/nashorn/internal/codegen/Splitter.java - src/jdk/nashorn/internal/codegen/objects/FieldObjectCreator.java - src/jdk/nashorn/internal/codegen/objects/MapCreator.java - src/jdk/nashorn/internal/codegen/objects/ObjectClassGenerator.java - src/jdk/nashorn/internal/codegen/objects/ObjectCreator.java - src/jdk/nashorn/internal/codegen/objects/ObjectMapCreator.java ! src/jdk/nashorn/internal/codegen/types/BooleanType.java ! src/jdk/nashorn/internal/codegen/types/IntType.java ! src/jdk/nashorn/internal/codegen/types/LongType.java ! src/jdk/nashorn/internal/codegen/types/NumberType.java ! src/jdk/nashorn/internal/ir/AccessNode.java ! src/jdk/nashorn/internal/ir/BaseNode.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/BreakNode.java ! src/jdk/nashorn/internal/ir/BreakableNode.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/IdentNode.java ! src/jdk/nashorn/internal/ir/IndexNode.java ! src/jdk/nashorn/internal/ir/LabelNode.java ! src/jdk/nashorn/internal/ir/LineNumberNode.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/ir/ReturnNode.java ! src/jdk/nashorn/internal/ir/SplitNode.java ! src/jdk/nashorn/internal/ir/SwitchNode.java ! src/jdk/nashorn/internal/ir/ThrowNode.java ! src/jdk/nashorn/internal/ir/TryNode.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/WhileNode.java ! src/jdk/nashorn/internal/ir/WithNode.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/Scope.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java Changeset: 757a49aaad02 Author: sundar Date: 2013-02-15 18:30 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/757a49aaad02 8008291: Add more tests for better coverage of objects, scripting and parser packages Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Scanner.java ! src/jdk/nashorn/internal/runtime/BitVector.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/QuotedStringTokenizer.java ! src/jdk/nashorn/internal/runtime/RegExpScanner.java ! src/jdk/nashorn/internal/runtime/Source.java ! src/jdk/nashorn/tools/Shell.java ! test/script/basic/NASHORN-401.js ! test/script/basic/NASHORN-401.js.EXPECTED + test/script/basic/assign_builtin_func_props.js + test/script/basic/debugger.js + test/script/basic/yield.js ! test/src/jdk/nashorn/api/scripting/MultipleEngineTest.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java ! test/src/jdk/nashorn/api/scripting/Window.java ! test/src/jdk/nashorn/internal/parser/ParserTest.java Changeset: 5851c5dac260 Author: sundar Date: 2013-02-15 20:40 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/5851c5dac260 8008298: Add tests to cover specialized versions of Math functions. Reviewed-by: jlaskey, lagergren + test/script/basic/JDK-8008298.js Changeset: d5f74bd2dc20 Author: sundar Date: 2013-02-18 14:41 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d5f74bd2dc20 8008305: ScriptEngine.eval should offer the ability to provide a codebase Reviewed-by: lagergren, hannesw, attila ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java + src/jdk/nashorn/api/scripting/URLReader.java + test/script/trusted/JDK-8008305.js + test/script/trusted/JDK-8008305_subtest.js + test/script/trusted/urlreader.js Changeset: 3245e174fe3a Author: hannesw Date: 2013-02-18 10:36 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/3245e174fe3a 8008351: Avoid using String.replace(String, String) in codegen Reviewed-by: sundar, attila ! src/jdk/nashorn/internal/codegen/Condition.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java Changeset: f8221ce53c2e Author: attila Date: 2013-02-18 16:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f8221ce53c2e 8008371: Fix Dynalink compiler warnings and whitespace Reviewed-by: jlaskey, sundar ! src/jdk/internal/dynalink/CallSiteDescriptor.java ! src/jdk/internal/dynalink/ChainedCallSite.java ! src/jdk/internal/dynalink/DefaultBootstrapper.java ! src/jdk/internal/dynalink/DynamicLinker.java ! src/jdk/internal/dynalink/DynamicLinkerFactory.java ! src/jdk/internal/dynalink/MonomorphicCallSite.java ! src/jdk/internal/dynalink/NoSuchDynamicMethodException.java ! src/jdk/internal/dynalink/RelinkableCallSite.java ! src/jdk/internal/dynalink/beans/AbstractJavaLinker.java ! src/jdk/internal/dynalink/beans/ApplicableOverloadedMethods.java ! src/jdk/internal/dynalink/beans/BeanLinker.java ! src/jdk/internal/dynalink/beans/BeansLinker.java ! src/jdk/internal/dynalink/beans/CheckRestrictedPackageInternal.java ! src/jdk/internal/dynalink/beans/ClassLinker.java ! src/jdk/internal/dynalink/beans/ClassString.java ! src/jdk/internal/dynalink/beans/DynamicMethod.java ! src/jdk/internal/dynalink/beans/DynamicMethodLinker.java ! src/jdk/internal/dynalink/beans/FacetIntrospector.java ! src/jdk/internal/dynalink/beans/GuardedInvocationComponent.java ! src/jdk/internal/dynalink/beans/MaximallySpecific.java ! src/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java ! src/jdk/internal/dynalink/beans/OverloadedMethod.java ! src/jdk/internal/dynalink/beans/SimpleDynamicMethod.java ! src/jdk/internal/dynalink/beans/StaticClass.java ! src/jdk/internal/dynalink/beans/StaticClassLinker.java ! src/jdk/internal/dynalink/linker/GuardedInvocation.java ! src/jdk/internal/dynalink/linker/GuardingDynamicLinker.java ! src/jdk/internal/dynalink/linker/GuardingTypeConverterFactory.java ! src/jdk/internal/dynalink/linker/LinkRequest.java ! src/jdk/internal/dynalink/linker/LinkerServices.java ! src/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java ! src/jdk/internal/dynalink/support/AbstractRelinkableCallSite.java ! src/jdk/internal/dynalink/support/AutoDiscovery.java ! src/jdk/internal/dynalink/support/BottomGuardingDynamicLinker.java ! src/jdk/internal/dynalink/support/CallSiteDescriptorFactory.java ! src/jdk/internal/dynalink/support/CompositeGuardingDynamicLinker.java ! src/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java ! src/jdk/internal/dynalink/support/DefaultCallSiteDescriptor.java ! src/jdk/internal/dynalink/support/Guards.java ! src/jdk/internal/dynalink/support/LinkRequestImpl.java ! src/jdk/internal/dynalink/support/LinkerServicesImpl.java ! src/jdk/internal/dynalink/support/Lookup.java ! src/jdk/internal/dynalink/support/LookupCallSiteDescriptor.java ! src/jdk/internal/dynalink/support/NamedDynCallSiteDescriptor.java ! src/jdk/internal/dynalink/support/RuntimeContextLinkRequestImpl.java ! src/jdk/internal/dynalink/support/TypeConverterFactory.java ! src/jdk/internal/dynalink/support/TypeUtilities.java ! src/jdk/internal/dynalink/support/UnnamedDynCallSiteDescriptor.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/Context.java Changeset: 4738de1bd57f Author: sundar Date: 2013-02-18 20:41 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/4738de1bd57f 8008387: Improve code coverage tests for JSObjectLinker and NashornBottomLinker Reviewed-by: lagergren, jlaskey, hannesw ! src/jdk/internal/dynalink/beans/BeansLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java + test/script/basic/javamethodcallerrors.js + test/script/basic/jsobject.js Changeset: b6798a83dbd4 Author: jlaskey Date: 2013-02-19 09:46 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b6798a83dbd4 8008420: Tweaks to make all NEWBUILD=false round 2 Reviewed-by: jjh Contributed-by: james.laskey at oracle.com ! make/Makefile Changeset: b228e3cdbfc3 Author: jlaskey Date: 2013-02-19 09:47 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b228e3cdbfc3 Merge Changeset: b632446ba138 Author: sundar Date: 2013-02-19 20:33 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b632446ba138 8008448: Add coverage test for jdk.nashorn.internal.ir.debug.JSONWriter Reviewed-by: jlaskey, attila ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java + test/script/basic/JDK-8008448.js Changeset: 58eea0e8f369 Author: sundar Date: 2013-02-20 17:08 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/58eea0e8f369 8008207: Make constants array and source fields private Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/Compiler.java Changeset: 671852e35ced Author: lagergren Date: 2013-02-20 16:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/671852e35ced 8008166: URL handling was broken on windows, causing "load" to malfunction Reviewed-by: attila, jlaskey Contributed-by: klara.ward at oracle.com ! make/build.xml ! src/jdk/nashorn/internal/runtime/Context.java Changeset: a971adb68f38 Author: lagergren Date: 2013-02-21 16:57 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a971adb68f38 8008648: Lazy JIT scope and callee semantics bugfixes. Broke out wallclock timer. Reviewed-by: attila, hannesw ! src/jdk/internal/dynalink/beans/BeansLinker.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + src/jdk/nashorn/internal/codegen/CompilationException.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/Lower.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/TernaryNode.java ! src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/NashornLoader.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java + src/jdk/nashorn/internal/runtime/Timing.java ! test/script/trusted/JDK-8006529.js Changeset: ae1c9716685b Author: jlaskey Date: 2013-02-21 15:24 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ae1c9716685b 8008447: Tweaks to make all NEWBUILD=false round 3 Reviewed-by: jjh, sundar Contributed-by: james.laskey at oracle.com ! make/Makefile Changeset: 678da59a29b3 Author: lagergren Date: 2013-02-22 08:57 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/678da59a29b3 8008554: load was broken for URLs Reviewed-by: attila, sundar ! src/jdk/nashorn/internal/runtime/Context.java + test/script/basic/JDK-8008554.js Changeset: 230a711062c1 Author: lagergren Date: 2013-02-22 11:27 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/230a711062c1 8008575: Re-integrate code coverage Reviewed-by: attila, hannesw Contributed-by: eugene.drobitko at oracle.com, ilya.dergalin at oracle.com ! make/build.xml + make/code_coverage.xml ! make/project.properties Changeset: 267cc4c85160 Author: lagergren Date: 2013-02-22 12:22 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/267cc4c85160 8007002: Replace implicit exception throwing methods with explicit throws - simplify control flow and remove useless code Reviewed-by: attila, hannesw ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/URLReader.java ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/ErrorManager.java ! src/jdk/nashorn/internal/runtime/JSONFunctions.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/ParserException.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/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/URIUtils.java ! src/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java ! src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/Lookup.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java Changeset: 3f0ff84aaf36 Author: jlaskey Date: 2013-02-22 10:39 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/3f0ff84aaf36 8008721: Tweaks to make all NEWBUILD=false round 4 Reviewed-by: jjh Contributed-by: james.laskey at oracle.com ! makefiles/BuildNashorn.gmk Changeset: 508da3c7fc3a Author: hannesw Date: 2013-02-22 16:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/508da3c7fc3a 8008093: Make RegExp engine pluggable Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/parser/AbstractParser.java - src/jdk/nashorn/internal/runtime/RegExp.java - src/jdk/nashorn/internal/runtime/RegExpMatch.java - src/jdk/nashorn/internal/runtime/RegExpScanner.java + src/jdk/nashorn/internal/runtime/regexp/DefaultRegExp.java + src/jdk/nashorn/internal/runtime/regexp/RegExp.java + src/jdk/nashorn/internal/runtime/regexp/RegExpFactory.java + src/jdk/nashorn/internal/runtime/regexp/RegExpMatcher.java + src/jdk/nashorn/internal/runtime/regexp/RegExpResult.java + src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java Changeset: e42fd1640ff9 Author: hannesw Date: 2013-02-22 17:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e42fd1640ff9 8006028: Integrate Joni regexp engine with Nashorn Reviewed-by: lagergren, attila ! THIRD_PARTY_README ! docs/DEVELOPER_README + src/jdk/nashorn/internal/runtime/regexp/JoniRegExp.java ! src/jdk/nashorn/internal/runtime/regexp/RegExpFactory.java + src/jdk/nashorn/internal/runtime/regexp/joni/Analyser.java + src/jdk/nashorn/internal/runtime/regexp/joni/ApplyCaseFold.java + src/jdk/nashorn/internal/runtime/regexp/joni/ApplyCaseFoldArg.java + src/jdk/nashorn/internal/runtime/regexp/joni/ArrayCompiler.java + src/jdk/nashorn/internal/runtime/regexp/joni/AsmCompiler.java + src/jdk/nashorn/internal/runtime/regexp/joni/AsmCompilerSupport.java + src/jdk/nashorn/internal/runtime/regexp/joni/BitSet.java + src/jdk/nashorn/internal/runtime/regexp/joni/BitStatus.java + src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodeMachine.java + src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodePrinter.java + src/jdk/nashorn/internal/runtime/regexp/joni/CaptureTreeNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/CodeRangeBuffer.java + src/jdk/nashorn/internal/runtime/regexp/joni/Compiler.java + src/jdk/nashorn/internal/runtime/regexp/joni/Config.java + src/jdk/nashorn/internal/runtime/regexp/joni/EncodingHelper.java + src/jdk/nashorn/internal/runtime/regexp/joni/Lexer.java + src/jdk/nashorn/internal/runtime/regexp/joni/Matcher.java + src/jdk/nashorn/internal/runtime/regexp/joni/MatcherFactory.java + src/jdk/nashorn/internal/runtime/regexp/joni/MinMaxLen.java + src/jdk/nashorn/internal/runtime/regexp/joni/NameEntry.java + src/jdk/nashorn/internal/runtime/regexp/joni/NativeMachine.java + src/jdk/nashorn/internal/runtime/regexp/joni/NodeOptInfo.java + src/jdk/nashorn/internal/runtime/regexp/joni/OptAnchorInfo.java + src/jdk/nashorn/internal/runtime/regexp/joni/OptEnvironment.java + src/jdk/nashorn/internal/runtime/regexp/joni/OptExactInfo.java + src/jdk/nashorn/internal/runtime/regexp/joni/OptMapInfo.java + src/jdk/nashorn/internal/runtime/regexp/joni/Option.java + src/jdk/nashorn/internal/runtime/regexp/joni/Parser.java + src/jdk/nashorn/internal/runtime/regexp/joni/Regex.java + src/jdk/nashorn/internal/runtime/regexp/joni/Region.java + src/jdk/nashorn/internal/runtime/regexp/joni/ScanEnvironment.java + src/jdk/nashorn/internal/runtime/regexp/joni/ScannerSupport.java + src/jdk/nashorn/internal/runtime/regexp/joni/SearchAlgorithm.java + src/jdk/nashorn/internal/runtime/regexp/joni/StackEntry.java + src/jdk/nashorn/internal/runtime/regexp/joni/StackMachine.java + src/jdk/nashorn/internal/runtime/regexp/joni/Syntax.java + src/jdk/nashorn/internal/runtime/regexp/joni/Token.java + src/jdk/nashorn/internal/runtime/regexp/joni/UnsetAddrList.java + src/jdk/nashorn/internal/runtime/regexp/joni/WarnCallback.java + src/jdk/nashorn/internal/runtime/regexp/joni/Warnings.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/AnchorNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/AnyCharNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/BackRefNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/CClassNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/CTypeNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/CallNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/ConsAltNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/EncloseNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/Node.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/QuantifierNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/StateNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/StringNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/bench/AbstractBench.java + src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchGreedyBacktrack.java + src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchRailsRegs.java + src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchSeveralRegexps.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/AnchorType.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/Arguments.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/AsmConstants.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/CCSTATE.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/CCVALTYPE.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/EncloseType.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/MetaChar.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/NodeStatus.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/NodeType.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/OPCode.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/OPSize.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/Reduce.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/RegexState.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/StackPopLevel.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/StackType.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/StringType.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/SyntaxProperties.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/TargetInfo.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/TokenType.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/Traverse.java + src/jdk/nashorn/internal/runtime/regexp/joni/encoding/AsciiTables.java + src/jdk/nashorn/internal/runtime/regexp/joni/encoding/CharacterType.java + src/jdk/nashorn/internal/runtime/regexp/joni/encoding/IntHolder.java + src/jdk/nashorn/internal/runtime/regexp/joni/encoding/ObjPtr.java + src/jdk/nashorn/internal/runtime/regexp/joni/encoding/PosixBracket.java + src/jdk/nashorn/internal/runtime/regexp/joni/encoding/Ptr.java + src/jdk/nashorn/internal/runtime/regexp/joni/exception/ErrorMessages.java + src/jdk/nashorn/internal/runtime/regexp/joni/exception/InternalException.java + src/jdk/nashorn/internal/runtime/regexp/joni/exception/JOniException.java + src/jdk/nashorn/internal/runtime/regexp/joni/exception/SyntaxException.java + src/jdk/nashorn/internal/runtime/regexp/joni/exception/ValueException.java Changeset: 7f5b7c6859d7 Author: sundar Date: 2013-02-22 22:39 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/7f5b7c6859d7 8008729: Make sure that we can run basic jsr223 tests using jtreg Reviewed-by: jlaskey, hannesw, lagergren + test/TEST.ROOT ! test/src/jdk/nashorn/api/scripting/MultipleEngineTest.java + test/src/jdk/nashorn/api/scripting/ScriptEngineSecurityTest.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: 5452f82eb2ce Author: jlaskey Date: 2013-02-22 23:33 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/5452f82eb2ce 8008776: Revise BuildNashorn.gmk for changes in new build system Reviewed-by: jjh Contributed-by: james.laskey at oracle.com ! makefiles/BuildNashorn.gmk Changeset: 927fba6785b0 Author: sundar Date: 2013-02-25 16:58 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/927fba6785b0 8008731: Separate configuration environment (options, error/output writer etc.) from Context Reviewed-by: hannesw, lagergren ! 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/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/JSONFunctions.java - src/jdk/nashorn/internal/runtime/OptionsObject.java + src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/tools/Shell.java ! test/script/trusted/JDK-8006529.js ! test/src/jdk/nashorn/internal/parser/ParserTest.java ! test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java Changeset: 5610ac25d8ff Author: sundar Date: 2013-02-25 18:13 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/5610ac25d8ff 8008789: Enable java access and nashorn runtime tests for jtreg Reviewed-by: lagergren, jlaskey, hannesw ! make/build.xml ! test/TEST.ROOT ! test/src/jdk/nashorn/api/javaaccess/BooleanAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/MethodAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/NumberAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/NumberBoxingTest.java ! test/src/jdk/nashorn/api/javaaccess/ObjectAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/StringAccessTest.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java ! test/src/jdk/nashorn/internal/runtime/JSTypeTest.java + test/src/jdk/nashorn/internal/runtime/TrustedScriptEngineTest.java From kumar.x.srinivasan at oracle.com Mon Feb 25 15:10:58 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 25 Feb 2013 07:10:58 -0800 Subject: RFR: 8006039 : test/tools/launcher/I18NJarTest.java fails on Mac w/ LANG=C, LC_ALL=C In-Reply-To: <512805C8.3070200@oracle.com> References: <5126BD1C.8030309@oracle.com> <5126E713.9090505@oracle.com> <512805C8.3070200@oracle.com> Message-ID: <512B7F02.2070405@oracle.com> Hi Brent, Ok I tested on Windows with JA installed and your patch works, also tested on Solaris. On other nit, Copyright on I18NJarTest.java needs updating. Looks good, go for it. Thanks Kumar > On 2/21/13 7:33 PM, Kumar Srinivasan wrote: >> >> A nit >> - " LC_ALL" + LC_ALL + "\n" + >> + " LC_ALL=" + LC_ALL + "\n" + > > Done, thanks. > >> If Mac is the only system affected by this, should we make the checks >> for >> LC* and LANG specific to Macs since other platforms don't have this >> issue ? >> I am concerned this might pass vacuously on systems configured >> correctly. > > LANG/LC_ALL=C is not a correct configuration for running this test. > It ought to pass vacuously in this case (and does, AFAIK, on other > platforms). > > What is Mac-specific is that sun.jnu.encoding is now always set to > UTF-8, even under LANG/LC_ALL=C. The test sees this, and tries (and > fails) to run the "real" test instead of passing vacuously. > > I don't think it does any harm to check for LANG/LC_ALL != 'C' on > other platforms. But it's only on Mac that it's required in order to > detect a mis-configured test environment. > >>> Of course it would be even better to update the test so the automated >>> test machines actually test the intended functionality. > >> ... > >> I can file a separate bug for this. > > I've filed 8008761 (test/tools/launcher/I18NJarTest.java should > automatically setup its environment) to cover this. > > To be clear, my short-term goal is to take I18NJarTest back off the > ProblemList. The test does correctly test the intended functionality > under the default Mac environment (LANG=en_US.UTF-8). So I want to > get it running again for engineers using the "jdk_tools" test target > on their local Mac (without causing nightly test failure noise). > > Later, as time permits, I can tackle 8008761, and get the test to > configure its own environment. > > Thanks, > -Brent From mike.duigou at oracle.com Mon Feb 25 15:55:56 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 25 Feb 2013 07:55:56 -0800 Subject: hg: jdk8/tl/jdk: 8008167: IdentityHashMap.[keySet|values|entrySet].toArray speed-up In-Reply-To: <512B340B.9020803@oracle.com> References: <20130214175538.236EC47A96@hg.openjdk.java.net> <512A149D.3030204@oracle.com> <512A3689.3000900@gmail.com> <512A609A.10002@oracle.com> <03FC4A5C-AF4D-45A2-908C-CFAC0AEA562B@oracle.com> <512A77C3.9070902@gmail.com> <512B340B.9020803@oracle.com> Message-ID: <2789B698-A96C-48B1-A7FF-DAA5142C3C25@oracle.com> On Feb 25 2013, at 01:51 , Alan Bateman wrote: > On 25/02/2013 04:06, Mike Duigou wrote: >> I have created an issue for fixing the introduced regression and created a regression test that would have caught the error (fix a bug, write a test...). >> >> 8008785: IdentityHashMap.values().toArray(V[]) broken by JDK-8008167 >> >> http://cr.openjdk.java.net/~mduigou/JDK-8008785/0/webrev >> >> Mike > The fix to IdentityHashMap looks good. It is surprising that it wasn't caught by tests in the jdk repository so a reminder that we always need to check that we have good test coverage when doing performance fixes. Yes, I should have checked not just that the existing tests passed but that there was a specific test for what was being changed. I was very surprised to discover after the fact that there was no test at all for ToArray. > > The webrev suggests you've replaced Map/Collisions.java and assume that is not the intention. Otherwise the new test looks okay, an alternative would have been to expand MOAT. Webrev doesn't properly recognize 'hg copy' and sees it as a rename. I started ToArray.java by copying Collisions.java Mike > -Alan. From nils.loodin at oracle.com Mon Feb 25 16:30:25 2013 From: nils.loodin at oracle.com (Nils Loodin) Date: Mon, 25 Feb 2013 17:30:25 +0100 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <512B675A.7090207@gmail.com> References: <5115316A.8050109@oracle.com> <51291AEB.3040005@gmail.com> <5129534A.8000500@oracle.com> <5129D45A.6010802@gmail.com> <5129EBE5.1030207@oracle.com> <512A7593.7040807@gmail.com> <512A7EB6.8090503@oracle.com> <512A8554.6080203@gmail.com> <512A8AC2.9020800@oracle.com> <512A8E95.9000902@gmail.com> <512A91A6.7090804@oracle.com> <512B2EEC.5050200@oracle.com> <512B675A.7090207@gmail.com> Message-ID: <512B91A1.8020603@oracle.com> On 02/25/2013 02:30 PM, Peter Levart wrote: > On 02/25/2013 10:29 AM, Nils Loodin wrote: >> On 02/24/2013 11:18 PM, David Holmes wrote: >>> We've not-so-slightly hijacked Nils' thread here - apologies for that. >> >> David, Peter! >> >> Yes you did :) >> However, feel free to make it up to me by: >> 1. Suggest a good name for the counter > > As Jason Mehrens pointed out in this thread, the "thrownThrowables" > might be misleading if the counter is incremented in the Throwable > constructors (or are you going to instrument the throw sites?). So it > might better be called what it is: "constructedThrowables". Yes, this > is a common idiom: > > throw new ThrowableSubclass(...); > > ...but the number of thrown and constructed throwables may diverge > considerably in situations like for example: > > - preallocated throwable instances used (and reused) as a form of > "long return" (from lambdas). > - deserialized throwables on RMI clients that are thrown on the server > side, transfered over the wire and re-thrown on client side > (de-seriailization does not call the constructor) > I changed it to sun.throwables.numThrowables in http://cr.openjdk.java.net/~nloodin/8007806/webrev.01/ Is this better? However, bear in mind that it's not exactly specified where this is going to be incremented from yet. Nothing in this change states that it's going to be incremented from the Throwable constructor. Regards, Nils Loodin From peter.levart at gmail.com Mon Feb 25 17:05:44 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 25 Feb 2013 18:05:44 +0100 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <512B91A1.8020603@oracle.com> References: <5115316A.8050109@oracle.com> <51291AEB.3040005@gmail.com> <5129534A.8000500@oracle.com> <5129D45A.6010802@gmail.com> <5129EBE5.1030207@oracle.com> <512A7593.7040807@gmail.com> <512A7EB6.8090503@oracle.com> <512A8554.6080203@gmail.com> <512A8AC2.9020800@oracle.com> <512A8E95.9000902@gmail.com> <512A91A6.7090804@oracle.com> <512B2EEC.5050200@oracle.com> <512B675A.7090207@gmail.com> <512B91A1.8020603@oracle.com> Message-ID: <512B99E8.1080803@gmail.com> On 02/25/2013 05:30 PM, Nils Loodin wrote: > On 02/25/2013 02:30 PM, Peter Levart wrote: >> On 02/25/2013 10:29 AM, Nils Loodin wrote: >>> On 02/24/2013 11:18 PM, David Holmes wrote: >>>> We've not-so-slightly hijacked Nils' thread here - apologies for that. >>> >>> David, Peter! >>> >>> Yes you did :) >>> However, feel free to make it up to me by: >>> 1. Suggest a good name for the counter >> >> As Jason Mehrens pointed out in this thread, the "thrownThrowables" >> might be misleading if the counter is incremented in the Throwable >> constructors (or are you going to instrument the throw sites?). So it >> might better be called what it is: "constructedThrowables". Yes, this >> is a common idiom: >> >> throw new ThrowableSubclass(...); >> >> ...but the number of thrown and constructed throwables may diverge >> considerably in situations like for example: >> >> - preallocated throwable instances used (and reused) as a form of >> "long return" (from lambdas). >> - deserialized throwables on RMI clients that are thrown on the >> server side, transfered over the wire and re-thrown on client side >> (de-seriailization does not call the constructor) >> > > I changed it to > > sun.throwables.numThrowables > > in http://cr.openjdk.java.net/~nloodin/8007806/webrev.01/ > > Is this better? However, bear in mind that it's not exactly specified > where this is going to be incremented from yet. Nothing in this change > states that it's going to be incremented from the Throwable constructor. These are just suggestions... thinking loud ... Other hierarchical names for counters use two common forms (note plural/singular): sun.classloader.findClassTime sun.classloader.findClasses sun.classloader.parentDelegationTime or: java.threads.daemon java.threads.live java.threads.livePeak java.threads.started So by these forms, the name could be: sun.throwable.numThrowables or: sun.throwables.num[ber] might be later changed to (if instrumented to increment at construction time and/or throw time): sun.throwables.constructed sun.throwables.thrown until then, it could be simply: sun.throwables Regards, Peter > > Regards, > Nils Loodin > > From alan.bateman at oracle.com Mon Feb 25 17:19:22 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 25 Feb 2013 17:19:22 +0000 Subject: hg: jdk8/tl/jdk: 8008808: Allowed dependencies added by JDK-8008481 no longer required Message-ID: <20130225171953.F389247E38@hg.openjdk.java.net> Changeset: 155095c245b4 Author: alanb Date: 2013-02-25 17:17 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/155095c245b4 8008808: Allowed dependencies added by JDK-8008481 no longer required Reviewed-by: tbell, chegar ! make/tools/src/build/tools/deps/refs.allowed From paul.sandoz at oracle.com Mon Feb 25 17:31:32 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 25 Feb 2013 18:31:32 +0100 Subject: Code review request In-Reply-To: <51289F3D.1010609@univ-mlv.fr> References: <512672E6.1050708@oracle.com> <51289F3D.1010609@univ-mlv.fr> Message-ID: <458B2D62-336C-429C-B835-DEEC7031004B@oracle.com> Hi Remi, Thanks for the feedback i have addressed some of this, mostly related to inner classes, in following change set to the lambda repo: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3e50294c68ea We can update the webrev next week. On Feb 23, 2013, at 11:51 AM, Remi Forax wrote: > On 02/21/2013 08:17 PM, Brian Goetz wrote: >> At >> http://cr.openjdk.java.net/~briangoetz/jdk-8008670/webrev/ >> >> I've posted a webrev for about half the classes in java.util.stream. None of these are public classes, so there are no public API issues here, but plenty of internal API issues, naming issues (ooh, a bikeshed), and code quality issues. >> > > Hi Brian, > > All protected fields should not be protected but package visible. > Classes are package private so there is no need to use a modifier which offer a wider visibility. > The same is true for constructors. > I agree with this, if there are no further objections i will fix in the lambda repo towards the end of the week. > For default method, some of them are marked public, some of them are not, > what the coding convention said ? > AFAICT "public" was only on two such default methods, so i have removed that modifier. > Code convention again, there is a lot of if/else with no curly braces, or only curly braces > on the if part but not on the else part. > Also, when a if block ends with a return, there is no need to use 'else', > > if (result != null) { > foundResult(result); > return result; > } > else > return null; > > can be simply written: > > if (result != null) { > foundResult(result); > return result; > } > return null; > Regarding code conventions i would prefer to auto-format all code to ensure consistency, as to what that consistency is, well we could argue until heat death of the universe :-) I am fine as long as it is consistent and easy to hit Alt-Cmd-L or what ever it is in ones favourite IDE. > > All inner class should not have private constructors, like by example FindOp.FindTask, because > the compiler will have to generate a special accessor for them when they are called from > the outer class. > I have made changes to all inner classes to conform to this. I have also marked all classes as final where appropriate. > In AbstractShortCircuitTask: > It's not clear that cancel and sharedResult can be accessed directly given that they both have methods that acts as getter and setter. > If they can be accessed directly, I think it's better to declare them private and to use getters. > They should be private, they are not accessed outside of that class. I will fix. > Depending on the ops, some of them do nullcheks of arguments at creating time (ForEachOp) , some of them don't (FindOp). > In ForEachUntilOp, the 'consumer' is checked but 'until' is not. > OK, there are probably lots of missing null checks in the code... > in ForEachOp, most of the keyword protected are not needed, ForEachUntilOp which inherits from ForEachOp is in the same package. > > In ForEachUntilOp, the constructor should be private (like for all the other ops). > Done. > In MatchOp, line 110, I think the compiler bug is fixed now ? Not yet, i can still reproduce it. > The enum MatchKind should not be public and all constructor of all inner classes should not be private. > Done. > In OpsUtils, some static methods are public and some are not, > OpUtils is now gone in the lambda repo. The forEach and reduce functionality is moved into the corresponding op classes. The static method has been moved to a default method on PipelineHelper. > in Tripwire: > enabled should be in uppercase (ENABLED). > method trip() should be: > public static void trip(Class trippingClass, String msg) > Done. I also made the field and method package private. Thanks, Paul. From mike.duigou at oracle.com Mon Feb 25 17:58:16 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 25 Feb 2013 09:58:16 -0800 Subject: hg: jdk8/tl/jdk: 8008167: IdentityHashMap.[keySet|values|entrySet].toArray speed-up In-Reply-To: <512B340B.9020803@oracle.com> References: <20130214175538.236EC47A96@hg.openjdk.java.net> <512A149D.3030204@oracle.com> <512A3689.3000900@gmail.com> <512A609A.10002@oracle.com> <03FC4A5C-AF4D-45A2-908C-CFAC0AEA562B@oracle.com> <512A77C3.9070902@gmail.com> <512B340B.9020803@oracle.com> Message-ID: <8FA66627-6679-4F40-86D8-AA6DF07EFF81@oracle.com> On Feb 25 2013, at 01:51 , Alan Bateman wrote: > On 25/02/2013 04:06, Mike Duigou wrote: >> I have created an issue for fixing the introduced regression and created a regression test that would have caught the error (fix a bug, write a test...). >> >> 8008785: IdentityHashMap.values().toArray(V[]) broken by JDK-8008167 >> >> http://cr.openjdk.java.net/~mduigou/JDK-8008785/0/webrev >> >> Mike > The fix to IdentityHashMap looks good. It is surprising that it wasn't caught by tests in the jdk repository so a reminder that we always need to check that we have good test coverage when doing performance fixes. > > The webrev suggests you've replaced Map/Collisions.java and assume that is not the intention. Otherwise the new test looks okay, an alternative would have been to expand MOAT. Ouch! The patch generated by webrev gets it wrong too: --- old/test/java/util/Map/Collisions.java 2013-02-24 19:47:40.491333191 -0800 +++ /dev/null 2013-02-24 18:12:51.832474922 -0800 --- /dev/null 2013-02-24 18:12:51.832474922 -0800 +++ new/test/java/util/Map/ToArray.java 2013-02-24 19:47:40.319333199 -0800 vs diff on source repo: diff --git a/test/java/util/Map/Collisions.java b/test/java/util/Map/ToArray.java copy from test/java/util/Map/Collisions.java copy to test/java/util/Map/ToArray.java --- a/test/java/util/Map/Collisions.java +++ b/test/java/util/Map/ToArray.java From Alan.Bateman at oracle.com Mon Feb 25 18:13:44 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 25 Feb 2013 18:13:44 +0000 Subject: hg: jdk8/tl/jdk: 8008167: IdentityHashMap.[keySet|values|entrySet].toArray speed-up In-Reply-To: <2789B698-A96C-48B1-A7FF-DAA5142C3C25@oracle.com> References: <20130214175538.236EC47A96@hg.openjdk.java.net> <512A149D.3030204@oracle.com> <512A3689.3000900@gmail.com> <512A609A.10002@oracle.com> <03FC4A5C-AF4D-45A2-908C-CFAC0AEA562B@oracle.com> <512A77C3.9070902@gmail.com> <512B340B.9020803@oracle.com> <2789B698-A96C-48B1-A7FF-DAA5142C3C25@oracle.com> Message-ID: <512BA9D8.5010400@oracle.com> On 25/02/2013 15:55, Mike Duigou wrote: > : > >> The webrev suggests you've replaced Map/Collisions.java and assume that is not the intention. Otherwise the new test looks okay, an alternative would have been to expand MOAT. > Webrev doesn't properly recognize 'hg copy' and sees it as a rename. I started ToArray.java by copying Collisions.java > Are you sure you want to do "hg copy" here? This means that hg will track the copy and I assume we don't want that here. -Alan. From mike.duigou at oracle.com Mon Feb 25 18:28:46 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 25 Feb 2013 10:28:46 -0800 Subject: hg: jdk8/tl/jdk: 8008167: IdentityHashMap.[keySet|values|entrySet].toArray speed-up In-Reply-To: <512BA9D8.5010400@oracle.com> References: <20130214175538.236EC47A96@hg.openjdk.java.net> <512A149D.3030204@oracle.com> <512A3689.3000900@gmail.com> <512A609A.10002@oracle.com> <03FC4A5C-AF4D-45A2-908C-CFAC0AEA562B@oracle.com> <512A77C3.9070902@gmail.com> <512B340B.9020803@oracle.com> <2789B698-A96C-48B1-A7FF-DAA5142C3C25@oracle.com> <512BA9D8.5010400@oracle.com> Message-ID: <40D43230-ECC3-4244-AFC7-83C97DCF50C9@oracle.com> On Feb 25 2013, at 10:13 , Alan Bateman wrote: > On 25/02/2013 15:55, Mike Duigou wrote: >> : >> >>> The webrev suggests you've replaced Map/Collisions.java and assume that is not the intention. Otherwise the new test looks okay, an alternative would have been to expand MOAT. >> Webrev doesn't properly recognize 'hg copy' and sees it as a rename. I started ToArray.java by copying Collisions.java >> > Are you sure you want to do "hg copy" here? This means that hg will track the copy and I assume we don't want that here. Some people would just do a plain shell copy of the file and then hg add the "new" file. I prefer to use an actual SCM copy because I am re-using portions of the original file. If it turns out there is a bug in the boilerplate that I copied the "hg copy" does leave a tenuous link back to the source which would still have the same bug. If I just used regular copy and then hg add then that link is broken completely. Mike From brent.christian at oracle.com Mon Feb 25 18:53:36 2013 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 25 Feb 2013 10:53:36 -0800 Subject: RFR: 8006039 : test/tools/launcher/I18NJarTest.java fails on Mac w/ LANG=C, LC_ALL=C In-Reply-To: <5127B780.6090800@oracle.com> References: <5126BD1C.8030309@oracle.com> <5127B780.6090800@oracle.com> Message-ID: <512BB330.6070903@oracle.com> On 2/22/13 10:22 AM, Naoto Sato wrote: > check not only "C" but also other locales that do not use UTF-8 > encoding. I would like to make the test more robust (per 8008761), though my focus at the moment is to avoid a test failure on our automated test systems, which all use "C". I've made a note in 8008761 that we should check for other locales that do not use UTF-8. > Also, "LC_ALL" precedes "LANG" environment variable, so I'd > check "LC_ALL" first, and if it is not exported then check "LANG" variable. Good point - I'll check LC_ALL first. Updated webrev with re-ordered LC_ALL check (and "LC_ALL=" output change) is here: http://cr.openjdk.java.net/~bchristi/8006039/webrev.01/ Thanks, -Brent > On 2/21/13 4:34 PM, Brent Christian wrote: >> Hi, >> >> This test started failing after 8003228 [1] was putback (setting >> sun.jnu.encoding to UTF-8 on Mac). It tests if java is able to launch a >> .jar stored in a directory named with two-byte characters. >> >> The code comments in the test case state that (on Unix) it expects >> LC_ALL to be set (to ja_JP.UTF-8/ja_JP.utf8/ja_JP.ujis), though it also >> seems to work with en_US.UTF-8). >> >> Our automated build+test Macs have LANG=C, so the test has been >> "passing" without actually testing the functionality. >> >> The test case determines if the environment is suitable for testing by >> checking if sun.jnu.encoding is either "MS932" or "UTF-8" (on Mac, this >> is now always UTF-8). The test doesn't actually check LC_ALL. >> >> I think the test should also check the LANG & LC_ALL env vars, and go >> back to "fake passing" the test if either is set to 'C'. This would >> allow the test to continue to run "for real" in the default Mac >> environment (LANG=en_US.UTF-8), and stop the test from failing on the >> build+test Macs. >> >> Of course it would be even better to update the test so the automated >> test machines actually test the intended functionality. On UNIX at >> least, perhaps it could find something suitable to set LC_ALL to before >> attempting to launch the .jar. I can file a separate bug for this. >> >> Webrev is here: >> http://cr.openjdk.java.net/~bchristi/8006039/webrev.00/ >> >> Thanks, >> -Brent >> >> [1] >> http://bugs.sun.com/view_bug.do?bug_id=8003228 > From naoto.sato at oracle.com Mon Feb 25 18:59:41 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 25 Feb 2013 10:59:41 -0800 Subject: RFR: 8006039 : test/tools/launcher/I18NJarTest.java fails on Mac w/ LANG=C, LC_ALL=C In-Reply-To: <512BB330.6070903@oracle.com> References: <5126BD1C.8030309@oracle.com> <5127B780.6090800@oracle.com> <512BB330.6070903@oracle.com> Message-ID: <512BB49D.5000201@oracle.com> Looks good. Thank you for fixing this. Naoto On 2/25/13 10:53 AM, Brent Christian wrote: > On 2/22/13 10:22 AM, Naoto Sato wrote: >> check not only "C" but also other locales that do not use UTF-8 >> encoding. > > I would like to make the test more robust (per 8008761), though my focus > at the moment is to avoid a test failure on our automated test systems, > which all use "C". > > I've made a note in 8008761 that we should check for other locales that > do not use UTF-8. > > > Also, "LC_ALL" precedes "LANG" environment variable, so I'd >> check "LC_ALL" first, and if it is not exported then check "LANG" >> variable. > > Good point - I'll check LC_ALL first. > > Updated webrev with re-ordered LC_ALL check (and "LC_ALL=" output > change) is here: > http://cr.openjdk.java.net/~bchristi/8006039/webrev.01/ > > Thanks, > -Brent > >> On 2/21/13 4:34 PM, Brent Christian wrote: >>> Hi, >>> >>> This test started failing after 8003228 [1] was putback (setting >>> sun.jnu.encoding to UTF-8 on Mac). It tests if java is able to launch a >>> .jar stored in a directory named with two-byte characters. >>> >>> The code comments in the test case state that (on Unix) it expects >>> LC_ALL to be set (to ja_JP.UTF-8/ja_JP.utf8/ja_JP.ujis), though it also >>> seems to work with en_US.UTF-8). >>> >>> Our automated build+test Macs have LANG=C, so the test has been >>> "passing" without actually testing the functionality. >>> >>> The test case determines if the environment is suitable for testing by >>> checking if sun.jnu.encoding is either "MS932" or "UTF-8" (on Mac, this >>> is now always UTF-8). The test doesn't actually check LC_ALL. >>> >>> I think the test should also check the LANG & LC_ALL env vars, and go >>> back to "fake passing" the test if either is set to 'C'. This would >>> allow the test to continue to run "for real" in the default Mac >>> environment (LANG=en_US.UTF-8), and stop the test from failing on the >>> build+test Macs. >>> >>> Of course it would be even better to update the test so the automated >>> test machines actually test the intended functionality. On UNIX at >>> least, perhaps it could find something suitable to set LC_ALL to before >>> attempting to launch the .jar. I can file a separate bug for this. >>> >>> Webrev is here: >>> http://cr.openjdk.java.net/~bchristi/8006039/webrev.00/ >>> >>> Thanks, >>> -Brent >>> >>> [1] >>> http://bugs.sun.com/view_bug.do?bug_id=8003228 >> From kumar.x.srinivasan at oracle.com Mon Feb 25 19:09:46 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 25 Feb 2013 11:09:46 -0800 Subject: RFR: 8006039 : test/tools/launcher/I18NJarTest.java fails on Mac w/ LANG=C, LC_ALL=C In-Reply-To: <512BB49D.5000201@oracle.com> References: <5126BD1C.8030309@oracle.com> <5127B780.6090800@oracle.com> <512BB330.6070903@oracle.com> <512BB49D.5000201@oracle.com> Message-ID: <512BB6FA.5000609@oracle.com> couple of minor nits I did not see in rev 01. Copyright, - if("C".equals(LC_ALL) || "C".equals(LANG)) { + if ("C".equals(LC_ALL) || "C".equals(LANG)) { Kumar > Looks good. Thank you for fixing this. > > Naoto > > On 2/25/13 10:53 AM, Brent Christian wrote: >> On 2/22/13 10:22 AM, Naoto Sato wrote: >>> check not only "C" but also other locales that do not use UTF-8 >>> encoding. >> >> I would like to make the test more robust (per 8008761), though my focus >> at the moment is to avoid a test failure on our automated test systems, >> which all use "C". >> >> I've made a note in 8008761 that we should check for other locales that >> do not use UTF-8. >> >> > Also, "LC_ALL" precedes "LANG" environment variable, so I'd >>> check "LC_ALL" first, and if it is not exported then check "LANG" >>> variable. >> >> Good point - I'll check LC_ALL first. >> >> Updated webrev with re-ordered LC_ALL check (and "LC_ALL=" output >> change) is here: >> http://cr.openjdk.java.net/~bchristi/8006039/webrev.01/ >> >> Thanks, >> -Brent >> >>> On 2/21/13 4:34 PM, Brent Christian wrote: >>>> Hi, >>>> >>>> This test started failing after 8003228 [1] was putback (setting >>>> sun.jnu.encoding to UTF-8 on Mac). It tests if java is able to >>>> launch a >>>> .jar stored in a directory named with two-byte characters. >>>> >>>> The code comments in the test case state that (on Unix) it expects >>>> LC_ALL to be set (to ja_JP.UTF-8/ja_JP.utf8/ja_JP.ujis), though it >>>> also >>>> seems to work with en_US.UTF-8). >>>> >>>> Our automated build+test Macs have LANG=C, so the test has been >>>> "passing" without actually testing the functionality. >>>> >>>> The test case determines if the environment is suitable for testing by >>>> checking if sun.jnu.encoding is either "MS932" or "UTF-8" (on Mac, >>>> this >>>> is now always UTF-8). The test doesn't actually check LC_ALL. >>>> >>>> I think the test should also check the LANG & LC_ALL env vars, and go >>>> back to "fake passing" the test if either is set to 'C'. This would >>>> allow the test to continue to run "for real" in the default Mac >>>> environment (LANG=en_US.UTF-8), and stop the test from failing on the >>>> build+test Macs. >>>> >>>> Of course it would be even better to update the test so the automated >>>> test machines actually test the intended functionality. On UNIX at >>>> least, perhaps it could find something suitable to set LC_ALL to >>>> before >>>> attempting to launch the .jar. I can file a separate bug for this. >>>> >>>> Webrev is here: >>>> http://cr.openjdk.java.net/~bchristi/8006039/webrev.00/ >>>> >>>> Thanks, >>>> -Brent >>>> >>>> [1] >>>> http://bugs.sun.com/view_bug.do?bug_id=8003228 >>> > From brent.christian at oracle.com Mon Feb 25 19:35:50 2013 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 25 Feb 2013 11:35:50 -0800 Subject: RFR: 8006039 : test/tools/launcher/I18NJarTest.java fails on Mac w/ LANG=C, LC_ALL=C In-Reply-To: <512BB6FA.5000609@oracle.com> References: <5126BD1C.8030309@oracle.com> <5127B780.6090800@oracle.com> <512BB330.6070903@oracle.com> <512BB49D.5000201@oracle.com> <512BB6FA.5000609@oracle.com> Message-ID: <512BBD16.3010703@oracle.com> Thanks for the review, guys. Think I've got it all in: http://cr.openjdk.java.net/~bchristi/8006039/webrev.02/ For the Copyright, do I just need to change the year(s) to "2012, 2013,"? Also, thanks a lot for running the Windows testing, Kumar. Can someone push this for me? I can send a patch (or bundle) file... Thanks, -Brent On 2/25/13 11:09 AM, Kumar Srinivasan wrote: > couple of minor nits I did not see in rev 01. > Copyright, > > - if("C".equals(LC_ALL) || "C".equals(LANG)) { > + if ("C".equals(LC_ALL) || "C".equals(LANG)) { > > Kumar > > >> Looks good. Thank you for fixing this. >> >> Naoto >> >> On 2/25/13 10:53 AM, Brent Christian wrote: >>> On 2/22/13 10:22 AM, Naoto Sato wrote: >>>> check not only "C" but also other locales that do not use UTF-8 >>>> encoding. >>> >>> I would like to make the test more robust (per 8008761), though my focus >>> at the moment is to avoid a test failure on our automated test systems, >>> which all use "C". >>> >>> I've made a note in 8008761 that we should check for other locales that >>> do not use UTF-8. >>> >>> > Also, "LC_ALL" precedes "LANG" environment variable, so I'd >>>> check "LC_ALL" first, and if it is not exported then check "LANG" >>>> variable. >>> >>> Good point - I'll check LC_ALL first. >>> >>> Updated webrev with re-ordered LC_ALL check (and "LC_ALL=" output >>> change) is here: >>> http://cr.openjdk.java.net/~bchristi/8006039/webrev.01/ >>> >>> Thanks, >>> -Brent >>> >>>> On 2/21/13 4:34 PM, Brent Christian wrote: >>>>> Hi, >>>>> >>>>> This test started failing after 8003228 [1] was putback (setting >>>>> sun.jnu.encoding to UTF-8 on Mac). It tests if java is able to >>>>> launch a >>>>> .jar stored in a directory named with two-byte characters. >>>>> >>>>> The code comments in the test case state that (on Unix) it expects >>>>> LC_ALL to be set (to ja_JP.UTF-8/ja_JP.utf8/ja_JP.ujis), though it >>>>> also >>>>> seems to work with en_US.UTF-8). >>>>> >>>>> Our automated build+test Macs have LANG=C, so the test has been >>>>> "passing" without actually testing the functionality. >>>>> >>>>> The test case determines if the environment is suitable for testing by >>>>> checking if sun.jnu.encoding is either "MS932" or "UTF-8" (on Mac, >>>>> this >>>>> is now always UTF-8). The test doesn't actually check LC_ALL. >>>>> >>>>> I think the test should also check the LANG & LC_ALL env vars, and go >>>>> back to "fake passing" the test if either is set to 'C'. This would >>>>> allow the test to continue to run "for real" in the default Mac >>>>> environment (LANG=en_US.UTF-8), and stop the test from failing on the >>>>> build+test Macs. >>>>> >>>>> Of course it would be even better to update the test so the automated >>>>> test machines actually test the intended functionality. On UNIX at >>>>> least, perhaps it could find something suitable to set LC_ALL to >>>>> before >>>>> attempting to launch the .jar. I can file a separate bug for this. >>>>> >>>>> Webrev is here: >>>>> http://cr.openjdk.java.net/~bchristi/8006039/webrev.00/ >>>>> >>>>> Thanks, >>>>> -Brent >>>>> >>>>> [1] >>>>> http://bugs.sun.com/view_bug.do?bug_id=8003228 >>>> >> > From kelly.ohair at oracle.com Tue Feb 12 17:52:23 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 12 Feb 2013 09:52:23 -0800 Subject: FAILS: test/sun/management/jdp/JdpTest.sh: test: argument expected In-Reply-To: <511A7DFA.5030101@oracle.com> References: <20130212120441.B8CCD479D2@hg.openjdk.java.net> <511A7DFA.5030101@oracle.com> Message-ID: <6087B5C4-30D3-4CEF-A175-0D93638CC21A@oracle.com> + if [ ! -f ${_testclasses} ] needs to be + if [ ! -d ${_testclasses} ] -kto On Feb 12, 2013, at 9:38 AM, Chris Hegarty wrote: > Dmitry, > > This test is now failing on several platforms, on jdk8 and 7u-dev > > ------- > > result: Passed. Compilation successful > > #section:shell > ----------messages:(3/154)---------- > command: shell JdpTest.sh [--jtreg, --no-compile] > reason: User specified action: run shell JdpTest.sh --jtreg --no-compile > elapsed time (seconds): 0.045 > ----------System.out:(0/0)---------- > ----------System.err:(1/110)---------- > /export2/Users/chris/repos/jdk8/tl/master_top/jdk/test/sun/management/jdp/JdpTest.sh: test: argument expected > result: Failed. Execution failed: exit code 1 > > > test result: Failed. Execution failed: exit code 1 > > -Chris. > > > On 02/12/2013 12:04 PM, dmitry.samersoff at oracle.com wrote: >> Changeset: f7fb173ac833 >> Author: dsamersoff >> Date: 2013-02-12 16:02 +0400 >> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f7fb173ac833 >> >> 8007786: JDK-8002048 testcase doesn't work on Solaris >> Summary: test built in into Solaris shell doesn't have -e operator >> Reviewed-by: sla, sspitsyn >> >> ! test/sun/management/jdp/JdpTest.sh >> From kelly.ohair at oracle.com Wed Feb 13 16:56:06 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 13 Feb 2013 08:56:06 -0800 Subject: FAILS: test/sun/management/jdp/JdpTest.sh: test: argument expected In-Reply-To: <511AC375.2050703@oracle.com> References: <20130212120441.B8CCD479D2@hg.openjdk.java.net> <511A7DFA.5030101@oracle.com> <6087B5C4-30D3-4CEF-A175-0D93638CC21A@oracle.com> <511ABFAB.8030409@oracle.com> <511AC375.2050703@oracle.com> Message-ID: <3FA4C5A9-2E60-4923-8B74-DDB8A8B8C8BD@oracle.com> Bingo. ;^) -kto On Feb 12, 2013, at 2:34 PM, alejandro murillo wrote: > > Dmitry, > you have to use "-testset core" to run this test via JPRT. It's not run on regular jobs. > > > Alejandro > > On 2/12/2013 3:18 PM, Dmitry Samersoff wrote: >> Kelly, >> >> Do you have an idea why I didn't see this failure under jprt? >> >> http://sthjprt.se.oracle.com/archives/2013/02/2013-02-08-192233.dsamerso.tl/ >> >> -Dmitry >> >> >> On 2013-02-12 21:52, Kelly O'Hair wrote: >>> + if [ ! -f ${_testclasses} ] >>> needs to be >>> + if [ ! -d ${_testclasses} ] >>> >>> >>> -kto >>> >>> On Feb 12, 2013, at 9:38 AM, Chris Hegarty wrote: >>> >>>> Dmitry, >>>> >>>> This test is now failing on several platforms, on jdk8 and 7u-dev >>>> >>>> ------- >>>> >>>> result: Passed. Compilation successful >>>> >>>> #section:shell >>>> ----------messages:(3/154)---------- >>>> command: shell JdpTest.sh [--jtreg, --no-compile] >>>> reason: User specified action: run shell JdpTest.sh --jtreg --no-compile >>>> elapsed time (seconds): 0.045 >>>> ----------System.out:(0/0)---------- >>>> ----------System.err:(1/110)---------- >>>> /export2/Users/chris/repos/jdk8/tl/master_top/jdk/test/sun/management/jdp/JdpTest.sh: test: argument expected >>>> result: Failed. Execution failed: exit code 1 >>>> >>>> >>>> test result: Failed. Execution failed: exit code 1 >>>> >>>> -Chris. >>>> >>>> >>>> On 02/12/2013 12:04 PM, dmitry.samersoff at oracle.com wrote: >>>>> Changeset: f7fb173ac833 >>>>> Author: dsamersoff >>>>> Date: 2013-02-12 16:02 +0400 >>>>> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f7fb173ac833 >>>>> >>>>> 8007786: JDK-8002048 testcase doesn't work on Solaris >>>>> Summary: test built in into Solaris shell doesn't have -e operator >>>>> Reviewed-by: sla, sspitsyn >>>>> >>>>> ! test/sun/management/jdp/JdpTest.sh >>>>> >> > From yong.huang at oracle.com Sun Feb 17 09:17:51 2013 From: yong.huang at oracle.com (yong.huang at oracle.com) Date: Sun, 17 Feb 2013 09:17:51 +0000 Subject: hg: jdk8/tl/jdk: 8006748: getISO3Country() returns wrong value Message-ID: <20130217091812.2B8DC47B3B@hg.openjdk.java.net> Changeset: ce6a2fcb4c9b Author: yhuang Date: 2013-02-16 21:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ce6a2fcb4c9b 8006748: getISO3Country() returns wrong value Reviewed-by: naoto ! src/share/classes/java/util/LocaleISOData.java From vladimir.danushevsky at oracle.com Thu Feb 21 22:02:08 2013 From: vladimir.danushevsky at oracle.com (Vladimir Danushevsky) Date: Thu, 21 Feb 2013 17:02:08 -0500 Subject: RFR: 8005545: Add System property to identify ARCH specific details such as ARM hard-float binaries Message-ID: <899E92AE-F8A0-4873-B8DC-EE642B615840@oracle.com> Please review changes for https://jbs.oracle.com/bugs/browse/JDK-8005545 "Add System property to identify ARCH specific details such as ARM hard-float binaries" which adds an optional sun.os.abi Java system property indicating an ABI type being used by the JVM: CCC Reguest: http://ccc.us.oracle.com/8005545 Webrev: http://cr.openjdk.java.net/~vladidan/8005545/webrev.00/ Separate change to the build script (e.g. in ARM Hard-Float ABI case): setenv ARCHABIPROPNAME gnueabihf -DARCHABIPROPNAME="\"$(ARCHABIPROPNAME)\"" is passed to the CFLAGS Thanks, Vlad From stefan.karlsson at oracle.com Fri Feb 22 12:19:56 2013 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Fri, 22 Feb 2013 12:19:56 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130222122134.917BF47C71@hg.openjdk.java.net> Changeset: c6d77b2b4478 Author: stefank Date: 2013-01-22 13:53 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c6d77b2b4478 8006506: Add test for redefining methods in backtraces to java/lang/instrument tests Reviewed-by: sspitsyn, coleenp + test/java/lang/instrument/RedefineMethodInBacktrace.sh + test/java/lang/instrument/RedefineMethodInBacktraceAgent.java + test/java/lang/instrument/RedefineMethodInBacktraceApp.java + test/java/lang/instrument/RedefineMethodInBacktraceTarget.java + test/java/lang/instrument/RedefineMethodInBacktraceTarget_2.java Changeset: 0e93015e77f6 Author: stefank Date: 2013-01-22 15:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0e93015e77f6 7140852: Add test for 7022100 Reviewed-by: sspitsyn, coleenp + test/java/lang/instrument/RedefineMethodWithAnnotations.sh + test/java/lang/instrument/RedefineMethodWithAnnotationsAgent.java + test/java/lang/instrument/RedefineMethodWithAnnotationsAnnotations.java + test/java/lang/instrument/RedefineMethodWithAnnotationsApp.java + test/java/lang/instrument/RedefineMethodWithAnnotationsTarget.java + test/java/lang/instrument/RedefineMethodWithAnnotationsTarget_2.java From vladimir.danushevsky at oracle.com Fri Feb 22 21:33:39 2013 From: vladimir.danushevsky at oracle.com (Vladimir Danushevsky) Date: Fri, 22 Feb 2013 16:33:39 -0500 Subject: RFR: 8005545: Add System property to identify ARCH specific details such as ARM hard-float binaries In-Reply-To: <51274F10.6020208@oracle.com> References: <899E92AE-F8A0-4873-B8DC-EE642B615840@oracle.com> <51274F10.6020208@oracle.com> Message-ID: <5D7CCEEA-EA5A-4D7C-833A-EB045ACF1AA9@oracle.com> Thanks, webrev updated http://cr.openjdk.java.net/~vladidan/8005545/webrev.01/ On Feb 22, 2013, at 5:57 AM, Alan Bateman wrote: > On 21/02/2013 22:02, Vladimir Danushevsky wrote: >> : >> >> Webrev: >> http://cr.openjdk.java.net/~vladidan/8005545/webrev.00/ >> >> Separate change to the build script (e.g. in ARM Hard-Float ABI case): >> setenv ARCHABIPROPNAME gnueabihf >> -DARCHABIPROPNAME="\"$(ARCHABIPROPNAME)\"" is passed to the CFLAGS >> > I agree with Bob on the naming, otherwise it looks okay to me. > > On the release file and Images.gmk then jdk/tl was sync'ed up yesterday so you will probably need to re-base the patch. > > -Alan From kelly.ohair at oracle.com Mon Feb 25 17:18:45 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 25 Feb 2013 09:18:45 -0800 Subject: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so In-Reply-To: <51292295.4040802@oracle.com> References: <5128AD43.2000809@oracle.com> <51292295.4040802@oracle.com> Message-ID: On Feb 23, 2013, at 12:12 PM, Alan Bateman wrote: > On 23/02/2013 18:06, Martin Buchholz wrote: >> I am actually encountering this in openjdk7 with the old build system. >> I can repro the problem in openjdk8 with the old build system, but not the new one. >> >> I don't know if you consider this a bug with the new build system - it's supposed to generate the same bits, after all???!! >> I'm not sure why - I'd guess something to do with VARIANT or FILES_m >> >> It's highly dubious whether we should have this extremely subtle and error-prone distinction between release and fastdebug builds at all. > Thanks for confirming it's old build only, that was my reading too but without checking. > > Anyway, I do consider it a bug (in the old build), and really hard to track down too until you see both libz and the JDK's libzip loaded. Kelly might have some insight the product vs. fastdebug difference. I have filed many issues over the years asking that mapfiles (or version scripts) be used to limit the visibility of extern symbols in Solaris and Linux. Most developers fail to understand the importance of this. I have also always wanted the fastdebug libraries and even debug build libraries to be 'plug&play' so that they exported the exact same externs and same prototypes, and could be plopped into a product build to isolate problems in just one single library. Unfortunately, some teams have added additional externs to the debug versions and that would imply the need for a different mapfile, so I suspect the easy path was to just not use a mapfile with the debug builds. It is rare that this is an issue, but obviously this is a case where it was. The policy should be that ALL shared libraries be scoped and only expose the extern symbols needed. However, with the old builds being this way all along, I see no need to go into the old builds to fix this. We have so much work to do as it is. -kto > > -Alan From mike.duigou at oracle.com Mon Feb 25 20:24:01 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 25 Feb 2013 12:24:01 -0800 Subject: hg: jdk8/tl/jdk: 8008167: IdentityHashMap.[keySet|values|entrySet].toArray speed-up In-Reply-To: <512B340B.9020803@oracle.com> References: <20130214175538.236EC47A96@hg.openjdk.java.net> <512A149D.3030204@oracle.com> <512A3689.3000900@gmail.com> <512A609A.10002@oracle.com> <03FC4A5C-AF4D-45A2-908C-CFAC0AEA562B@oracle.com> <512A77C3.9070902@gmail.com> <512B340B.9020803@oracle.com> Message-ID: I made one additional change to the regression test so that the keys and values aren't in the same range. It didn't produce any failures but I think it is a good addition to catch future bugs. Mike diff --git a/test/java/util/Map/ToArray.java b/test/java/util/Map/ToArray.java --- a/test/java/util/Map/ToArray.java +++ b/test/java/util/Map/ToArray.java @@ -67,7 +67,7 @@ public class ToArray { static { for (int each = 0; each < TEST_SIZE; each++) { KEYS[each] = Integer.valueOf(each); - VALUES[each] = Long.valueOf(each); + VALUES[each] = Long.valueOf(each + TEST_SIZE); } } On Feb 25 2013, at 01:51 , Alan Bateman wrote: > On 25/02/2013 04:06, Mike Duigou wrote: >> I have created an issue for fixing the introduced regression and created a regression test that would have caught the error (fix a bug, write a test...). >> >> 8008785: IdentityHashMap.values().toArray(V[]) broken by JDK-8008167 >> >> http://cr.openjdk.java.net/~mduigou/JDK-8008785/0/webrev >> >> Mike > The fix to IdentityHashMap looks good. It is surprising that it wasn't caught by tests in the jdk repository so a reminder that we always need to check that we have good test coverage when doing performance fixes. > > The webrev suggests you've replaced Map/Collisions.java and assume that is not the intention. Otherwise the new test looks okay, an alternative would have been to expand MOAT. > > -Alan. From brian.burkhalter at oracle.com Mon Feb 25 20:50:05 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 25 Feb 2013 12:50:05 -0800 Subject: [PATCH] Sunbug 7131192: Optimize BigInteger.doubleValue(), floatValue() In-Reply-To: References: <511ED22B.8030800@oracle.com> <2867C9E8-F8FB-405A-8D00-7D4F90CA9628@oracle.com> <692B4DC6-88F3-4740-9B06-BDE56BB7B8B5@oracle.com> <370E52AA-385B-4117-B18E-71699243782F@oracle.com> Message-ID: <4A336C49-B0CD-443E-B771-1DD886F15BF4@oracle.com> Hi Dima, On Feb 25, 2013, at 1:14 AM, Dmitry Nadezhin wrote: > I looked at your fix of sunbug=6358355 "Fix Float.parseFloat to round > correctly and preserve monotonicity". > [?] > 1) The line in floatValue() method > fValue = (float) doubleValue(); > > fValue can become Float.POSITIVE_INFINITY. > It causes incorrect result on input like this > [?] > It can be fixed in such a way > fValue = Math.max(Float.MIN_VALUE, Math.min(Float.MAX_VALUE, (float) > doubleValue())); Thanks for the catch! > 2) The line in floatValue() method. > // difference is exactly half an ULP > // round to some other value maybe, then finish > fValue += 0.5f*ulp( fValue, overvalue ); > > When fValue is subnormal, the right-hand sign evaluates to 0, fValue > remains unchanged. > This is similar to the bug 4396272 - Parsing doubles fails to follow > IEEE for largest decimal that should yield 0. > [?] > > It can be fixed in such a way > fValue = (float) (fValue + 0.5*ulp(fValue, overvalue)); > Constant 0.5 instead of 0.5f causes double evaluation of right-hand > side, so it doesn'nt underflow. I was intending to comment on this as well. Once approved, I was thinking that the patch for 7192954 "Fix Float.parseFloat to round correctly and preserve monotonicity" should be applied first followed by patches for 4396272 "Parsing doubles fails to follow IEEE for largest decimal that should yield 0" and "BigInteger.doubleValue() is depressingly slow." I initiated some of these reviews out of this sequence as I had not become aware of all the linkages. I am actually also wondering whether the patch for 7032154 "Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal," which I just learned of today, should perhaps be dealt with prior to any of the above? Thanks, Brian From lowasser at google.com Mon Feb 25 20:53:53 2013 From: lowasser at google.com (Louis Wasserman) Date: Mon, 25 Feb 2013 12:53:53 -0800 Subject: [PATCH] Sunbug 7131192: Optimize BigInteger.doubleValue(), floatValue() In-Reply-To: <4A336C49-B0CD-443E-B771-1DD886F15BF4@oracle.com> References: <511ED22B.8030800@oracle.com> <2867C9E8-F8FB-405A-8D00-7D4F90CA9628@oracle.com> <692B4DC6-88F3-4740-9B06-BDE56BB7B8B5@oracle.com> <370E52AA-385B-4117-B18E-71699243782F@oracle.com> <4A336C49-B0CD-443E-B771-1DD886F15BF4@oracle.com> Message-ID: In general, the only thing I did was to mirror the double parsing logic as closely as I could manage. If that logic is going to change, then so too should the patch. There's really no reason to preserve the specific code I added in that patch. On Mon, Feb 25, 2013 at 12:50 PM, Brian Burkhalter < brian.burkhalter at oracle.com> wrote: > Hi Dima, > > On Feb 25, 2013, at 1:14 AM, Dmitry Nadezhin wrote: > > I looked at your fix of sunbug=6358355 "Fix Float.parseFloat to round > correctly and preserve monotonicity". > [?] > > 1) The line in floatValue() method > fValue = (float) doubleValue(); > > fValue can become Float.POSITIVE_INFINITY. > It causes incorrect result on input like this > [?] > > It can be fixed in such a way > fValue = Math.max(Float.MIN_VALUE, Math.min(Float.MAX_VALUE, (float) > doubleValue())); > > > Thanks for the catch! > > 2) The line in floatValue() method. > // difference is exactly half an ULP > // round to some other value maybe, then finish > fValue += 0.5f*ulp( fValue, overvalue ); > > When fValue is subnormal, the right-hand sign evaluates to 0, fValue > remains unchanged. > This is similar to the bug 4396272 - Parsing doubles fails to follow > IEEE for largest decimal that should yield 0. > [?] > > > It can be fixed in such a way > fValue = (float) (fValue + 0.5*ulp(fValue, overvalue)); > Constant 0.5 instead of 0.5f causes double evaluation of right-hand > side, so it doesn'nt underflow. > > > I was intending to comment on this as well. > > Once approved, I was thinking that the patch for 7192954 "Fix > Float.parseFloat to round correctly and preserve monotonicity" should be > applied first followed by patches for 4396272 "Parsing doubles fails to > follow IEEE for largest decimal that should yield 0" > and "BigInteger.doubleValue() is depressingly slow." I initiated some of > these reviews out of this sequence as I had not become aware of all the > linkages. > > I am actually also wondering whether the patch for 7032154 "Performance > tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal," which I just > learned of today, should perhaps be dealt with prior to any of the above? > > Thanks, > > Brian > -- Louis Wasserman From martinrb at google.com Mon Feb 25 21:27:30 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 25 Feb 2013 13:27:30 -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> Message-ID: Kelly, Thanks. I think we agree. I think we have consensus that my change is an improvement and should be committed. Can I haz approval? I'm not brave enough to try to change the default for all mapfiles, although I would support Kelly or anyone else who tries. Martin On Mon, Feb 25, 2013 at 9:18 AM, Kelly O'Hair wrote: > > On Feb 23, 2013, at 12:12 PM, Alan Bateman wrote: > > > On 23/02/2013 18:06, Martin Buchholz wrote: > >> I am actually encountering this in openjdk7 with the old build system. > >> I can repro the problem in openjdk8 with the old build system, but not > the new one. > >> > >> I don't know if you consider this a bug with the new build system - > it's supposed to generate the same bits, after all???!! > >> I'm not sure why - I'd guess something to do with VARIANT or FILES_m > >> > >> It's highly dubious whether we should have this extremely subtle and > error-prone distinction between release and fastdebug builds at all. > > Thanks for confirming it's old build only, that was my reading too but > without checking. > > > > Anyway, I do consider it a bug (in the old build), and really hard to > track down too until you see both libz and the JDK's libzip loaded. Kelly > might have some insight the product vs. fastdebug difference. > > I have filed many issues over the years asking that mapfiles (or version > scripts) be used to limit the > visibility of extern symbols in Solaris and Linux. Most developers fail to > understand the importance of this. > > I have also always wanted the fastdebug libraries and even debug build > libraries to be 'plug&play' so that they > exported the exact same externs and same prototypes, and could be plopped > into a product build to isolate problems > in just one single library. Unfortunately, some teams have added > additional externs > to the debug versions and that would imply the need for a different > mapfile, so I suspect the easy path was to just > not use a mapfile with the debug builds. It is rare that this is an issue, > but obviously this is a case where it was. > > The policy should be that ALL shared libraries be scoped and only expose > the extern symbols needed. > > However, with the old builds being this way all along, I see no need to go > into the old builds to fix this. > We have so much work to do as it is. > > -kto > > > > > -Alan > > From david.holmes at oracle.com Mon Feb 25 21:45:47 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Feb 2013 07:45:47 +1000 Subject: Code review request In-Reply-To: <458B2D62-336C-429C-B835-DEEC7031004B@oracle.com> References: <512672E6.1050708@oracle.com> <51289F3D.1010609@univ-mlv.fr> <458B2D62-336C-429C-B835-DEEC7031004B@oracle.com> Message-ID: <512BDB8B.9070005@oracle.com> On 26/02/2013 3:31 AM, Paul Sandoz wrote: > Hi Remi, > > Thanks for the feedback i have addressed some of this, mostly related to > inner classes, in following change set to the lambda repo: > > http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3e50294c68ea I see a lot of private things that are now package-access. Is that because they are now being used within the package? The access modifiers document intended usage even if there is limited accessibility to the class defining the member. The idea that a class restricted to package-access should have member access modifiers restricted to package-only or else private, is just plain wrong in my view. Each type should have a public, protected and private API. The exposure of the type within a package is a separate matter. Package-access then becomes a limited-sharing mechanism. David > We can update the webrev next week. > > > On Feb 23, 2013, at 11:51 AM, Remi Forax > wrote: > >> On 02/21/2013 08:17 PM, Brian Goetz wrote: >>> At >>> http://cr.openjdk.java.net/~briangoetz/jdk-8008670/webrev/ >>> >>> I've posted a webrev for about half the classes in java.util.stream. >>> None of these are public classes, so there are no public API issues >>> here, but plenty of internal API issues, naming issues (ooh, a >>> bikeshed), and code quality issues. >>> >> >> Hi Brian, >> >> All protected fields should not be protected but package visible. >> Classes are package private so there is no need to use a modifier >> which offer a wider visibility. >> The same is true for constructors. >> > > I agree with this, if there are no further objections i will fix in the > lambda repo towards the end of the week. > > >> For default method, some of them are marked public, some of them are not, >> what the coding convention said ? >> > > AFAICT "public" was only on two such default methods, so i have removed > that modifier. > > >> Code convention again, there is a lot of if/else with no curly braces, >> or only curly braces >> on the if part but not on the else part. >> Also, when a if block ends with a return, there is no need to use 'else', >> >> if (result != null) { >> foundResult(result); >> return result; >> } >> else >> return null; >> >> can be simply written: >> >> if (result != null) { >> foundResult(result); >> return result; >> } >> return null; >> > > Regarding code conventions i would prefer to auto-format all code to > ensure consistency, as to what that consistency is, well we could argue > until heat death of the universe :-) I am fine as long as it is > consistent and easy to hit Alt-Cmd-L or what ever it is in ones > favourite IDE. > > >> >> All inner class should not have private constructors, like by example >> FindOp.FindTask, because >> the compiler will have to generate a special accessor for them when >> they are called from >> the outer class. >> > > I have made changes to all inner classes to conform to this. I have also > marked all classes as final where appropriate. > > >> In AbstractShortCircuitTask: >> It's not clear that cancel and sharedResult can be accessed directly >> given that they both have methods that acts as getter and setter. >> If they can be accessed directly, I think it's better to declare them >> private and to use getters. >> > > They should be private, they are not accessed outside of that class. I > will fix. > > >> Depending on the ops, some of them do nullcheks of arguments at >> creating time (ForEachOp) , some of them don't (FindOp). >> In ForEachUntilOp, the 'consumer' is checked but 'until' is not. >> > > OK, there are probably lots of missing null checks in the code... > > >> in ForEachOp, most of the keyword protected are not needed, >> ForEachUntilOp which inherits from ForEachOp is in the same package. >> > > >> In ForEachUntilOp, the constructor should be private (like for all the >> other ops). >> > > Done. > > >> In MatchOp, line 110, I think the compiler bug is fixed now ? > > Not yet, i can still reproduce it. > > >> The enum MatchKind should not be public and all constructor of all >> inner classes should not be private. >> > > Done. > > >> In OpsUtils, some static methods are public and some are not, >> > > OpUtils is now gone in the lambda repo. The forEach and reduce > functionality is moved into the corresponding op classes. The static > method has been moved to a default method on PipelineHelper. > > >> in Tripwire: >> enabled should be in uppercase (ENABLED). >> method trip() should be: >> public static void trip(Class trippingClass, String msg) >> > > Done. I also made the field and method package private. > > Thanks, > Paul. > From brian.burkhalter at oracle.com Mon Feb 25 21:47:23 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 25 Feb 2013 13:47:23 -0800 Subject: [PATCH] Sunbug 7131192: Optimize BigInteger.doubleValue(), floatValue() In-Reply-To: References: <511ED22B.8030800@oracle.com> <2867C9E8-F8FB-405A-8D00-7D4F90CA9628@oracle.com> <692B4DC6-88F3-4740-9B06-BDE56BB7B8B5@oracle.com> <370E52AA-385B-4117-B18E-71699243782F@oracle.com> <4A336C49-B0CD-443E-B771-1DD886F15BF4@oracle.com> Message-ID: <872314C2-C9D3-41CB-A878-1D840BFB16A5@oracle.com> Understood. Thanks, Brian On Feb 25, 2013, at 12:53 PM, Louis Wasserman wrote: > In general, the only thing I did was to mirror the double parsing logic as closely as I could manage. If that logic is going to change, then so too should the patch. There's really no reason to preserve the specific code I added in that patch. From chris.hegarty at oracle.com Mon Feb 25 21:46:59 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 25 Feb 2013 21:46:59 +0000 Subject: 8006409: ThreadLocalRandom should dropping padding fields from its serialized form In-Reply-To: <5124DA0E.60507@oracle.com> References: <50EF4143.4090008@oracle.com> <50F408CF.6060207@oracle.com> <50F40D95.9050402@oracle.com> <50F44C72.60707@oracle.com> <50F483E7.6080504@oracle.com> <50F487CE.6010101@oracle.com> <50F48C5A.4040500@oracle.com> <8E0C1F8A-DF46-457C-81DB-0BC41FC5F2D5@oracle.com> <50F49B06.9070202@cs.oswego.edu> <50F50E1E.5040604@javaspecialists.eu> <50F558D7.5040509@cs.oswego.edu> <50F55B8F.40502@oracle.com> <50F55E7C.8040809@oracle.com> <50F56062.5070404@oracle.com> <50F584DD.6080108@oracle.com> <50F66BE4.3050305@gmail.com> <50F693A2.8030000@cs.oswego.edu> <50F6C0E4.2090401@oracle.com> <5124B086.60006@oracle.com> <5124DA0E.60507@oracle.com> Message-ID: <512BDBD3.5040403@oracle.com> [ Subject: 8006409: ThreadLocalRandom should drop padding fields from its serialized form (was: Re: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread) ] I think we are in agreement that the pad fields can safely be removed from the serial form. No problem. To remain compatible with the TLR implementation in jdk7, and to have a reconstituted TLR behave reasonably, we need to continue to write a sensible value for rnd. http://cr.openjdk.java.net/~chegar/8006409/webrev.00/webrev/ If I can get agreement on this simple change, I'll finalize the "spec" change, with respect to the serial form of TLR, and hopefully we can put this one to bed. -Chris. From dl at cs.oswego.edu Mon Feb 25 21:49:23 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Mon, 25 Feb 2013 16:49:23 -0500 Subject: 8006409: ThreadLocalRandom should dropping padding fields from its serialized form In-Reply-To: <512BDBD3.5040403@oracle.com> References: <50EF4143.4090008@oracle.com> <50F408CF.6060207@oracle.com> <50F40D95.9050402@oracle.com> <50F44C72.60707@oracle.com> <50F483E7.6080504@oracle.com> <50F487CE.6010101@oracle.com> <50F48C5A.4040500@oracle.com> <8E0C1F8A-DF46-457C-81DB-0BC41FC5F2D5@oracle.com> <50F49B06.9070202@cs.oswego.edu> <50F50E1E.5040604@javaspecialists.eu> <50F558D7.5040509@cs.oswego.edu> <50F55B8F.40502@oracle.com> <50F55E7C.8040809@oracle.com> <50F56062.5070404@oracle.com> <50F584DD.6080108@oracle.com> <50F66BE4.3050305@gmail.com> <50F693A2.8030000@cs.oswego.edu> <50F6C0E4.2090401@oracle.com> <5124B086.60006@oracle.com> <5124DA0E.60507@oracle.com> <512BDBD3.5040403@oracle.com> Message-ID: <512BDC63.5080505@cs.oswego.edu> On 02/25/13 16:46, Chris Hegarty wrote: > [ Subject: 8006409: ThreadLocalRandom should drop padding fields > from its serialized form (was: Re: RFR (S): CR 8005926: (thread) > Merge ThreadLocalRandom state into java.lang.Thread) ] > > I think we are in agreement that the pad fields can safely be removed from the > serial form. No problem. To remain compatible with the TLR implementation in > jdk7, and to have a reconstituted TLR behave reasonably, we need to continue to > write a sensible value for rnd. > > http://cr.openjdk.java.net/~chegar/8006409/webrev.00/webrev/ > > If I can get agreement on this simple change, I'll finalize the "spec" change, > with respect to the serial form of TLR, and hopefully we can put this one to bed. > Yes please! -Doug From Alan.Bateman at oracle.com Mon Feb 25 21:58:11 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 25 Feb 2013 21:58:11 +0000 Subject: 8006409: ThreadLocalRandom should dropping padding fields from its serialized form In-Reply-To: <512BDBD3.5040403@oracle.com> References: <50EF4143.4090008@oracle.com> <50F408CF.6060207@oracle.com> <50F40D95.9050402@oracle.com> <50F44C72.60707@oracle.com> <50F483E7.6080504@oracle.com> <50F487CE.6010101@oracle.com> <50F48C5A.4040500@oracle.com> <8E0C1F8A-DF46-457C-81DB-0BC41FC5F2D5@oracle.com> <50F49B06.9070202@cs.oswego.edu> <50F50E1E.5040604@javaspecialists.eu> <50F558D7.5040509@cs.oswego.edu> <50F55B8F.40502@oracle.com> <50F55E7C.8040809@oracle.com> <50F56062.5070404@oracle.com> <50F584DD.6080108@oracle.com> <50F66BE4.3050305@gmail.com> <50F693A2.8030000@cs.oswego.edu> <50F6C0E4.2090401@oracle.com> <5124B086.60006@oracle.com> <5124DA0E.60507@oracle.com> <512BDBD3.5040403@oracle.com> Message-ID: <512BDE73.10907@oracle.com> On 25/02/2013 21:46, Chris Hegarty wrote: > [ Subject: 8006409: ThreadLocalRandom should drop padding fields > from its serialized form (was: Re: RFR (S): CR 8005926: (thread) > Merge ThreadLocalRandom state into java.lang.Thread) ] > > I think we are in agreement that the pad fields can safely be removed > from the serial form. No problem. To remain compatible with the TLR > implementation in jdk7, and to have a reconstituted TLR behave > reasonably, we need to continue to write a sensible value for rnd. > > http://cr.openjdk.java.net/~chegar/8006409/webrev.00/webrev/ > > If I can get agreement on this simple change, I'll finalize the "spec" > change, with respect to the serial form of TLR, and hopefully we can > put this one to bed. > > -Chris. This looks good to me too. -Alan From kumar.x.srinivasan at oracle.com Mon Feb 25 22:00:48 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 25 Feb 2013 14:00:48 -0800 Subject: RFR: 8006039 : test/tools/launcher/I18NJarTest.java fails on Mac w/ LANG=C, LC_ALL=C In-Reply-To: <512BBD16.3010703@oracle.com> References: <5126BD1C.8030309@oracle.com> <5127B780.6090800@oracle.com> <512BB330.6070903@oracle.com> <512BB49D.5000201@oracle.com> <512BB6FA.5000609@oracle.com> <512BBD16.3010703@oracle.com> Message-ID: <512BDF10.7030908@oracle.com> I can take care of it. Kumar > Thanks for the review, guys. > > Think I've got it all in: > http://cr.openjdk.java.net/~bchristi/8006039/webrev.02/ > > For the Copyright, do I just need to change the year(s) to "2012, 2013,"? > > Also, thanks a lot for running the Windows testing, Kumar. > > > Can someone push this for me? I can send a patch (or bundle) file... > > Thanks, > -Brent > > On 2/25/13 11:09 AM, Kumar Srinivasan wrote: >> couple of minor nits I did not see in rev 01. >> Copyright, >> >> - if("C".equals(LC_ALL) || "C".equals(LANG)) { >> + if ("C".equals(LC_ALL) || "C".equals(LANG)) { >> >> Kumar >> >> >>> Looks good. Thank you for fixing this. >>> >>> Naoto >>> >>> On 2/25/13 10:53 AM, Brent Christian wrote: >>>> On 2/22/13 10:22 AM, Naoto Sato wrote: >>>>> check not only "C" but also other locales that do not use UTF-8 >>>>> encoding. >>>> >>>> I would like to make the test more robust (per 8008761), though my >>>> focus >>>> at the moment is to avoid a test failure on our automated test >>>> systems, >>>> which all use "C". >>>> >>>> I've made a note in 8008761 that we should check for other locales >>>> that >>>> do not use UTF-8. >>>> >>>> > Also, "LC_ALL" precedes "LANG" environment variable, so I'd >>>>> check "LC_ALL" first, and if it is not exported then check "LANG" >>>>> variable. >>>> >>>> Good point - I'll check LC_ALL first. >>>> >>>> Updated webrev with re-ordered LC_ALL check (and "LC_ALL=" output >>>> change) is here: >>>> http://cr.openjdk.java.net/~bchristi/8006039/webrev.01/ >>>> >>>> Thanks, >>>> -Brent >>>> >>>>> On 2/21/13 4:34 PM, Brent Christian wrote: >>>>>> Hi, >>>>>> >>>>>> This test started failing after 8003228 [1] was putback (setting >>>>>> sun.jnu.encoding to UTF-8 on Mac). It tests if java is able to >>>>>> launch a >>>>>> .jar stored in a directory named with two-byte characters. >>>>>> >>>>>> The code comments in the test case state that (on Unix) it expects >>>>>> LC_ALL to be set (to ja_JP.UTF-8/ja_JP.utf8/ja_JP.ujis), though it >>>>>> also >>>>>> seems to work with en_US.UTF-8). >>>>>> >>>>>> Our automated build+test Macs have LANG=C, so the test has been >>>>>> "passing" without actually testing the functionality. >>>>>> >>>>>> The test case determines if the environment is suitable for >>>>>> testing by >>>>>> checking if sun.jnu.encoding is either "MS932" or "UTF-8" (on Mac, >>>>>> this >>>>>> is now always UTF-8). The test doesn't actually check LC_ALL. >>>>>> >>>>>> I think the test should also check the LANG & LC_ALL env vars, >>>>>> and go >>>>>> back to "fake passing" the test if either is set to 'C'. This would >>>>>> allow the test to continue to run "for real" in the default Mac >>>>>> environment (LANG=en_US.UTF-8), and stop the test from failing on >>>>>> the >>>>>> build+test Macs. >>>>>> >>>>>> Of course it would be even better to update the test so the >>>>>> automated >>>>>> test machines actually test the intended functionality. On UNIX at >>>>>> least, perhaps it could find something suitable to set LC_ALL to >>>>>> before >>>>>> attempting to launch the .jar. I can file a separate bug for this. >>>>>> >>>>>> Webrev is here: >>>>>> http://cr.openjdk.java.net/~bchristi/8006039/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> -Brent >>>>>> >>>>>> [1] >>>>>> http://bugs.sun.com/view_bug.do?bug_id=8003228 >>>>> >>> >> From Alan.Bateman at oracle.com Mon Feb 25 22:01:54 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 25 Feb 2013 22:01:54 +0000 Subject: hg: jdk8/tl/jdk: 8008167: IdentityHashMap.[keySet|values|entrySet].toArray speed-up In-Reply-To: References: <20130214175538.236EC47A96@hg.openjdk.java.net> <512A149D.3030204@oracle.com> <512A3689.3000900@gmail.com> <512A609A.10002@oracle.com> <03FC4A5C-AF4D-45A2-908C-CFAC0AEA562B@oracle.com> <512A77C3.9070902@gmail.com> <512B340B.9020803@oracle.com> Message-ID: <512BDF52.9080903@oracle.com> On 25/02/2013 20:24, Mike Duigou wrote: > I made one additional change to the regression test so that the keys and values aren't in the same range. It didn't produce any failures but I think it is a good addition to catch future bugs. > > Mike > Looks okay. -Alan From aleksey.shipilev at oracle.com Mon Feb 25 22:03:05 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 26 Feb 2013 02:03:05 +0400 Subject: 8006409: ThreadLocalRandom should dropping padding fields from its serialized form In-Reply-To: <512BDBD3.5040403@oracle.com> References: <50EF4143.4090008@oracle.com> <50F408CF.6060207@oracle.com> <50F40D95.9050402@oracle.com> <50F44C72.60707@oracle.com> <50F483E7.6080504@oracle.com> <50F487CE.6010101@oracle.com> <50F48C5A.4040500@oracle.com> <8E0C1F8A-DF46-457C-81DB-0BC41FC5F2D5@oracle.com> <50F49B06.9070202@cs.oswego.edu> <50F50E1E.5040604@javaspecialists.eu> <50F558D7.5040509@cs.oswego.edu> <50F55B8F.40502@oracle.com> <50F55E7C.8040809@oracle.com> <50F56062.5070404@oracle.com> <50F584DD.6080108@oracle.com> <50F66BE4.3050305@gmail.com> <50F693A2.8030000@cs.oswego.edu> <50F6C0E4.2090401@oracle.com> <5124B086.60006@oracle.com> <5124DA0E.60507@oracle.com> <512BDBD3.5040403@oracle.com> Message-ID: <512BDF99.4070405@oracle.com> On 02/26/2013 01:46 AM, Chris Hegarty wrote: > [ Subject: 8006409: ThreadLocalRandom should drop padding fields > from its serialized form (was: Re: RFR (S): CR 8005926: (thread) > Merge ThreadLocalRandom state into java.lang.Thread) ] > > I think we are in agreement that the pad fields can safely be removed > from the serial form. No problem. To remain compatible with the TLR > implementation in jdk7, and to have a reconstituted TLR behave > reasonably, we need to continue to write a sensible value for rnd. > > http://cr.openjdk.java.net/~chegar/8006409/webrev.00/webrev/ > > If I can get agreement on this simple change, I'll finalize the "spec" > change, with respect to the serial form of TLR, and hopefully we can put > this one to bed. Good for me. -Aleksey. From martinrb at google.com Mon Feb 25 22:13:48 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 25 Feb 2013 14:13:48 -0800 Subject: 8006409: ThreadLocalRandom should dropping padding fields from its serialized form In-Reply-To: <512BDF99.4070405@oracle.com> References: <50EF4143.4090008@oracle.com> <50F408CF.6060207@oracle.com> <50F40D95.9050402@oracle.com> <50F44C72.60707@oracle.com> <50F483E7.6080504@oracle.com> <50F487CE.6010101@oracle.com> <50F48C5A.4040500@oracle.com> <8E0C1F8A-DF46-457C-81DB-0BC41FC5F2D5@oracle.com> <50F49B06.9070202@cs.oswego.edu> <50F50E1E.5040604@javaspecialists.eu> <50F558D7.5040509@cs.oswego.edu> <50F55B8F.40502@oracle.com> <50F55E7C.8040809@oracle.com> <50F56062.5070404@oracle.com> <50F584DD.6080108@oracle.com> <50F66BE4.3050305@gmail.com> <50F693A2.8030000@cs.oswego.edu> <50F6C0E4.2090401@oracle.com> <5124B086.60006@oracle.com> <5124DA0E.60507@oracle.com> <512BDBD3.5040403@oracle.com> <512BDF99.4070405@oracle.com> Message-ID: Me too! From martinrb at google.com Mon Feb 25 22:25:52 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 25 Feb 2013 14:25:52 -0800 Subject: 8006409: ThreadLocalRandom should dropping padding fields from its serialized form In-Reply-To: References: <50EF4143.4090008@oracle.com> <50F408CF.6060207@oracle.com> <50F40D95.9050402@oracle.com> <50F44C72.60707@oracle.com> <50F483E7.6080504@oracle.com> <50F487CE.6010101@oracle.com> <50F48C5A.4040500@oracle.com> <8E0C1F8A-DF46-457C-81DB-0BC41FC5F2D5@oracle.com> <50F49B06.9070202@cs.oswego.edu> <50F50E1E.5040604@javaspecialists.eu> <50F558D7.5040509@cs.oswego.edu> <50F55B8F.40502@oracle.com> <50F55E7C.8040809@oracle.com> <50F56062.5070404@oracle.com> <50F584DD.6080108@oracle.com> <50F66BE4.3050305@gmail.com> <50F693A2.8030000@cs.oswego.edu> <50F6C0E4.2090401@oracle.com> <5124B086.60006@oracle.com> <5124DA0E.60507@oracle.com> <512BDBD3.5040403@oracle.com> <512BDF99.4070405@oracle.com> Message-ID: Perhaps slightly better is this variant, which adds doc for the @serialField's. /** * @serialField rnd long * seed for random computations * @serialField initialized boolean * always true */ private static final ObjectStreamField[] serialPersistentFields = { new ObjectStreamField("rnd", long.class), new ObjectStreamField("initialized", boolean.class), }; /** * Saves the {@code ThreadLocalRandom} to a stream (that is, serializes it). */ private void writeObject(java.io.ObjectOutputStream out) throws java.io.IOException { java.io.ObjectOutputStream.PutField fields = out.putFields(); fields.put("rnd", UNSAFE.getLong(Thread.currentThread(), SEED)); fields.put("initialized", true); out.writeFields(); } On Mon, Feb 25, 2013 at 2:13 PM, Martin Buchholz wrote: > Me too! > > From kumar.x.srinivasan at oracle.com Mon Feb 25 22:40:28 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Mon, 25 Feb 2013 22:40:28 +0000 Subject: hg: jdk8/tl/jdk: 8006039: test/tools/launcher/I18NJarTest.java fails on Mac w/ LANG=C, LC_ALL=C Message-ID: <20130225224051.93CE247E99@hg.openjdk.java.net> Changeset: 58f829566fe3 Author: bchristi Date: 2013-02-25 14:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/58f829566fe3 8006039: test/tools/launcher/I18NJarTest.java fails on Mac w/ LANG=C, LC_ALL=C Summary: Avoid automated test failure by just exiting when in 'C' locale Reviewed-by: naoto, ksrini ! test/ProblemList.txt ! test/tools/launcher/I18NJarTest.java From jonathan.gibbons at oracle.com Mon Feb 25 23:09:15 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 25 Feb 2013 23:09:15 +0000 Subject: hg: jdk8/tl: 8008914: Add nashorn to the tl build Message-ID: <20130225230915.4782747E9C@hg.openjdk.java.net> Changeset: 5b0b6ef58dbf Author: jjg Date: 2013-02-25 15:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/5b0b6ef58dbf 8008914: Add nashorn to the tl build Reviewed-by: mr, tbell, jjh Contributed-by: erik.joelsson at oracle.com, james.laskey at oracle.com ! Makefile ! common/autoconf/generated-configure.sh ! common/autoconf/source-dirs.m4 ! common/autoconf/spec.gmk.in ! common/bin/hgforest.sh ! common/makefiles/Main.gmk ! common/makefiles/MakeBase.gmk ! make/Defs-internal.gmk ! make/jdk-rules.gmk ! make/sanity-rules.gmk ! make/scripts/hgforest.sh From jonathan.gibbons at oracle.com Mon Feb 25 23:09:21 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 25 Feb 2013 23:09:21 +0000 Subject: hg: jdk8/tl/jdk: 8008914: Add nashorn to the tl build Message-ID: <20130225230933.273A747E9F@hg.openjdk.java.net> Changeset: 4cf4403c9bf2 Author: jjg Date: 2013-02-25 15:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4cf4403c9bf2 8008914: Add nashorn to the tl build Reviewed-by: mr, tbell, jjh Contributed-by: erik.joelsson at oracle.com, james.laskey at oracle.com ! make/launchers/Makefile ! makefiles/CompileLaunchers.gmk ! makefiles/CreateJars.gmk ! test/tools/launcher/VersionCheck.java From mandy.chung at oracle.com Mon Feb 25 23:18:49 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 25 Feb 2013 15:18:49 -0800 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <512B91A1.8020603@oracle.com> References: <5115316A.8050109@oracle.com> <51291AEB.3040005@gmail.com> <5129534A.8000500@oracle.com> <5129D45A.6010802@gmail.com> <5129EBE5.1030207@oracle.com> <512A7593.7040807@gmail.com> <512A7EB6.8090503@oracle.com> <512A8554.6080203@gmail.com> <512A8AC2.9020800@oracle.com> <512A8E95.9000902@gmail.com> <512A91A6.7090804@oracle.com> <512B2EEC.5050200@oracle.com> <512B675A.7090207@gmail.com> <512B91A1.8020603@oracle.com> Message-ID: <512BF159.7040902@oracle.com> On 2/25/2013 8:30 AM, Nils Loodin wrote: > I changed it to > > sun.throwables.numThrowables > > in http://cr.openjdk.java.net/~nloodin/8007806/webrev.01/ > > Is this better? However, bear in mind that it's not exactly specified > where this is going to be incremented from yet. Nothing in this change > states that it's going to be incremented from the Throwable constructor. I'm surprised to see adding a performance counter for an "external" instrumentation agent to use. I understand that we agree that dynamic bytecode instrumentation is a more appropriate approach to instrument and count the number of thrown throwables. I guess I am missing the big picture how you want the serviceability tools (jstat etc) to work with the perf counters and tracing events. Mandy From chris.hegarty at oracle.com Mon Feb 25 23:25:19 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 25 Feb 2013 23:25:19 +0000 Subject: 8006409: ThreadLocalRandom should dropping padding fields from its serialized form In-Reply-To: References: <50EF4143.4090008@oracle.com> <50F408CF.6060207@oracle.com> <50F40D95.9050402@oracle.com> <50F44C72.60707@oracle.com> <50F483E7.6080504@oracle.com> <50F487CE.6010101@oracle.com> <50F48C5A.4040500@oracle.com> <8E0C1F8A-DF46-457C-81DB-0BC41FC5F2D5@oracle.com> <50F49B06.9070202@cs.oswego.edu> <50F50E1E.5040604@javaspecialists.eu> <50F558D7.5040509@cs.oswego.edu> <50F55B8F.40502@oracle.com> <50F55E7C.8040809@oracle.com> <50F56062.5070404@oracle.com> <50F584DD.6080108@oracle.com> <50F66BE4.3050305@gmail.com> <50F693A2.8030000@cs.oswego.edu> <50F6C0E4.2090401@oracle.com> <5124B086.60006@oracle.com> <5124DA0E.60507@oracle.com> <512BDBD3.5040403@oracle.com> <512BDF99.4070405@oracle.com> Message-ID: <93FE0DD4-0BCD-46CF-BE29-423E17835AE3@oracle.com> Thanks Martin, good suggestion. -Chris On 25 Feb 2013, at 22:25, Martin Buchholz wrote: > Perhaps slightly better is this variant, which adds doc for the @serialField's. > > /** > * @serialField rnd long > * seed for random computations > * @serialField initialized boolean > * always true > */ > private static final ObjectStreamField[] serialPersistentFields = { > new ObjectStreamField("rnd", long.class), > new ObjectStreamField("initialized", boolean.class), > }; > > /** > * Saves the {@code ThreadLocalRandom} to a stream (that is, serializes it). > */ > private void writeObject(java.io.ObjectOutputStream out) > throws java.io.IOException { > > java.io.ObjectOutputStream.PutField fields = out.putFields(); > fields.put("rnd", UNSAFE.getLong(Thread.currentThread(), SEED)); > fields.put("initialized", true); > out.writeFields(); > } > > > On Mon, Feb 25, 2013 at 2:13 PM, Martin Buchholz wrote: >> Me too! > From dmitry.nadezhin at gmail.com Tue Feb 26 02:58:36 2013 From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin) Date: Tue, 26 Feb 2013 05:58:36 +0300 Subject: [PATCH] Sunbug 7131192: Optimize BigInteger.doubleValue(), floatValue() In-Reply-To: <4A336C49-B0CD-443E-B771-1DD886F15BF4@oracle.com> References: <511ED22B.8030800@oracle.com> <2867C9E8-F8FB-405A-8D00-7D4F90CA9628@oracle.com> <692B4DC6-88F3-4740-9B06-BDE56BB7B8B5@oracle.com> <370E52AA-385B-4117-B18E-71699243782F@oracle.com> <4A336C49-B0CD-443E-B771-1DD886F15BF4@oracle.com> Message-ID: Hi Brian, The reported benchmark results are impressive: http://bugs.sun.com/view_bug.do?bug_id=7032154 Where can we find the 7032154 patch to review it ? Dima On Tue, Feb 26, 2013 at 12:50 AM, Brian Burkhalter wrote: > Hi Dima, > > On Feb 25, 2013, at 1:14 AM, Dmitry Nadezhin wrote: > > I looked at your fix of sunbug=6358355 "Fix Float.parseFloat to round > correctly and preserve monotonicity". > [?] > > 1) The line in floatValue() method > fValue = (float) doubleValue(); > > fValue can become Float.POSITIVE_INFINITY. > It causes incorrect result on input like this > [?] > > It can be fixed in such a way > fValue = Math.max(Float.MIN_VALUE, Math.min(Float.MAX_VALUE, (float) > doubleValue())); > > > Thanks for the catch! > > 2) The line in floatValue() method. > // difference is exactly half an ULP > // round to some other value maybe, then finish > fValue += 0.5f*ulp( fValue, overvalue ); > > When fValue is subnormal, the right-hand sign evaluates to 0, fValue > remains unchanged. > This is similar to the bug 4396272 - Parsing doubles fails to follow > IEEE for largest decimal that should yield 0. > [?] > > > It can be fixed in such a way > fValue = (float) (fValue + 0.5*ulp(fValue, overvalue)); > Constant 0.5 instead of 0.5f causes double evaluation of right-hand > side, so it doesn'nt underflow. > > > I was intending to comment on this as well. > > Once approved, I was thinking that the patch for 7192954 "Fix > Float.parseFloat to round correctly and preserve monotonicity" should be > applied first followed by patches for 4396272 "Parsing doubles fails to > follow IEEE for largest decimal that should yield 0" and > "BigInteger.doubleValue() is depressingly slow." I initiated some of these > reviews out of this sequence as I had not become aware of all the linkages. > > I am actually also wondering whether the patch for 7032154 "Performance > tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal," which I just > learned of today, should perhaps be dealt with prior to any of the above? > > Thanks, > > Brian From brian.burkhalter at oracle.com Tue Feb 26 03:16:40 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 25 Feb 2013 19:16:40 -0800 Subject: [PATCH] Sunbug 7131192: Optimize BigInteger.doubleValue(), floatValue() In-Reply-To: References: <511ED22B.8030800@oracle.com> <2867C9E8-F8FB-405A-8D00-7D4F90CA9628@oracle.com> <692B4DC6-88F3-4740-9B06-BDE56BB7B8B5@oracle.com> <370E52AA-385B-4117-B18E-71699243782F@oracle.com> <4A336C49-B0CD-443E-B771-1DD886F15BF4@oracle.com> Message-ID: <88AB632A-D17D-47D4-AAFB-90FD8327AF76@oracle.com> Hi Dima, On Feb 25, 2013, at 6:58 PM, Dmitry Nadezhin wrote: > The reported benchmark results are impressive: > http://bugs.sun.com/view_bug.do?bug_id=7032154 Indeed. > Where can we find the 7032154 patch to review it ? The patch appears to be against the state of the repository about 23 months ago. I could post the patch as-is, but I was thinking first to bring it up to date with respect to the current tip of the repository. Thanks, Brian From nils.loodin at oracle.com Tue Feb 26 10:12:24 2013 From: nils.loodin at oracle.com (Nils Loodin) Date: Tue, 26 Feb 2013 11:12:24 +0100 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <512BF159.7040902@oracle.com> References: <5115316A.8050109@oracle.com> <51291AEB.3040005@gmail.com> <5129534A.8000500@oracle.com> <5129D45A.6010802@gmail.com> <5129EBE5.1030207@oracle.com> <512A7593.7040807@gmail.com> <512A7EB6.8090503@oracle.com> <512A8554.6080203@gmail.com> <512A8AC2.9020800@oracle.com> <512A8E95.9000902@gmail.com> <512A91A6.7090804@oracle.com> <512B2EEC.5050200@oracle.com> <512B675A.7090207@gmail.com> <512B91A1.8020603@oracle.com> <512BF159.7040902@oracle.com> Message-ID: <512C8A88.8000606@oracle.com> On 02/26/2013 12:18 AM, Mandy Chung wrote: > On 2/25/2013 8:30 AM, Nils Loodin wrote: >> I changed it to >> >> sun.throwables.numThrowables >> >> in http://cr.openjdk.java.net/~nloodin/8007806/webrev.01/ >> >> Is this better? However, bear in mind that it's not exactly specified >> where this is going to be incremented from yet. Nothing in this change >> states that it's going to be incremented from the Throwable constructor. > > I'm surprised to see adding a performance counter for an "external" > instrumentation agent to use. I understand that we agree that dynamic > bytecode instrumentation is a more appropriate approach to instrument > and count the number of thrown throwables. Just to be clear, what I was trying to say that this review is just to add the counter, and the discussion on how and when to access it is something that I'd much rather have in context of a review of that code... But yes, we do agree that dynamic bytecode instrumentation is a more appropriate aproach to count the number of throwables. But that code and the following review would depend on this one. Regards, Nils Loodin From chris.hegarty at oracle.com Tue Feb 26 11:20:13 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 26 Feb 2013 11:20:13 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20130226112307.08DE647412@hg.openjdk.java.net> Changeset: bc92e4b044e2 Author: kmo Date: 2013-02-26 11:05 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bc92e4b044e2 7087570: java.lang.invoke.MemberName information wrong for method handles created with findConstructor Summary: REF_invokeSpecial DMHs (which are unusual) get marked explicitly; tweak the MHI to use this bit Reviewed-by: jrose, twisti ! src/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleInfo.java ! src/share/classes/java/lang/invoke/MethodHandles.java + test/java/lang/invoke/7087570/Test7087570.java Changeset: 5fcecbcefb71 Author: chegar Date: 2013-02-26 11:06 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5fcecbcefb71 Merge Changeset: 77447981db73 Author: chegar Date: 2013-02-26 11:18 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/77447981db73 Merge From vicente.romero at oracle.com Tue Feb 26 12:39:22 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 26 Feb 2013 12:39:22 +0000 Subject: hg: jdk8/tl/langtools: 8008436: javac should not issue a warning for overriding equals without hasCode if hashCode has been overriden by a superclass Message-ID: <20130226123930.27B6247414@hg.openjdk.java.net> Changeset: bd49e0304281 Author: vromero Date: 2013-02-26 09:04 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bd49e0304281 8008436: javac should not issue a warning for overriding equals without hasCode if hashCode has been overriden by a superclass Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/code/Symbol.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/OverridesEqualsButNotHashCodeTest.java ! test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.out From paul.sandoz at oracle.com Tue Feb 26 13:11:50 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 26 Feb 2013 14:11:50 +0100 Subject: Code review request In-Reply-To: <512BDB8B.9070005@oracle.com> References: <512672E6.1050708@oracle.com> <51289F3D.1010609@univ-mlv.fr> <458B2D62-336C-429C-B835-DEEC7031004B@oracle.com> <512BDB8B.9070005@oracle.com> Message-ID: <958F39D3-EB3A-4FD2-ABAF-5109BDDD8D49@oracle.com> On Feb 25, 2013, at 10:45 PM, David Holmes wrote: > On 26/02/2013 3:31 AM, Paul Sandoz wrote: >> Hi Remi, >> >> Thanks for the feedback i have addressed some of this, mostly related to >> inner classes, in following change set to the lambda repo: >> >> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3e50294c68ea > > I see a lot of private things that are now package-access. I presume you mean on constructors of private inner classes? > Is that because they are now being used within the package? > No, it is to avoid the creation of a synthetic package private constructor called by enclosing class to construct the inner class. > The access modifiers document intended usage even if there is limited accessibility to the class defining the member. The idea that a class restricted to package-access should have member access modifiers restricted to package-only or else private, is just plain wrong in my view. Each type should have a public, protected and private API. The exposure of the type within a package is a separate matter. Package-access then becomes a limited-sharing mechanism. > For private inner classes i took the view that protected on fields offered little value, but paused for top level classes. There are not many use-cases in the JDK at least for the packages i browsed. The class java.util.concurrent.atomic.Striped64 does not bother with protected. I am leaning towards the opinion that protected is just noise in these cases since the compiler offers no protection. Paul. From forax at univ-mlv.fr Tue Feb 26 13:40:37 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 26 Feb 2013 14:40:37 +0100 Subject: Code review request In-Reply-To: <958F39D3-EB3A-4FD2-ABAF-5109BDDD8D49@oracle.com> References: <512672E6.1050708@oracle.com> <51289F3D.1010609@univ-mlv.fr> <458B2D62-336C-429C-B835-DEEC7031004B@oracle.com> <512BDB8B.9070005@oracle.com> <958F39D3-EB3A-4FD2-ABAF-5109BDDD8D49@oracle.com> Message-ID: <512CBB55.7080301@univ-mlv.fr> On 02/26/2013 02:11 PM, Paul Sandoz wrote: > On Feb 25, 2013, at 10:45 PM, David Holmes wrote: > >> On 26/02/2013 3:31 AM, Paul Sandoz wrote: >>> Hi Remi, >>> >>> Thanks for the feedback i have addressed some of this, mostly related to >>> inner classes, in following change set to the lambda repo: >>> >>> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3e50294c68ea >> I see a lot of private things that are now package-access. > I presume you mean on constructors of private inner classes? > > >> Is that because they are now being used within the package? >> > No, it is to avoid the creation of a synthetic package private constructor called by enclosing class to construct the inner class. > > >> The access modifiers document intended usage even if there is limited accessibility to the class defining the member. The idea that a class restricted to package-access should have member access modifiers restricted to package-only or else private, is just plain wrong in my view. Each type should have a public, protected and private API. The exposure of the type within a package is a separate matter. Package-access then becomes a limited-sharing mechanism. >> > For private inner classes i took the view that protected on fields offered little value, but paused for top level classes. > > There are not many use-cases in the JDK at least for the packages i browsed. The class java.util.concurrent.atomic.Striped64 does not bother with protected. > > I am leaning towards the opinion that protected is just noise in these cases since the compiler offers no protection. amen :) > > Paul. R?mi From forax at univ-mlv.fr Tue Feb 26 13:50:11 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 26 Feb 2013 14:50:11 +0100 Subject: Code review request In-Reply-To: <458B2D62-336C-429C-B835-DEEC7031004B@oracle.com> References: <512672E6.1050708@oracle.com> <51289F3D.1010609@univ-mlv.fr> <458B2D62-336C-429C-B835-DEEC7031004B@oracle.com> Message-ID: <512CBD93.1080805@univ-mlv.fr> On 02/25/2013 06:31 PM, Paul Sandoz wrote: > Hi Remi, > > Thanks for the feedback i have addressed some of this, mostly related to inner classes, in following change set to the lambda repo: > > http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3e50294c68ea > > We can update the webrev next week. There are still some methods that are declared 'default public' and some that are declared just with 'default'. I propose the following code convention for abstract/default method in interface. All methods in interface are marked public (just because we may support private static method in jdk9), default method should be 'public default' and not 'default public', like we have public static, visibility modifier first, and abstract methods in the same interface should be declared only 'public'. R?mi ... From alan.bateman at oracle.com Tue Feb 26 14:11:27 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 26 Feb 2013 14:11:27 +0000 Subject: hg: jdk8/tl: 8008978: nashorn-rules.gmk missing Message-ID: <20130226141127.EAE4947417@hg.openjdk.java.net> Changeset: e065107437b9 Author: alanb Date: 2013-02-26 14:08 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e065107437b9 8008978: nashorn-rules.gmk missing Reviewed-by: alanb Contributed-by: erik.joelsson at oracle.com, james.laskey at oracle.com + make/nashorn-rules.gmk From alan.bateman at oracle.com Tue Feb 26 14:19:11 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 26 Feb 2013 14:19:11 +0000 Subject: hg: jdk8/tl/jdk: 8008977: profiles build broken by Nashorn build changes Message-ID: <20130226141937.1898847419@hg.openjdk.java.net> Changeset: 022cd5adc0fa Author: alanb Date: 2013-02-26 14:16 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/022cd5adc0fa 8008977: profiles build broken by Nashorn build changes Reviewed-by: chegar ! makefiles/profile-rtjar-includes.txt From jason_mehrens at hotmail.com Tue Feb 26 15:07:23 2013 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Tue, 26 Feb 2013 09:07:23 -0600 Subject: RFR: 8007806: Need a Throwables performance counter In-Reply-To: <512C8A88.8000606@oracle.com> References: <5115316A.8050109@oracle.com>, <51291AEB.3040005@gmail.com>, <5129534A.8000500@oracle.com>, <5129D45A.6010802@gmail.com>, <5129EBE5.1030207@oracle.com>, <512A7593.7040807@gmail.com>, <512A7EB6.8090503@oracle.com>, <512A8554.6080203@gmail.com>, <512A8AC2.9020800@oracle.com>, <512A8E95.9000902@gmail.com>, <512A91A6.7090804@oracle.com>, <512B2EEC.5050200@oracle.com>, <512B675A.7090207@gmail.com>, <512B91A1.8020603@oracle.com>, <512BF159.7040902@oracle.com>, <512C8A88.8000606@oracle.com> Message-ID: > Just to be clear, what I was trying to say that this review is just to > add the counter, and the discussion on how and when to access it is > something that I'd much rather have in context of a review of that code... Then the counter name should not bind you to how it is counting. +1 for 'sun.throwables' as suggested by Peter. Jason From paul.sandoz at oracle.com Tue Feb 26 15:41:14 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 26 Feb 2013 16:41:14 +0100 Subject: Code review request In-Reply-To: <512CBD93.1080805@univ-mlv.fr> References: <512672E6.1050708@oracle.com> <51289F3D.1010609@univ-mlv.fr> <458B2D62-336C-429C-B835-DEEC7031004B@oracle.com> <512CBD93.1080805@univ-mlv.fr> Message-ID: <20D89B20-0604-45E9-AAA7-38F74298C77A@oracle.com> On Feb 26, 2013, at 2:50 PM, Remi Forax wrote: > On 02/25/2013 06:31 PM, Paul Sandoz wrote: >> Hi Remi, >> >> Thanks for the feedback i have addressed some of this, mostly related to inner classes, in following change set to the lambda repo: >> >> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3e50294c68ea >> >> We can update the webrev next week. > > > > There are still some methods that are declared 'default public' Where? > and some that are declared just with 'default'. > > I propose the following code convention for abstract/default method in interface. > All methods in interface are marked public (just because we may support private static method in jdk9), > default method should be 'public default' and not 'default public', like we have public static, visibility modifier first, > and abstract methods in the same interface should be declared only 'public'. > I do not relish your proposal of changing all abstract methods in interfaces to be declared redundantly public because of potential future features, even if such features are highly likely, we should have that discussion when those feature arrive. The source in the java.util.function package uses "public default" for default methods. That source has been through a round of reviews strongly indicating this was the preferred approach. Mike, is that so? Paul. From sundararajan.athijegannathan at oracle.com Tue Feb 26 18:39:55 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 26 Feb 2013 18:39:55 +0000 Subject: hg: jdk8/tl/nashorn: 2 new changesets Message-ID: <20130226183956.6A44F47424@hg.openjdk.java.net> Changeset: 1654918e0612 Author: attila Date: 2013-02-25 16:51 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1654918e0612 8006984: Introducing local into a function inside with statement confuses its scope Reviewed-by: jlaskey, lagergren, sundar ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/WithObject.java + test/script/basic/JDK-8006984.js + test/script/basic/JDK-8006984.js.EXPECTED Changeset: a90094ae5be3 Author: sundar Date: 2013-02-26 22:57 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a90094ae5be3 8009021: nasgen should be run on boot jdk rather than currenly built jdk Reviewed-by: jlaskey ! makefiles/BuildNashorn.gmk From robert.field at oracle.com Tue Feb 26 18:44:48 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Tue, 26 Feb 2013 18:44:48 +0000 Subject: hg: jdk8/tl/jdk: 8008770: SerializedLambda incorrect class loader for lambda deserializing class Message-ID: <20130226184510.A901D47425@hg.openjdk.java.net> Changeset: 5ebc62421717 Author: rfield Date: 2013-02-26 10:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5ebc62421717 8008770: SerializedLambda incorrect class loader for lambda deserializing class Summary: current thread's context ClassLoader was used to load class by name, pass class not name in serialization (Thank you Peter Levart for test and prototype. Thank you Sundar and Peter for unofficial reviews) Reviewed-by: forax ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/share/classes/java/lang/invoke/SerializedLambda.java + test/java/lang/invoke/lambda/LambdaClassLoaderSerialization.java ! test/java/lang/invoke/lambda/LambdaSerialization.java From alan.bateman at oracle.com Tue Feb 26 22:41:57 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 26 Feb 2013 22:41:57 +0000 Subject: hg: jdk8/tl/jdk: 8009029: SunEC provider classes ending up in rt.jar after Nashorn build changes Message-ID: <20130226224220.A988947445@hg.openjdk.java.net> Changeset: ecd33c6ab12f Author: alanb Date: 2013-02-26 22:39 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ecd33c6ab12f 8009029: SunEC provider classes ending up in rt.jar after Nashorn build changes Reviewed-by: mduigou ! makefiles/CreateJars.gmk From joe.darcy at oracle.com Tue Feb 26 23:38:05 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 26 Feb 2013 15:38:05 -0800 Subject: JDK 8 RFR: some more docs build warnings Message-ID: <512D475D.9060801@oracle.com> Hello, Please review the patch before the fix some docs build warnings. I'll file a bug once the review is complete, etc. Thanks, -Joe diff -r ecd33c6ab12f src/share/classes/java/lang/invoke/LambdaMetafactory.java --- a/src/share/classes/java/lang/invoke/LambdaMetafactory.java Tue Feb 26 22:39:50 2013 +0000 +++ b/src/share/classes/java/lang/invoke/LambdaMetafactory.java Tue Feb 26 15:36:27 2013 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -220,24 +220,11 @@ * of the caller. * @param invokedName Stacked automatically by VM; the name of the invoked method as it appears at the call site. * Currently unused. - * @param invokedType Stacked automatically by VM; the signature of the invoked method, which includes the + * @param invokedType Stacked automatically by VM; the signature of the invoked method, which includes thefu * expected static type of the returned lambda object, and the static types of the captured * arguments for the lambda. In the event that the implementation method is an instance method, * the first argument in the invocation signature will correspond to the receiver. - * @param samMethod The primary method in the functional interface to which the lambda or method reference is - * being converted, represented as a method handle. - * @param implMethod The implementation method which should be called (with suitable adaptation of argument - * types, return types, and adjustment for captured arguments) when methods of the resulting - * functional interface instance are invoked. - * @param instantiatedMethodType The signature of the primary functional interface method after type variables - * are substituted with their instantiation from the capture site - * @param flags A bitmask containing flags that may influence the translation of this lambda expression. Defined - * fields include FLAG_SERIALIZABLE and FLAG_MARKERS. - * @param markerInterfaceCount If the FLAG_MARKERS flag is set, this is a count of the number of additional - * marker interfaces - * @param markerInterfaces If the FLAG_MARKERS flag is set, this consists of Class objects identifying additional - * marker interfaces which the lambda object should implement, whose count equals - * markerInterfaceCount + * @param args argument to pass, flags, marker interface count, and marker interfaces as described above * @return a CallSite, which, when invoked, will return an instance of the functional interface * @throws ReflectiveOperationException * @throws LambdaConversionException If any of the meta-factory protocol invariants are violated diff -r ecd33c6ab12f src/share/classes/java/util/function/BinaryOperator.java --- a/src/share/classes/java/util/function/BinaryOperator.java Tue Feb 26 22:39:50 2013 +0000 +++ b/src/share/classes/java/util/function/BinaryOperator.java Tue Feb 26 15:36:27 2013 -0800 @@ -30,7 +30,7 @@ * * @param the type of operands to {@code apply} and of the result * - * @see BiFunction. + * @see BiFunction * @since 1.8 */ @FunctionalInterface diff -r ecd33c6ab12f src/share/classes/java/util/function/ToDoubleBiFunction.java --- a/src/share/classes/java/util/function/ToDoubleBiFunction.java Tue Feb 26 22:39:50 2013 +0000 +++ b/src/share/classes/java/util/function/ToDoubleBiFunction.java Tue Feb 26 15:36:27 2013 -0800 @@ -33,7 +33,7 @@ * @param the type of the second argument to the {@code applyAsDouble} * operation. * - * @see BiFunction. + * @see BiFunction * @since 1.8 */ @FunctionalInterface From mike.duigou at oracle.com Tue Feb 26 23:42:00 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 26 Feb 2013 15:42:00 -0800 Subject: JDK 8 RFR: some more docs build warnings In-Reply-To: <512D475D.9060801@oracle.com> References: <512D475D.9060801@oracle.com> Message-ID: The look fine to me. The same fixes ToDoubleBiFunction.java and BinaryOperator.java have been applied in the lambda repository. Mike On Feb 26 2013, at 15:38 , Joe Darcy wrote: > Hello, > > Please review the patch before the fix some docs build warnings. I'll file a bug once the review is complete, etc. > > Thanks, > > -Joe > > diff -r ecd33c6ab12f src/share/classes/java/lang/invoke/LambdaMetafactory.java > --- a/src/share/classes/java/lang/invoke/LambdaMetafactory.java Tue Feb 26 22:39:50 2013 +0000 > +++ b/src/share/classes/java/lang/invoke/LambdaMetafactory.java Tue Feb 26 15:36:27 2013 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -220,24 +220,11 @@ > * of the caller. > * @param invokedName Stacked automatically by VM; the name of the invoked method as it appears at the call site. > * Currently unused. > - * @param invokedType Stacked automatically by VM; the signature of the invoked method, which includes the > + * @param invokedType Stacked automatically by VM; the signature of the invoked method, which includes thefu > * expected static type of the returned lambda object, and the static types of the captured > * arguments for the lambda. In the event that the implementation method is an instance method, > * the first argument in the invocation signature will correspond to the receiver. > - * @param samMethod The primary method in the functional interface to which the lambda or method reference is > - * being converted, represented as a method handle. > - * @param implMethod The implementation method which should be called (with suitable adaptation of argument > - * types, return types, and adjustment for captured arguments) when methods of the resulting > - * functional interface instance are invoked. > - * @param instantiatedMethodType The signature of the primary functional interface method after type variables > - * are substituted with their instantiation from the capture site > - * @param flags A bitmask containing flags that may influence the translation of this lambda expression. Defined > - * fields include FLAG_SERIALIZABLE and FLAG_MARKERS. > - * @param markerInterfaceCount If the FLAG_MARKERS flag is set, this is a count of the number of additional > - * marker interfaces > - * @param markerInterfaces If the FLAG_MARKERS flag is set, this consists of Class objects identifying additional > - * marker interfaces which the lambda object should implement, whose count equals > - * markerInterfaceCount > + * @param args argument to pass, flags, marker interface count, and marker interfaces as described above > * @return a CallSite, which, when invoked, will return an instance of the functional interface > * @throws ReflectiveOperationException > * @throws LambdaConversionException If any of the meta-factory protocol invariants are violated > diff -r ecd33c6ab12f src/share/classes/java/util/function/BinaryOperator.java > --- a/src/share/classes/java/util/function/BinaryOperator.java Tue Feb 26 22:39:50 2013 +0000 > +++ b/src/share/classes/java/util/function/BinaryOperator.java Tue Feb 26 15:36:27 2013 -0800 > @@ -30,7 +30,7 @@ > * > * @param the type of operands to {@code apply} and of the result > * > - * @see BiFunction. > + * @see BiFunction > * @since 1.8 > */ > @FunctionalInterface > diff -r ecd33c6ab12f src/share/classes/java/util/function/ToDoubleBiFunction.java > --- a/src/share/classes/java/util/function/ToDoubleBiFunction.java Tue Feb 26 22:39:50 2013 +0000 > +++ b/src/share/classes/java/util/function/ToDoubleBiFunction.java Tue Feb 26 15:36:27 2013 -0800 > @@ -33,7 +33,7 @@ > * @param the type of the second argument to the {@code applyAsDouble} > * operation. > * > - * @see BiFunction. > + * @see BiFunction > * @since 1.8 > */ > @FunctionalInterface > From dan.xu at oracle.com Wed Feb 27 00:10:51 2013 From: dan.xu at oracle.com (Dan Xu) Date: Tue, 26 Feb 2013 16:10:51 -0800 Subject: Review Request for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly Message-ID: <512D4F0B.8020903@oracle.com> Hi All, Please help review the fix for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly. Java IO, not like NIO, does not check NUL character in the given file path name, which brings confusion to Java users. This fix is going to address this issue by removing any NUL character from the given file path. And it also cleans and optimizes the path-name normalization logic. Thanks! Bug: https://jbs.oracle.com/bugs/browse/JDK-8003992 webrev: http://cr.openjdk.java.net/~dxu/8003992/webrev.00/ -Dan From mike.duigou at oracle.com Wed Feb 27 00:33:31 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 26 Feb 2013 16:33:31 -0800 Subject: Review Request for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly In-Reply-To: <512D4F0B.8020903@oracle.com> References: <512D4F0B.8020903@oracle.com> Message-ID: Hi Dan; External link to the bug (will hopefully work soon): http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003992 I would like to better understand why silently removing the garbage null characters is the right answer here. If null is an invalid character for the underlying operating system or filesystem then perhaps an error should be signalled. Mike On Feb 26 2013, at 16:10 , Dan Xu wrote: > Hi All, > > Please help review the fix for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly. > > Java IO, not like NIO, does not check NUL character in the given file path name, which brings confusion to Java users. This fix is going to address this issue by removing any NUL character from the given file path. And it also cleans and optimizes the path-name normalization logic. Thanks! > > Bug: https://jbs.oracle.com/bugs/browse/JDK-8003992 > webrev: http://cr.openjdk.java.net/~dxu/8003992/webrev.00/ > > -Dan From joe.darcy at oracle.com Wed Feb 27 01:01:23 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 27 Feb 2013 01:01:23 +0000 Subject: hg: jdk8/tl/jdk: 8009102: Several docs warnings in Project Lambda APIs Message-ID: <20130227010146.5DE3047448@hg.openjdk.java.net> Changeset: 543be9488e50 Author: darcy Date: 2013-02-26 17:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/543be9488e50 8009102: Several docs warnings in Project Lambda APIs Reviewed-by: mduigou ! src/share/classes/java/lang/invoke/LambdaMetafactory.java ! src/share/classes/java/util/function/BinaryOperator.java ! src/share/classes/java/util/function/ToDoubleBiFunction.java From joe.darcy at oracle.com Wed Feb 27 01:38:42 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 27 Feb 2013 01:38:42 +0000 Subject: hg: jdk8/tl/jdk: 8008279: Remove InvalidContainerAnnotationError.java Message-ID: <20130227013902.8F1684744B@hg.openjdk.java.net> Changeset: d623f520557b Author: darcy Date: 2013-02-26 17:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d623f520557b 8008279: Remove InvalidContainerAnnotationError.java Reviewed-by: jfranck - src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java ! src/share/classes/java/lang/reflect/AnnotatedElement.java ! src/share/classes/sun/reflect/annotation/AnnotationSupport.java From martinrb at google.com Wed Feb 27 02:18:14 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 26 Feb 2013 18:18:14 -0800 Subject: Review Request for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly In-Reply-To: References: <512D4F0B.8020903@oracle.com> Message-ID: Filenames are a lot like environment variables, and we already have code that rejects NUL chars in environment variable names: // Check that name is suitable for insertion into Environment map private static void validateVariable(String name) { if (name.indexOf('=') != -1 || name.indexOf('\u0000') != -1) throw new IllegalArgumentException ("Invalid environment variable name: \"" + name + "\""); } On Tue, Feb 26, 2013 at 4:33 PM, Mike Duigou wrote: > Hi Dan; > > External link to the bug (will hopefully work soon): > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003992 > > I would like to better understand why silently removing the garbage null > characters is the right answer here. > > If null is an invalid character for the underlying operating system or > filesystem then perhaps an error should be signalled. > > Mike > > On Feb 26 2013, at 16:10 , Dan Xu wrote: > > > Hi All, > > > > Please help review the fix for JDK-8003992: File and other classes in > java.io do not handle embedded nulls properly. > > > > Java IO, not like NIO, does not check NUL character in the given file > path name, which brings confusion to Java users. This fix is going to > address this issue by removing any NUL character from the given file path. > And it also cleans and optimizes the path-name normalization logic. Thanks! > > > > Bug: https://jbs.oracle.com/bugs/browse/JDK-8003992 > > webrev: http://cr.openjdk.java.net/~dxu/8003992/webrev.00/ > > > > -Dan > > From dan.xu at oracle.com Wed Feb 27 02:31:37 2013 From: dan.xu at oracle.com (Dan Xu) Date: Tue, 26 Feb 2013 18:31:37 -0800 Subject: Review Request for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly In-Reply-To: References: <512D4F0B.8020903@oracle.com> Message-ID: <512D7009.70506@oracle.com> Thank you, Mike. The reason not to throw out an exception is for the backward compatibility. Due to that, the constructorof File object with NUL willnever fail.While in NIO, it is defined in the spec to throw out exceptions when invalid NUL character is found. -Dan On 02/26/2013 04:33 PM, Mike Duigou wrote: > Hi Dan; > > External link to the bug (will hopefully work soon): > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003992 > > I would like to better understand why silently removing the garbage null characters is the right answer here. > > If null is an invalid character for the underlying operating system or filesystem then perhaps an error should be signalled. > > Mike > > On Feb 26 2013, at 16:10 , Dan Xu wrote: > >> Hi All, >> >> Please help review the fix for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly. >> >> Java IO, not like NIO, does not check NUL character in the given file path name, which brings confusion to Java users. This fix is going to address this issue by removing any NUL character from the given file path. And it also cleans and optimizes the path-name normalization logic. Thanks! >> >> Bug: https://jbs.oracle.com/bugs/browse/JDK-8003992 >> webrev: http://cr.openjdk.java.net/~dxu/8003992/webrev.00/ >> >> -Dan From david.holmes at oracle.com Wed Feb 27 02:52:07 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Feb 2013 12:52:07 +1000 Subject: Review Request for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly In-Reply-To: <512D7009.70506@oracle.com> References: <512D4F0B.8020903@oracle.com> <512D7009.70506@oracle.com> Message-ID: <512D74D7.2010902@oracle.com> On 27/02/2013 12:31 PM, Dan Xu wrote: > Thank you, Mike. > > The reason not to throw out an exception is for the backward > compatibility. Due to that, the constructorof File object with NUL > willnever fail.While in NIO, it is defined in the spec to throw out > exceptions when invalid NUL character is found. That still gives the choice of deleting the nul characters, or treating them as a terminator. And do we really want/need to maintain compatability in this case anyway? What reasonable expectations can anyone have if they have embedded nuls? David > -Dan > > > On 02/26/2013 04:33 PM, Mike Duigou wrote: >> Hi Dan; >> >> External link to the bug (will hopefully work soon): >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003992 >> >> I would like to better understand why silently removing the garbage >> null characters is the right answer here. >> >> If null is an invalid character for the underlying operating system or >> filesystem then perhaps an error should be signalled. >> >> Mike >> >> On Feb 26 2013, at 16:10 , Dan Xu wrote: >> >>> Hi All, >>> >>> Please help review the fix for JDK-8003992: File and other classes in >>> java.io do not handle embedded nulls properly. >>> >>> Java IO, not like NIO, does not check NUL character in the given file >>> path name, which brings confusion to Java users. This fix is going to >>> address this issue by removing any NUL character from the given file >>> path. And it also cleans and optimizes the path-name normalization >>> logic. Thanks! >>> >>> Bug: https://jbs.oracle.com/bugs/browse/JDK-8003992 >>> webrev: http://cr.openjdk.java.net/~dxu/8003992/webrev.00/ >>> >>> -Dan > From sundararajan.athijegannathan at oracle.com Wed Feb 27 10:39:57 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 27 Feb 2013 16:09:57 +0530 Subject: Codereview request for 8009115: jtreg tests under jdk/test/javax/script should use nashorn as script engine Message-ID: <512DE27D.1080006@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8009115/ Changing javax.script tests to use nashorn engine explicitly - also adjusting tests to reflect (minor) changes b/w nashorn and rhino. Thanks -Sundar From Alan.Bateman at oracle.com Wed Feb 27 10:40:21 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Feb 2013 10:40:21 +0000 Subject: Review Request for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly In-Reply-To: <512D7009.70506@oracle.com> References: <512D4F0B.8020903@oracle.com> <512D7009.70506@oracle.com> Message-ID: <512DE295.8000508@oracle.com> On 27/02/2013 02:31, Dan Xu wrote: > Thank you, Mike. > > The reason not to throw out an exception is for the backward > compatibility. Due to that, the constructorof File object with NUL > willnever fail.While in NIO, it is defined in the spec to throw out > exceptions when invalid NUL character is found. > > -Dan Right, we can't change the constructor to throw an exception, particularly if this fix is going to be back-ported to 7u. For NIO then it's not an issue because getPath was specified from the begining to throw the unexpected InvalidPathException when it is given garbage. -Alan. From sundararajan.athijegannathan at oracle.com Wed Feb 27 10:44:17 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 27 Feb 2013 16:14:17 +0530 Subject: Review request for 8009115: jtreg tests under jdk/test/javax/script should use nashorn as script engine Message-ID: <512DE381.9050102@oracle.com> Hi, Please review http://cr.openjdk.java.net/~sundar/8009115/ Changing javax.script tests to use nashorn engine explicitly. Adjusted tests for differences b/w nashorn and rhino engines. Changes documented here: http://cr.openjdk.java.net/~sundar/8009115/README Thanks -Sundar From Alan.Bateman at oracle.com Wed Feb 27 11:17:28 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Feb 2013 11:17:28 +0000 Subject: Review request for 8009115: jtreg tests under jdk/test/javax/script should use nashorn as script engine In-Reply-To: <512DE381.9050102@oracle.com> References: <512DE381.9050102@oracle.com> Message-ID: <512DEB48.5060703@oracle.com> On 27/02/2013 10:44, A. Sundararajan wrote: > Hi, > > Please review http://cr.openjdk.java.net/~sundar/8009115/ > > Changing javax.script tests to use nashorn engine explicitly. Adjusted > tests for differences b/w nashorn and rhino engines. > Changes documented here: > http://cr.openjdk.java.net/~sundar/8009115/README > > Thanks > -Sundar These changes look okay to me although I assumed that Nashorn would be a "js" scripting engine, in which case there shouldn't be a need to change many of the getEngineByName("js") usages to "nashorn". -Alan From sundararajan.athijegannathan at oracle.com Wed Feb 27 11:20:08 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 27 Feb 2013 16:50:08 +0530 Subject: Review request for 8009115: jtreg tests under jdk/test/javax/script should use nashorn as script engine In-Reply-To: <512DEB48.5060703@oracle.com> References: <512DE381.9050102@oracle.com> <512DEB48.5060703@oracle.com> Message-ID: <512DEBE8.4050903@oracle.com> Thanks Alan. Yes, nashorn is a "js" engine as well and so user's java code can use getEngineByName("js") and get it. The current change is to make sure that javax.script tests use nashorn engine - rather than any other "js" engine that may be present in the underlying jdk. -Sundar On Wednesday 27 February 2013 04:47 PM, Alan Bateman wrote: > On 27/02/2013 10:44, A. Sundararajan wrote: >> Hi, >> >> Please review http://cr.openjdk.java.net/~sundar/8009115/ >> >> Changing javax.script tests to use nashorn engine explicitly. >> Adjusted tests for differences b/w nashorn and rhino engines. >> Changes documented here: >> http://cr.openjdk.java.net/~sundar/8009115/README >> >> Thanks >> -Sundar > These changes look okay to me although I assumed that Nashorn would be > a "js" scripting engine, in which case there shouldn't be a need to > change many of the getEngineByName("js") usages to "nashorn". > > -Alan From sundararajan.athijegannathan at oracle.com Wed Feb 27 11:55:34 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Wed, 27 Feb 2013 11:55:34 +0000 Subject: hg: jdk8/tl/jdk: 8009115: jtreg tests under jdk/test/javax/script should use nashorn as script engine Message-ID: <20130227115602.B096C4745F@hg.openjdk.java.net> Changeset: f5416026cdf5 Author: sundar Date: 2013-02-27 17:22 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f5416026cdf5 8009115: jtreg tests under jdk/test/javax/script should use nashorn as script engine Reviewed-by: alanb ! test/javax/script/CauseExceptionTest.java + test/javax/script/ExceptionTest.java ! test/javax/script/GetInterfaceTest.java ! test/javax/script/Helper.java - test/javax/script/RhinoExceptionTest.java ! test/javax/script/StringWriterPrintTest.java ! test/javax/script/Test3.js ! test/javax/script/Test5.java ! test/javax/script/Test5.js ! test/javax/script/Test6.java ! test/javax/script/Test7.js ! test/javax/script/UnescapedBracketRegExTest.java ! test/javax/script/VersionTest.java From peter.levart at gmail.com Wed Feb 27 12:07:05 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 27 Feb 2013 13:07:05 +0100 Subject: Review Request for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly In-Reply-To: <512D74D7.2010902@oracle.com> References: <512D4F0B.8020903@oracle.com> <512D7009.70506@oracle.com> <512D74D7.2010902@oracle.com> Message-ID: <512DF6E9.4050100@gmail.com> On 02/27/2013 03:52 AM, David Holmes wrote: > On 27/02/2013 12:31 PM, Dan Xu wrote: >> Thank you, Mike. >> >> The reason not to throw out an exception is for the backward >> compatibility. Due to that, the constructorof File object with NUL >> willnever fail.While in NIO, it is defined in the spec to throw out >> exceptions when invalid NUL character is found. > > That still gives the choice of deleting the nul characters, or > treating them as a terminator. > > And do we really want/need to maintain compatability in this case > anyway? What reasonable expectations can anyone have if they have > embedded nuls? 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... Regards, Peter > > David > >> -Dan >> >> >> On 02/26/2013 04:33 PM, Mike Duigou wrote: >>> Hi Dan; >>> >>> External link to the bug (will hopefully work soon): >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003992 >>> >>> I would like to better understand why silently removing the garbage >>> null characters is the right answer here. >>> >>> If null is an invalid character for the underlying operating system or >>> filesystem then perhaps an error should be signalled. >>> >>> Mike >>> >>> On Feb 26 2013, at 16:10 , Dan Xu wrote: >>> >>>> Hi All, >>>> >>>> Please help review the fix for JDK-8003992: File and other classes in >>>> java.io do not handle embedded nulls properly. >>>> >>>> Java IO, not like NIO, does not check NUL character in the given file >>>> path name, which brings confusion to Java users. This fix is going to >>>> address this issue by removing any NUL character from the given file >>>> path. And it also cleans and optimizes the path-name normalization >>>> logic. Thanks! >>>> >>>> Bug: https://jbs.oracle.com/bugs/browse/JDK-8003992 >>>> webrev: http://cr.openjdk.java.net/~dxu/8003992/webrev.00/ >>>> >>>> -Dan >> From Alan.Bateman at oracle.com Wed Feb 27 12:15:06 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Feb 2013 12:15:06 +0000 Subject: Review Request for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly In-Reply-To: <512DF6E9.4050100@gmail.com> References: <512D4F0B.8020903@oracle.com> <512D7009.70506@oracle.com> <512D74D7.2010902@oracle.com> <512DF6E9.4050100@gmail.com> Message-ID: <512DF8CA.20109@oracle.com> 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. -Alan From Alan.Bateman at oracle.com Wed Feb 27 12:22:58 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Feb 2013 12:22:58 +0000 Subject: Review request for 8009115: jtreg tests under jdk/test/javax/script should use nashorn as script engine In-Reply-To: <512DEBE8.4050903@oracle.com> References: <512DE381.9050102@oracle.com> <512DEB48.5060703@oracle.com> <512DEBE8.4050903@oracle.com> Message-ID: <512DFAA2.7050808@oracle.com> On 27/02/2013 11:20, A. Sundararajan wrote: > Thanks Alan. Yes, nashorn is a "js" engine as well and so user's java > code can use getEngineByName("js") and get it. The current change is > to make sure that javax.script tests use nashorn engine - rather than > any other "js" engine that may be present in the underlying jdk. > > -Sundar I assume Rhino in the Oracle builds should now be removed or disabled. The changes are fine for today of course. It would be good to look at the tests in sun/tools/jrunscript too as I I think there may be changes required there too. -Alan From sundararajan.athijegannathan at oracle.com Wed Feb 27 12:24:06 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 27 Feb 2013 17:54:06 +0530 Subject: Review request for 8009115: jtreg tests under jdk/test/javax/script should use nashorn as script engine In-Reply-To: <512DFAA2.7050808@oracle.com> References: <512DE381.9050102@oracle.com> <512DEB48.5060703@oracle.com> <512DEBE8.4050903@oracle.com> <512DFAA2.7050808@oracle.com> Message-ID: <512DFAE6.60009@oracle.com> Yes, that is the plan (i.e., removal of rhino in Oracle builds). I am looking at jrunscript tests too. Thanks -Sundar On Wednesday 27 February 2013 05:52 PM, Alan Bateman wrote: > On 27/02/2013 11:20, A. Sundararajan wrote: >> Thanks Alan. Yes, nashorn is a "js" engine as well and so user's java >> code can use getEngineByName("js") and get it. The current change is >> to make sure that javax.script tests use nashorn engine - rather than >> any other "js" engine that may be present in the underlying jdk. >> >> -Sundar > I assume Rhino in the Oracle builds should now be removed or disabled. > The changes are fine for today of course. It would be good to look at > the tests in sun/tools/jrunscript too as I I think there may be > changes required there too. > > -Alan From sundararajan.athijegannathan at oracle.com Wed Feb 27 14:14:45 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 27 Feb 2013 19:44:45 +0530 Subject: Please review 8009140: jtreg tests under sun/tools/jrunscript should use nashorn engine Message-ID: <512E14D5.4040102@oracle.com> Hi, Please review http://cr.openjdk.java.net/~sundar/8009140/ Thanks -Sundar From alan.bateman at oracle.com Wed Feb 27 14:15:17 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 27 Feb 2013 14:15:17 +0000 Subject: hg: jdk8/tl/nashorn: 8008950: jdk8/tl failing with SetupJavaCompilation BUILD_NASGEN contains missing directory -c on Windows Message-ID: <20130227141518.B525F47463@hg.openjdk.java.net> Changeset: 1d3dca059b3e Author: alanb Date: 2013-02-27 14:12 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1d3dca059b3e 8008950: jdk8/tl failing with SetupJavaCompilation BUILD_NASGEN contains missing directory -c on Windows Reviewed-by: chegar, sundar ! makefiles/BuildNashorn.gmk From Alan.Bateman at oracle.com Wed Feb 27 14:29:26 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Feb 2013 14:29:26 +0000 Subject: Please review 8009140: jtreg tests under sun/tools/jrunscript should use nashorn engine In-Reply-To: <512E14D5.4040102@oracle.com> References: <512E14D5.4040102@oracle.com> Message-ID: <512E1846.1020806@oracle.com> On 27/02/2013 14:14, A. Sundararajan wrote: > Hi, > > Please review http://cr.openjdk.java.net/~sundar/8009140/ This looks okay to me. -Alan From alan.bateman at oracle.com Wed Feb 27 14:28:50 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 27 Feb 2013 14:28:50 +0000 Subject: hg: jdk8/tl/jdk: 8008793: SecurityManager.checkXXX behavior not specified for methods that check AWTPermission and AWT not present Message-ID: <20130227142911.1D25047465@hg.openjdk.java.net> Changeset: 13013dedcdfd Author: alanb Date: 2013-02-27 14:24 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/13013dedcdfd 8008793: SecurityManager.checkXXX behavior not specified for methods that check AWTPermission and AWT not present Reviewed-by: hawtin, mullan, dsamersoff, mchung ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/sun/security/util/SecurityConstants.java ! test/java/lang/SecurityManager/NoAWT.java From sundararajan.athijegannathan at oracle.com Wed Feb 27 15:05:21 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Wed, 27 Feb 2013 15:05:21 +0000 Subject: hg: jdk8/tl/jdk: 8009140: jtreg tests under sun/tools/jrunscript should use nashorn engine Message-ID: <20130227150543.C4F8B47469@hg.openjdk.java.net> Changeset: 1b3173c326e6 Author: sundar Date: 2013-02-27 20:34 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1b3173c326e6 8009140: jtreg tests under sun/tools/jrunscript should use nashorn engine Reviewed-by: alanb ! test/sun/tools/jrunscript/CheckEngine.java ! test/sun/tools/jrunscript/jrunscript-DTest.sh ! test/sun/tools/jrunscript/jrunscript-argsTest.sh ! test/sun/tools/jrunscript/jrunscript-cpTest.sh ! test/sun/tools/jrunscript/jrunscript-eTest.sh ! test/sun/tools/jrunscript/jrunscript-fTest.sh ! test/sun/tools/jrunscript/jrunscriptTest.sh ! test/sun/tools/jrunscript/repl.out From vladimir.danushevsky at oracle.com Wed Feb 27 16:23:11 2013 From: vladimir.danushevsky at oracle.com (vladimir.danushevsky at oracle.com) Date: Wed, 27 Feb 2013 16:23:11 +0000 Subject: hg: jdk8/tl/jdk: 8005545: Add System property to identify ARCH specific details such as ARM hard-float binaries Message-ID: <20130227162334.B24894746D@hg.openjdk.java.net> Changeset: 093fdf8937bd Author: vladidan Date: 2013-02-22 17:12 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/093fdf8937bd 8005545: Add System property to identify ARCH specific details such as ARM hard-float binaries Summary: Adding sun.os.abi Java Property support Reviewed-by: bobv, alanb, dholmes ! makefiles/Images.gmk ! src/share/native/java/lang/System.c ! src/share/native/java/lang/java_props.h ! src/solaris/native/java/lang/java_props_md.c From martinrb at google.com Wed Feb 27 17:10:02 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 27 Feb 2013 09:10:02 -0800 Subject: 8006409: ThreadLocalRandom should dropping padding fields from its serialized form In-Reply-To: <93FE0DD4-0BCD-46CF-BE29-423E17835AE3@oracle.com> References: <50EF4143.4090008@oracle.com> <50F408CF.6060207@oracle.com> <50F40D95.9050402@oracle.com> <50F44C72.60707@oracle.com> <50F483E7.6080504@oracle.com> <50F487CE.6010101@oracle.com> <50F48C5A.4040500@oracle.com> <8E0C1F8A-DF46-457C-81DB-0BC41FC5F2D5@oracle.com> <50F49B06.9070202@cs.oswego.edu> <50F50E1E.5040604@javaspecialists.eu> <50F558D7.5040509@cs.oswego.edu> <50F55B8F.40502@oracle.com> <50F55E7C.8040809@oracle.com> <50F56062.5070404@oracle.com> <50F584DD.6080108@oracle.com> <50F66BE4.3050305@gmail.com> <50F693A2.8030000@cs.oswego.edu> <50F6C0E4.2090401@oracle.com> <5124B086.60006@oracle.com> <5124DA0E.60507@oracle.com> <512BDBD3.5040403@oracle.com> <512BDF99.4070405@oracle.com> <93FE0DD4-0BCD-46CF-BE29-423E17835AE3@oracle.com> Message-ID: CVS has been updated with some more internal doc clarifications. http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ThreadLocalRandom.java?view=co Martin's "random" wishlist: - I wish the cool convenience methods in TLR like nextInt(least, bound) could be promoted to Random.java, or perhaps to a utility class Randoms.java - I wish that TLR didn't continue to extend the life of Random's poor PRNG, and at least provide one with a 2**64 period. I don't see much value producing a sequence compatible with Random, given that setSeed is not available. but it's probably too late. From chris.hegarty at oracle.com Wed Feb 27 17:55:10 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 27 Feb 2013 17:55:10 +0000 Subject: 8006409: ThreadLocalRandom should dropping padding fields from its serialized form In-Reply-To: References: <50EF4143.4090008@oracle.com> <50F48C5A.4040500@oracle.com> <8E0C1F8A-DF46-457C-81DB-0BC41FC5F2D5@oracle.com> <50F49B06.9070202@cs.oswego.edu> <50F50E1E.5040604@javaspecialists.eu> <50F558D7.5040509@cs.oswego.edu> <50F55B8F.40502@oracle.com> <50F55E7C.8040809@oracle.com> <50F56062.5070404@oracle.com> <50F584DD.6080108@oracle.com> <50F66BE4.3050305@gmail.com> <50F693A2.8030000@cs.oswego.edu> <50F6C0E4.2090401@oracle.com> <5124B086.60006@oracle.com> <5124DA0E.60507@oracle.com> <512BDBD3.5040403@oracle.com> <512BDF99.4070405@oracle.com> <93FE0DD4-0BCD-46CF-BE29-423E17835AE3@oracle.com> Message-ID: <512E487E.3060108@oracle.com> On 02/27/2013 05:10 PM, Martin Buchholz wrote: > CVS has been updated with some more internal doc clarifications. > > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ThreadLocalRandom.java?view=co Thanks Martin, Once the CCC approves these changes, I will push them to jdk8. -Chris. > > Martin's "random" wishlist: > - I wish the cool convenience methods in TLR like nextInt(least, bound) > could be promoted to Random.java, or perhaps to a utility class Randoms.java > - I wish that TLR didn't continue to extend the life of Random's poor > PRNG, and at least provide one with a 2**64 period. I don't see much > value producing a sequence compatible with Random, given that setSeed is > not available. > > but it's probably too late. From mike.duigou at oracle.com Wed Feb 27 18:31:43 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 27 Feb 2013 10:31:43 -0800 Subject: Review Request for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly In-Reply-To: <512DE295.8000508@oracle.com> References: <512D4F0B.8020903@oracle.com> <512D7009.70506@oracle.com> <512DE295.8000508@oracle.com> Message-ID: Ouch. That is unfortunate that File cannot reject bad input. Perhaps FileInputStream etc. should throw a specialized "Bad Filename" FnF for paths containing NUL if the underlying filesystem does not support NUL? Masking garbage input always really scares me. Mike On Feb 27 2013, at 02:40 , Alan Bateman wrote: > On 27/02/2013 02:31, Dan Xu wrote: >> Thank you, Mike. >> >> The reason not to throw out an exception is for the backward compatibility. Due to that, the constructorof File object with NUL willnever fail.While in NIO, it is defined in the spec to throw out exceptions when invalid NUL character is found. >> >> -Dan > Right, we can't change the constructor to throw an exception, particularly if this fix is going to be back-ported to 7u. For NIO then it's not an issue because getPath was specified from the begining to throw the unexpected InvalidPathException when it is given garbage. > > -Alan. From mike.duigou at oracle.com Wed Feb 27 19:00:45 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 27 Feb 2013 19:00:45 +0000 Subject: hg: jdk8/tl/jdk: 8008785: IdentityHashMap.values().toArray(V[]) broken by JDK-8008167 Message-ID: <20130227190108.3E2634747B@hg.openjdk.java.net> Changeset: f4b01f4e8f35 Author: mduigou Date: 2013-02-27 11:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f4b01f4e8f35 8008785: IdentityHashMap.values().toArray(V[]) broken by JDK-8008167 Reviewed-by: alanb ! src/share/classes/java/util/IdentityHashMap.java + test/java/util/Map/ToArray.java From dan.xu at oracle.com Wed Feb 27 19:40:10 2013 From: dan.xu at oracle.com (Dan Xu) Date: Wed, 27 Feb 2013 11:40:10 -0800 Subject: Review Request for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly In-Reply-To: References: <512D4F0B.8020903@oracle.com> <512D7009.70506@oracle.com> <512DE295.8000508@oracle.com> Message-ID: <512E611A.2080707@oracle.com> Because we cannot change the behaviour of File constructorsto error out the bad input immediately, the changes will be scattered all over many java io methods, especially methods in File.java, if we choose to reject bad inputs. And due to the delay of the rejection, it also brings a little headache to developers to find out why the exception happens.Comparing with that, the proposed approach is simple and resilient. In addition, the currentnormalization logic already tolerates some invalid path-name formats and invalid characters. This approach can be regarded as a extension of the tolerance to theNUL character. It is consistent with what the native platform would do with a null and what/how we are currently normalizing the "slash".Thanks! -Dan On 02/27/2013 10:31 AM, Mike Duigou wrote: > Ouch. That is unfortunate that File cannot reject bad input. > > Perhaps FileInputStream etc. should throw a specialized "Bad Filename" FnF for paths containing NUL if the underlying filesystem does not support NUL? > > Masking garbage input always really scares me. > > Mike > > On Feb 27 2013, at 02:40 , Alan Bateman wrote: > >> On 27/02/2013 02:31, Dan Xu wrote: >>> Thank you, Mike. >>> >>> The reason not to throw out an exception is for the backward compatibility. Due to that, the constructorof File object with NUL willnever fail.While in NIO, it is defined in the spec to throw out exceptions when invalid NUL character is found. >>> >>> -Dan >> Right, we can't change the constructor to throw an exception, particularly if this fix is going to be back-ported to 7u. For NIO then it's not an issue because getPath was specified from the begining to throw the unexpected InvalidPathException when it is given garbage. >> >> -Alan. From martinrb at google.com Wed Feb 27 23:07:17 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 27 Feb 2013 15:07:17 -0800 Subject: Define JNIEXPORT as visibility default with GCC? In-Reply-To: <51241726.2040102@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> Message-ID: 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 martinrb at google.com Wed Feb 27 23:16:43 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 27 Feb 2013 15:16:43 -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> Message-ID: I have another iteration of this change http://cr.openjdk.java.net/~martin/webrevs/openjdk8/hide-zlib/ that adds exciting new exception detail message for the InternalError I was scratching my head about earlier. - msg = strm->msg; + msg = ((strm->msg != NULL) ? strm->msg : + (ret == Z_VERSION_ERROR) ? + "zlib returned Z_VERSION_ERROR: " + "compile time and runtime zlib implementations differ" : + (ret == Z_STREAM_ERROR) ? + "inflateInit2 returned Z_STREAM_ERROR" : + "unknown error initializing zlib library"); From jan.t.ohlsen at gmail.com Thu Feb 28 07:47:40 2013 From: jan.t.ohlsen at gmail.com (Jan Ohlsen) Date: Thu, 28 Feb 2013 08:47:40 +0100 Subject: Why is StringBuilder.toString() returning new String instances for empty strings ? Message-ID: System.out.println( new StringBuilder().toString() == "" ); -> "false" Any reason for not returning the "" instance? public String toString() { return new String(value, 0, count); } --> public String toString() { return (count > 0) ? new String(value, 0, count) : ""; } ? From volker.simonis at gmail.com Thu Feb 28 08:07:09 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 28 Feb 2013 09:07:09 +0100 Subject: Why is StringBuilder.toString() returning new String instances for empty strings ? In-Reply-To: References: Message-ID: Probably because the API-Spec (http://docs.oracle.com/javase/7/docs/api/java/lang/StringBuilder.html#toString%28%29) says "..A new String object is allocated and initialized to contain the character sequence currently represented by this object..". Regards, Volker On Thu, Feb 28, 2013 at 8:47 AM, Jan Ohlsen wrote: > System.out.println( new StringBuilder().toString() == "" ); > -> "false" > > > Any reason for not returning the "" instance? > > > public String toString() { > return new String(value, 0, count); > } > > --> > > public String toString() { > return (count > 0) ? new String(value, 0, count) : ""; > } > > ? From forax at univ-mlv.fr Thu Feb 28 09:23:13 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 28 Feb 2013 10:23:13 +0100 Subject: Why is StringBuilder.toString() returning new String instances for empty strings ? In-Reply-To: References: Message-ID: <512F2201.50204@univ-mlv.fr> On 02/28/2013 09:07 AM, Volker Simonis wrote: > Probably because the API-Spec > (http://docs.oracle.com/javase/7/docs/api/java/lang/StringBuilder.html#toString%28%29) > says "..A new String object is allocated and initialized to contain > the character sequence currently represented by this object..". > > Regards, > Volker Also, this kind of short circuit 'if' in a heavily used code like StringBuilder.toString() can have bad interaction with the way the VM optimize/deoptimize. See this thread for more information. http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-May/010295.html R?mi > > On Thu, Feb 28, 2013 at 8:47 AM, Jan Ohlsen wrote: >> System.out.println( new StringBuilder().toString() == "" ); >> -> "false" >> >> >> Any reason for not returning the "" instance? >> >> >> public String toString() { >> return new String(value, 0, count); >> } >> >> --> >> >> public String toString() { >> return (count > 0) ? new String(value, 0, count) : ""; >> } >> >> ? From alexey.utkin at oracle.com Thu Feb 28 11:54:28 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Thu, 28 Feb 2013 15:54:28 +0400 Subject: Request for review: 7190897 (fs) Files.isWritable method returns false when the path is writable (win). Message-ID: <512F4574.5090909@oracle.com> Hi, Please review the fix. 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.00/ Summary: The isolated method for the file security descriptor testing against the process owner is not a realistic approach for run-time permission checking by two reasons: 1. the user can hold additional privileges due to access to active logon session 2. the test thread can be impersonated by token that is different from process token The problem is covered by test NB project attached to the bug. Please, read the bug comments for details. New approach based on WIN32 function AccessCheck that makes run-time permission checking against the thread token. The function security setting was adjusted for the file system objects. The bug JDK-8008810 [(fs) Handle leak in the [WindowsSecurity.enablePrivilege] method.] https://jbs.oracle.com/bugs/browse/JDK-8008810 was resoled as part of suggested modification. Regards, -uta From chris.hegarty at oracle.com Thu Feb 28 12:40:37 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 28 Feb 2013 12:40:37 +0000 Subject: hg: jdk8/tl/jdk: 8006409: ThreadLocalRandom should dropping padding fields from its serialized form Message-ID: <20130228124055.A25F8474AC@hg.openjdk.java.net> Changeset: 7d272e524768 Author: chegar Date: 2013-02-28 12:39 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d272e524768 8006409: ThreadLocalRandom should dropping padding fields from its serialized form Reviewed-by: dl, martin, alanb, shade ! src/share/classes/java/util/concurrent/ThreadLocalRandom.java From jan.t.ohlsen at gmail.com Thu Feb 28 12:53:38 2013 From: jan.t.ohlsen at gmail.com (Jan Ohlsen) Date: Thu, 28 Feb 2013 13:53:38 +0100 Subject: Why is StringBuilder.toString() returning new String instances for empty strings ? In-Reply-To: <512F2201.50204@univ-mlv.fr> References: <512F2201.50204@univ-mlv.fr> Message-ID: Yes, makes sense to avoid the branching in that method. Thanks. On Thu, Feb 28, 2013 at 10:23 AM, Remi Forax wrote: > On 02/28/2013 09:07 AM, Volker Simonis wrote: > >> Probably because the API-Spec >> (http://docs.oracle.com/**javase/7/docs/api/java/lang/** >> StringBuilder.html#toString%**28%29 >> ) >> says "..A new String object is allocated and initialized to contain >> the character sequence currently represented by this object..". >> >> Regards, >> Volker >> > > Also, this kind of short circuit 'if' in a heavily used code like > StringBuilder.toString() can have bad interaction with the way the VM > optimize/deoptimize. See this thread for more information. > http://mail.openjdk.java.net/**pipermail/core-libs-dev/2012-** > May/010295.html > > R?mi > > > >> On Thu, Feb 28, 2013 at 8:47 AM, Jan Ohlsen >> wrote: >> >>> System.out.println( new StringBuilder().toString() == "" ); >>> -> "false" >>> >>> >>> Any reason for not returning the "" instance? >>> >>> >>> public String toString() { >>> return new String(value, 0, count); >>> } >>> >>> --> >>> >>> public String toString() { >>> return (count > 0) ? new String(value, 0, count) : ""; >>> } >>> >>> ? >>> >> > From Alan.Bateman at oracle.com Thu Feb 28 14:03:23 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Feb 2013 14:03:23 +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> Message-ID: <512F63AB.2050204@oracle.com> On 27/02/2013 23:16, Martin Buchholz wrote: > I have another iteration of this change > http://cr.openjdk.java.net/~martin/webrevs/openjdk8/hide-zlib/ > > that adds exciting new exception detail message for the InternalError > I was scratching my head about earlier. > > - msg = strm->msg; > + msg = ((strm->msg != NULL) ? strm->msg : > + (ret == Z_VERSION_ERROR) ? > + "zlib returned Z_VERSION_ERROR: " > + "compile time and runtime zlib implementations differ" : > + (ret == Z_STREAM_ERROR) ? > + "inflateInit2 returned Z_STREAM_ERROR" : > + "unknown error initializing zlib library"); 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). 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. -Alan. From maurizio.cimadamore at oracle.com Thu Feb 28 14:08:40 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 28 Feb 2013 14:08:40 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20130228140850.94A29474B0@hg.openjdk.java.net> Changeset: 133a0a0c2cbc Author: mcimadamore Date: 2013-02-28 14:00 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/133a0a0c2cbc 8008723: Graph Inference: bad graph calculation leads to assertion error Summary: Dependencies are not propagated correctly through merged nodes during inference graph initialization Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/lambda/TargetType65.java Changeset: 332f23993353 Author: mcimadamore Date: 2013-02-28 14:05 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/332f23993353 8008813: Structural most specific fails when method reference is passed to overloaded method Summary: Bad logic for checking most specific method reference type Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/lambda/MostSpecific08.java Changeset: 08782b8b03ce Author: mcimadamore Date: 2013-02-28 14:05 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/08782b8b03ce 8008537: Missing method reference lookup error when unbound search finds a static method Summary: Static-ness check should be applied after member reference resolution Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples/NonStaticCantBeRefFragment.java + test/tools/javac/diags/examples/StaticMethodInUnboundLookup.java ! test/tools/javac/lambda/MethodReference22.java ! test/tools/javac/lambda/MethodReference22.out ! test/tools/javac/lambda/MethodReference28.out ! test/tools/javac/lambda/MethodReference51.out ! test/tools/javac/lambda/TargetType60.java ! test/tools/javac/lambda/TargetType60.out From Alan.Bateman at oracle.com Thu Feb 28 14:31:38 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Feb 2013 14:31:38 +0000 Subject: Request for review: 7190897 (fs) Files.isWritable method returns false when the path is writable (win). In-Reply-To: <512F4574.5090909@oracle.com> References: <512F4574.5090909@oracle.com> Message-ID: <512F6A4A.3080300@oracle.com> On 28/02/2013 11:54, Alexey Utkin wrote: > : > > The suggested fix: > http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7190897/webrev.00/ Thanks for sorting this out, this code should have used AccessCheck in the original implementation. A couple of comments: Did you consider having AccessCheckForFile take a parameter for the mapping so that it wouldn't be file-specific (and so could be renamed to AccessCheck)? checkFileAccess ignores the exception from AccessCheck whereas I should it should be translated to an IOException. 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. -Alan. From alexey.utkin at oracle.com Thu Feb 28 15:17:20 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Thu, 28 Feb 2013 19:17:20 +0400 Subject: Request for review: 7190897 (fs) Files.isWritable method returns false when the path is writable (win). In-Reply-To: <512F6A4A.3080300@oracle.com> References: <512F4574.5090909@oracle.com> <512F6A4A.3080300@oracle.com> Message-ID: <512F7500.8010106@oracle.com> On 28.02.2013 18:31, Alan Bateman wrote: > On 28/02/2013 11:54, Alexey Utkin wrote: >> : >> >> The suggested fix: >> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7190897/webrev.00/ > Thanks for sorting this out, this code should have used AccessCheck in > the original implementation. A couple of comments: > > Did you consider having AccessCheckForFile take a parameter for the > mapping so that it wouldn't be file-specific (and so could be renamed > to AccessCheck)? 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. > 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. > > 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. > -Alan. From Alan.Bateman at oracle.com Thu Feb 28 15:41:16 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Feb 2013 15:41:16 +0000 Subject: Request for review: 7190897 (fs) Files.isWritable method returns false when the path is writable (win). In-Reply-To: <512F7500.8010106@oracle.com> References: <512F4574.5090909@oracle.com> <512F6A4A.3080300@oracle.com> <512F7500.8010106@oracle.com> Message-ID: <512F7A9C.4030905@oracle.com> 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. >> 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. >> >> 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. -Alan. From martinrb at google.com Thu Feb 28 16:11:45 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 28 Feb 2013 08:11:45 -0800 Subject: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so In-Reply-To: <512F63AB.2050204@oracle.com> References: <5128AD43.2000809@oracle.com> <51292295.4040802@oracle.com> <512F63AB.2050204@oracle.com> Message-ID: 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 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. "Include What You Use" ==> "always #include in any source file that uses NULL." From david.dehaven at oracle.com Thu Feb 28 18:57:06 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 28 Feb 2013 10:57: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: <0ED8D7F6-1541-46C0-81AE-46FA0CBFE423@oracle.com> > 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. This looks fine, however since 4.2.1 is still used for some builds we need to filter that specific version out or this will cause grief in other groups. The __has_attribute check is also redundant since clang by design pretends to be gcc so the __GNUC__ check should be sufficient (clang claims GCC compatibility as one of it's selling features). LLVM is the backend to the compiler, it doesn't see the source code. My jawt_md.h fix (that I haven't touched in well over month) has a separate jni_md.h for Mac since it has to have it's own headers to properly fix the issue, it wouldn't affect Linux/Solaris builds at all though. I think that would be more appropriate for Mac users, who haven't used 4.2 in some time. If I can actually find some time this week I may be able to post it for review... There's also the matter of the hotspot header being wrong. Has a bug been filed for this? -DrD- From mark.reinhold at oracle.com Thu Feb 28 19:31:21 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 28 Feb 2013 11:31:21 -0800 Subject: @Supported design issues In-Reply-To: <51293038.7090503@oracle.com> References: <51266B7C.3040804@oracle.com>, <20130222150427.1712@eggemoggin.niobe.net>, <51293038.7090503@oracle.com> Message-ID: <20130228113121.144747@eggemoggin.niobe.net> 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? > 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. Earlier in this thread you stated "@Supported(true)" is meant to convey the same conservative evolution policy as is implicit in the SE APIs. It would be good for that policy to be captured in the specification of the annotation itself. >> - Is the "supportedness" of a package inherited by its sub-packages? > > No; for at least two reasons. First, annotation inheritance is only > defined to work for classes along the superclass chain; there is no > defined inheritance of annotations on methods or from superinterfaces. > Second, subpackages of a package can have at most a tenuous logical > relationship to the parent package (and they have no additional > language-level access). ... I understand both those points -- I was just wondering whether you intended to layer additional informal inheritance semantics over and above those of the language. I agree that's it's better not to do so, at least not for packages. >> - The name "Supported" is problematic. It begs the question, >> "Supported by whom?" Maybe the annotation should take URL and >> phone-number parameters so that you know where to go when you run >> into a problem? > > I would trust that users of a JDK distribution would by default turn to > the provider of their distribution for support, or barring that, > stackoverflow. Let's leave this bikeshed issue for later ... >> - 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? > 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. >> 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. 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? 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. >> - 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? >> - 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. 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. >> Finally, this annotation is intended for use throughout our code base, >> and will be of interest not just to people working on the JDK but also >> to people using it. Its syntax, semantics, and intended usage should >> hence be documented in a JEP, which will be much more visible than an >> obscure Javadoc page. > > The listed criteria for a JEP are: > >> It requires two or more weeks of engineering effort, >> >> It makes a significant change to the JDK, or to the processes and >> infrastructure by which it is developed, or >> >> It is in high demand by developers or customers. > > Perhaps excluding this email thread, the first condition does not hold > for this work and the second two conditions are debatable. You may disagree, but I think the second condition clearly holds. > ... > Given the apparent heightened interest in this topic, I trust that if a > JEP for this is sent in, it will be promptly published in the JEP index. Yes, of course. - Mark From david.dehaven at oracle.com Thu Feb 28 20:28:38 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 28 Feb 2013 12:28:38 -0800 Subject: Define JNIEXPORT as visibility default with GCC? In-Reply-To: <0ED8D7F6-1541-46C0-81AE-46FA0CBFE423@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> Message-ID: <9C72EAE5-393C-47B3-9ABF-792DB920970D@oracle.com> >> 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. > > This looks fine, however since 4.2.1 I meant 4.1.2? -DrD- From pbenedict at apache.org Thu Feb 28 20:35:44 2013 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 28 Feb 2013 14:35:44 -0600 Subject: @Supported design issues Message-ID: Regarding if 2 or more levels are necessary, it can easily be solved by introducing a family of annotations. I suggest abandoning the boolean attribute in favor of (something like) @Supported, @NotSupported, @Experimental, etc. You may likely find the need to express individual attributes at each "level" -- which is more expressive than trying to use a single annotation. And what's good for the goose is good for the gander. It would be nice to make (at least) @Supported officially part of Java so 3rd libraries can use them too in their own documentation. For example, Google does something quite similar with its @Beta annotation. Paul From daniel.daugherty at oracle.com Thu Feb 28 20:56:55 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 28 Feb 2013 13:56:55 -0700 Subject: Define JNIEXPORT as visibility default with GCC? In-Reply-To: <0ED8D7F6-1541-46C0-81AE-46FA0CBFE423@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> Message-ID: <512FC497.9080400@oracle.com> 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 brian.burkhalter at oracle.com Thu Feb 28 21:17:59 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 28 Feb 2013 13:17:59 -0800 Subject: Review: 7032154 - Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal Message-ID: <611D45A4-8B28-408E-8914-4BCEEB4F883D@oracle.com> Hello, 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. This is a large patch so it would be great to have comments from anyone interested in this area. At this point I think that it would be of most interest to identify errors, if any, as opposed to providing further suggestions for tweaking the code, although any comments whatsoever are of course welcome. All pertinent JTREG tests have been run successfully. The plan is to conduct further testing in parallel with code review. Once this patch has been validated and committed we can move on to other patches in this area, notably http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4396272, http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7192954, and http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131192. Thanks, Brian From brian.burkhalter at oracle.com Thu Feb 28 21:34:54 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 28 Feb 2013 13:34:54 -0800 Subject: Fwd: Review: 7032154 - Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal References: <611D45A4-8B28-408E-8914-4BCEEB4F883D@oracle.com> Message-ID: <3E47081F-1F08-4A61-8122-FB9209725232@oracle.com> 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 tim.bell at oracle.com Tue Feb 26 17:29:55 2013 From: tim.bell at oracle.com (tim.bell at oracle.com) Date: Tue, 26 Feb 2013 17:29:55 +0000 Subject: hg: jdk8/tl: 8009019: Updates to generated-configure.sh required for 8008914 Message-ID: <20130226172955.1AECA47420@hg.openjdk.java.net> Changeset: cb0ac8979caa Author: tbell Date: 2013-02-26 09:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/cb0ac8979caa 8009019: Updates to generated-configure.sh required for 8008914 Reviewed-by: sundar, jlaskey, jjg ! common/autoconf/generated-configure.sh